Once I tried to start a fair discussion... :)
- KVRian
- Topic Starter
- 1158 posts since 17 Feb, 2010
@Vokbuz :
I didn't want to be "hostile" in any way when I said "you don't know how SOUL works". If you intended my words as hostile, sorry for that. I just want to say that your objections in your post seem to be due to a not full understanding about SOUL and how it has been thought by guys at ROLI. Sorry for any misunderstanding, it could happen when I write a post with "hurry"...
I didn't want to be "hostile" in any way when I said "you don't know how SOUL works". If you intended my words as hostile, sorry for that. I just want to say that your objections in your post seem to be due to a not full understanding about SOUL and how it has been thought by guys at ROLI. Sorry for any misunderstanding, it could happen when I write a post with "hurry"...
- KVRian
- 1035 posts since 26 Jun, 2008 from Czech Republic
Watched the keynote. I really like it. Move to ARM or to browser is a real thing today. I wouldn't worry about the security. I can imagine plugins comming with downloadable precompiled SOUL packages if the developer is really scared. Or with some kind of encryption for the sensitive bits. What I REALLY like is that there seems to be a way to perhaps take an existing code and re-write it to SOUL with all the pre-existing plugin formats being supported by the compiler. All the other platofrms failed because people are way too accustomed to their favorite plugins and the new platform specific ones just s*cked. Any platform that has a chance of succeeding needs to have a conversion path for existing code bases. ...and this seems to have at least a shot. I'm a fan.
Evovled into noctucat...
http://www.noctucat.com/
http://www.noctucat.com/
-
mike_the_ranger mike_the_ranger https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=393922
- KVRist
- 262 posts since 16 Feb, 2017
Looking forward but right now it's more strange and obscure. And let's also face it: ROLI can make this easily their own standard. And then we're at the point: "hey look we have 10 different standards, time to make one final once and for all. oh hey look we have 11 standards."
- KVRian
- Topic Starter
- 1158 posts since 17 Feb, 2010
@FairleyCZ : "Or with some kind of encryption for the sensitive bits..."
Exactly! Instead, precompiled SOUL binaries would take it away from the original future-proof concept.
@mike_the_ranger : SOUL "plugins" are not distributed as executable binaries. If ROLI will fail, SOUL is here to stay without any issue.
For example, OpenGL has been created @ SGI more than 25 years ago. SGI is failed about 17 years ago and OpenGL is alive still today (and newer versions 2.0, 3.0, 4.0 have been made - offering backward compatibility).
Exactly! Instead, precompiled SOUL binaries would take it away from the original future-proof concept.
@mike_the_ranger : SOUL "plugins" are not distributed as executable binaries. If ROLI will fail, SOUL is here to stay without any issue.
For example, OpenGL has been created @ SGI more than 25 years ago. SGI is failed about 17 years ago and OpenGL is alive still today (and newer versions 2.0, 3.0, 4.0 have been made - offering backward compatibility).
- KVRian
- 1169 posts since 24 Feb, 2012
IMHO, compiling math is the smallest problem (by miles).
The true difficulty is about thinking out UIs and interaction concepts working with the latest interaction types (keyboard -> mouse -> multitouch -> ?) and the contexts in which we use them. Both are unpredictable. Same with display tech, maybe we'll have spherical, foldable or strechable displays at some point, VR around the corner. All asking for conceptual rewrites, not just new "drivers".
The same is true with political issues. Code-signing, passing various gate-keepers, high dependence on SOUL implementations and SOUL specification, versioning and potential fragmentation. Finally, all this must fit business models (both Roli's model, third party dev models, DAW and OS politics!). A "driver" won't handle that.
This is very much the Flash of audio, with all its fantastic advantages, and now rather well known, neck breaking drawbacks. All it needs to implode is one Steve writing a letter. Too risky for me, I'll pass. JUCE already "changed property" at least once, with deep philosophical changes. This can repeat anytime, as nobody will ever protect you from finding an even better idea, trashing the old. Or simply finding someone who pays you even better.
DIY and independence also has advantages, in particular long term: Control and mobility. Despite the noble goals, all this sounds a bit megalomaniac from ROLI. "Just trust us: we predict the future(tm) today".
The true difficulty is about thinking out UIs and interaction concepts working with the latest interaction types (keyboard -> mouse -> multitouch -> ?) and the contexts in which we use them. Both are unpredictable. Same with display tech, maybe we'll have spherical, foldable or strechable displays at some point, VR around the corner. All asking for conceptual rewrites, not just new "drivers".
The same is true with political issues. Code-signing, passing various gate-keepers, high dependence on SOUL implementations and SOUL specification, versioning and potential fragmentation. Finally, all this must fit business models (both Roli's model, third party dev models, DAW and OS politics!). A "driver" won't handle that.
This is very much the Flash of audio, with all its fantastic advantages, and now rather well known, neck breaking drawbacks. All it needs to implode is one Steve writing a letter. Too risky for me, I'll pass. JUCE already "changed property" at least once, with deep philosophical changes. This can repeat anytime, as nobody will ever protect you from finding an even better idea, trashing the old. Or simply finding someone who pays you even better.
DIY and independence also has advantages, in particular long term: Control and mobility. Despite the noble goals, all this sounds a bit megalomaniac from ROLI. "Just trust us: we predict the future(tm) today".
Last edited by FabienTDR on Tue Nov 12, 2019 10:45 pm, edited 1 time in total.
Fabien from Tokyo Dawn Records
Check out my audio processors over at the Tokyo Dawn Labs!
Check out my audio processors over at the Tokyo Dawn Labs!
- KVRian
- Topic Starter
- 1158 posts since 17 Feb, 2010
In the next 10-20 years things will move in the heterogeneous computung direction anyway. Maybe from 2030+ new materials will allow to continue the Dennard scaling (or, better, will allow to "scale in the time domain" = rise the semiconductors clock freq).
But for the years to come, the whole computing industry will move thowards the Heterogeneous Computing Architecture ( and it's a great thing ! ).
And heterogeneous computing means JIT. And JIT for pro audio means SOUL (or similar, I'm not a ROLY fanboy ! ). So everything it's moving in that direction (again : fortunately !).
GUI is not handled by SOUL in any way. It resides on a separate process, in a separate file written in a separate language (for example JS). You can handle multitouch or any kind of input you wish with it (separately from DSP code).
Things will need to be re-thought in the pro audio indistry from the ground up - it's a great chance for us all !
Also, tedious, unuseful things like the code-signing processes (aaaaaaarrgh !) and similar will be completely avoided, because SOUL simply can't contain malware of any sort. If a specific company (guess who?) doesn't want to adhere to SOUL and heterogeneous computing, it will be discarded by the pro audio communities/users/industry in just 15 minutes.
Last but NOT least, heterogeneous computing must not be compared in any way to passed, clunky web or browsers addons. It's completely another story.
But for the years to come, the whole computing industry will move thowards the Heterogeneous Computing Architecture ( and it's a great thing ! ).
And heterogeneous computing means JIT. And JIT for pro audio means SOUL (or similar, I'm not a ROLY fanboy ! ). So everything it's moving in that direction (again : fortunately !).
GUI is not handled by SOUL in any way. It resides on a separate process, in a separate file written in a separate language (for example JS). You can handle multitouch or any kind of input you wish with it (separately from DSP code).
Things will need to be re-thought in the pro audio indistry from the ground up - it's a great chance for us all !
Also, tedious, unuseful things like the code-signing processes (aaaaaaarrgh !) and similar will be completely avoided, because SOUL simply can't contain malware of any sort. If a specific company (guess who?) doesn't want to adhere to SOUL and heterogeneous computing, it will be discarded by the pro audio communities/users/industry in just 15 minutes.
Last but NOT least, heterogeneous computing must not be compared in any way to passed, clunky web or browsers addons. It's completely another story.
- KVRian
- 1169 posts since 24 Feb, 2012
It has the same political dependencies. Technically it's super interesting, don't get me wrong.
But practically, after 25 years in this biz, I can't trust its vision and promises.
The DSP/math part is the most trivial aspect when compiling. You can also use Java, C# or whatever developed JIT to achieve the same level of comfort, at the price of political dependence. In my view, asking every "player" in the market to develop and maintain his own "driver" is that clunky browser addon, rebranded. With all their advantages and drawbacks. In practice, there will be zero practical differences to what flash, silverlight, java applets historically achieved. Closed, rather short living worlds.
But practically, after 25 years in this biz, I can't trust its vision and promises.
The DSP/math part is the most trivial aspect when compiling. You can also use Java, C# or whatever developed JIT to achieve the same level of comfort, at the price of political dependence. In my view, asking every "player" in the market to develop and maintain his own "driver" is that clunky browser addon, rebranded. With all their advantages and drawbacks. In practice, there will be zero practical differences to what flash, silverlight, java applets historically achieved. Closed, rather short living worlds.
Last edited by FabienTDR on Sun Nov 03, 2019 6:26 pm, edited 6 times in total.
Fabien from Tokyo Dawn Records
Check out my audio processors over at the Tokyo Dawn Labs!
Check out my audio processors over at the Tokyo Dawn Labs!
- KVRian
- Topic Starter
- 1158 posts since 17 Feb, 2010
PS : when I say ROLI/JUCE's SOUL, I mean "that kind of concept/stuff", I'm not referring strictly to that specific company. We will see similar things from Intel and Microsoft (a modular Windows OS) in different areas for example. In this case ROLI seems to be in pole position for the pro audio area with SOUL.
PS2 : maybe if any ROLI member will join this discussion thread, he/she can disclose further details or more detailed infos about the current SOUL state, or maybe they will explain it in time for ADC2019...
PS2 : maybe if any ROLI member will join this discussion thread, he/she can disclose further details or more detailed infos about the current SOUL state, or maybe they will explain it in time for ADC2019...
- KVRian
- Topic Starter
- 1158 posts since 17 Feb, 2010
Ah, ok - I was strictly technically-speaking about that.
Instead, you mean from a "political dependency" point of view. Well in this case just compare SOUL to HTML.
HTML is for hypertexts what SOUL is for pro audio (I'm just talking about a "political dependency" in this specific comparison). No one would avoid HTML because in future it could be discarded form browsers' manufacturers (yes, it could happen - but how much is it probable ? )
If today you use intrinsics in your C++ code, you are strictly dependant from that or this compiler. If you make a sound library, you are dependant from this ot that file format. Etc. Also your standard C++ code itself requires a correctly-working compiler available for that specific platform. And a specific plugin format has to be compatible with that platform too. We can continue endlessy with the MIDI standard from MMA, and go on further eheh
To say it all from a "publishing dependency" point of view, today you hve to pay 99 USD/year just to have the "privilege" to code-sign your plugin you want to distribute...
Today's restrictions are heavy enough.With SOUL or similar, things can just go better. Said that, let's see how ROLI will proceed with that !
PS : last year ROLI said they will make SOUL completely open source and fees-free for plugins developers. The same as happens with MIDI for example (and other things). Just drivers manufacturers will be charged (if I remember fine).
Instead, you mean from a "political dependency" point of view. Well in this case just compare SOUL to HTML.
HTML is for hypertexts what SOUL is for pro audio (I'm just talking about a "political dependency" in this specific comparison). No one would avoid HTML because in future it could be discarded form browsers' manufacturers (yes, it could happen - but how much is it probable ? )
If today you use intrinsics in your C++ code, you are strictly dependant from that or this compiler. If you make a sound library, you are dependant from this ot that file format. Etc. Also your standard C++ code itself requires a correctly-working compiler available for that specific platform. And a specific plugin format has to be compatible with that platform too. We can continue endlessy with the MIDI standard from MMA, and go on further eheh
To say it all from a "publishing dependency" point of view, today you hve to pay 99 USD/year just to have the "privilege" to code-sign your plugin you want to distribute...
Today's restrictions are heavy enough.With SOUL or similar, things can just go better. Said that, let's see how ROLI will proceed with that !
PS : last year ROLI said they will make SOUL completely open source and fees-free for plugins developers. The same as happens with MIDI for example (and other things). Just drivers manufacturers will be charged (if I remember fine).
- KVRist
- 91 posts since 13 May, 2007
I’m not going to pretend that I know anything about what you write, but JIT-compilation is prohibited in Catalina. Or to be precise, it requires a special entitlement:xhunaudio wrote: ↑Sun Nov 03, 2019 2:42 am The most discussed topic in the passed months/weeks (and it totally makes sense) is developers' concern about the future of plugin development. Obviously, "software and plugins" are here to stay for the Centuries to come - I'm just talking about how much **uselessy complicated** things seem to be going from a developer's perspective.
Starting a battle of fanboys is definitely NOT my aim here, in any way. People (like the developers in this forum) who spent the latest *decades* dealing *everyday* with computer science just know if a computing system/company is valid or not. Other considerations about "which OS has the most colourful icons" are just fanboys' stuff.
Fake "companies" arbitrarily discarding support for *GEMS* like OpenGL WITHOUT ANY REASON, or arbitrarily moving to a different CPU architecture without a software layer for "backward" compatibility (because it will happen), etc. are at the center of everyday's discussion topics. From a wider perspective, in the pro audio world, 99% of everyday discussions are about :
- is this plugin 64-bit or also 32-bit ?
- this plugin makes use of OpenGL graphics ?
- I have to sign that plugin, and the package containing that plugin, and the package containing that package (,....,...) before shipping ?
- etc., etc, etc, ...
Sorry, but I really have enough . We concern about this aspects as it was a normal thing. But it definitely has nothing to do with pro audio itself. It's just a **waste of time** we should spend on creating new synthesis gems.
So, in this dark-fate scenario, a new hope seems to be rising over the horizon (for the ones who missed it) : SOUL (soul.dev). I really wish it will take all the attention it deserves. Things seem to proceed quite fast with it - it's not production-ready at now, but I wish it will be soon
To say it in 2 words - beside a ton of other benefits - SOUL let us to "develop it once, run it forever on any past, present and future platform".
There's also a new announcement for ADC2019 :
https://juce.com/discover/stories/build ... l-beginner
https://developer.apple.com/documentati ... _allow-jit
Due to the fact that entitlements are properties of the host, plugins can’t use JIT when loaded into a host not having that entitlement.
Arne @ noteperformer.com
- KVRian
- Topic Starter
- 1158 posts since 17 Feb, 2010
Hi Wallander,
My apologies, it's too long to fully explain it in a single post - but I'll try to recap it in a "few" lines.
Today, ROLI/JUCE's SOUL has to be seen as the "sneak-preview" of a long-term approach to something called domain-specific computing architectures (software-side).
(DSA) Domain-specific computing (aka true HC "heterogeneous computing") will proliferate in the next few decades, driven by a multi-billion dollars industry. Any kind of OS trying to "obstruct" this approach will simply take its creators to their own failure. Historically, heterogeneous computing was a common practice in the 80s for example (just hardware-side - but definitely NOT software-side !). The upcoming new HC approach (this time including the software-side as well) is a great thing, from the perspective of a purist, performance-maniac computing enthusiast. And domain-specific means a form of high-performance JIT. In a form that really has *nothing* to do with clanky things seen on browsers and websites more than 15 years ago...
In the past, a lot of AUTHENTIC computing companies like SGI (or research institutes like the Bell Labs) failed for this of that reason. So no one is free from potential wrong strategies - also a good company can take wrong decisions and fail.
Personally, I can't read into their minds, but I don't think Apple will close its future OS doors to things like SOUL (and billions of similar examples in different computing contexts). In addition, I think Apple will have great consideration of JIT and DSA/HC. Despite marketing hypes of the passed years, ARM architecture can't be considered in any way a valid x86-x64 competitor for high-performance computing scenarios ( I'm not talking about the twitter/facebook/web navigation scenarios ) . If Apple wants to completely move to ARM devices, it's because for that time they expect a big diffusion of software based on the DSA/HC approach (it's long to explain in detail).
But I make my statement purely from the "computing" point of view - to try to predict Apple's strategies it's important to consider what Apple really is.
Apple today is a "finance colossus" company - not an authentic computing company. And it can happen that they will take such insane approaches (missing support for DSA) for their OS ecosystem - because if they fail on OS side, they could invest on things like watches, cars, glasses, phones, IoT, "artificial intelligence", the so-called "clouds" and similar crap. Their field is exclusively the finance (the practice of making money out of other money), not the computing industry. So I can't make accurate predictions for Apple's specific future, because I don't know what vision a "finance company" has about itself and about the world. For example, it is possible that Apple's strategy is to voluntarily get rid of its computing division to produce more iphones or watches. It's all about its financial visions...
Then, about "Catalina", it's mandatory to see this thing in the long-term scenario. Scientifically speaking, in no way Catalina represents the future of computing. Instad, realistically, Catalina is just the next iteration of a curious, insane marketing game several companies played in the passed (few) years : making an OS major update every year. It's a wrong practice from engineering viewpoint : an OS has just to be stable. Making a major update every year is a suicide. But this is another story... Let's just say that Catalina and its "features" can't be taken as an example of the "future of computing", eheh
My apologies, it's too long to fully explain it in a single post - but I'll try to recap it in a "few" lines.
Today, ROLI/JUCE's SOUL has to be seen as the "sneak-preview" of a long-term approach to something called domain-specific computing architectures (software-side).
(DSA) Domain-specific computing (aka true HC "heterogeneous computing") will proliferate in the next few decades, driven by a multi-billion dollars industry. Any kind of OS trying to "obstruct" this approach will simply take its creators to their own failure. Historically, heterogeneous computing was a common practice in the 80s for example (just hardware-side - but definitely NOT software-side !). The upcoming new HC approach (this time including the software-side as well) is a great thing, from the perspective of a purist, performance-maniac computing enthusiast. And domain-specific means a form of high-performance JIT. In a form that really has *nothing* to do with clanky things seen on browsers and websites more than 15 years ago...
In the past, a lot of AUTHENTIC computing companies like SGI (or research institutes like the Bell Labs) failed for this of that reason. So no one is free from potential wrong strategies - also a good company can take wrong decisions and fail.
Personally, I can't read into their minds, but I don't think Apple will close its future OS doors to things like SOUL (and billions of similar examples in different computing contexts). In addition, I think Apple will have great consideration of JIT and DSA/HC. Despite marketing hypes of the passed years, ARM architecture can't be considered in any way a valid x86-x64 competitor for high-performance computing scenarios ( I'm not talking about the twitter/facebook/web navigation scenarios ) . If Apple wants to completely move to ARM devices, it's because for that time they expect a big diffusion of software based on the DSA/HC approach (it's long to explain in detail).
But I make my statement purely from the "computing" point of view - to try to predict Apple's strategies it's important to consider what Apple really is.
Apple today is a "finance colossus" company - not an authentic computing company. And it can happen that they will take such insane approaches (missing support for DSA) for their OS ecosystem - because if they fail on OS side, they could invest on things like watches, cars, glasses, phones, IoT, "artificial intelligence", the so-called "clouds" and similar crap. Their field is exclusively the finance (the practice of making money out of other money), not the computing industry. So I can't make accurate predictions for Apple's specific future, because I don't know what vision a "finance company" has about itself and about the world. For example, it is possible that Apple's strategy is to voluntarily get rid of its computing division to produce more iphones or watches. It's all about its financial visions...
Then, about "Catalina", it's mandatory to see this thing in the long-term scenario. Scientifically speaking, in no way Catalina represents the future of computing. Instad, realistically, Catalina is just the next iteration of a curious, insane marketing game several companies played in the passed (few) years : making an OS major update every year. It's a wrong practice from engineering viewpoint : an OS has just to be stable. Making a major update every year is a suicide. But this is another story... Let's just say that Catalina and its "features" can't be taken as an example of the "future of computing", eheh
- KVRist
- 91 posts since 13 May, 2007
Don’t shoot the messenger.
All I’m saying is, you can do JIT on Catalina. But the host’s executable needs to be signed with entitlements for JIT, if that host is also going to be notarized.
Adding those entitlements is not by any means impossible to do. It’s a checkbox in Xcode.
I’m not a host developer, but if I was, I would select all those checkboxes. I don’t see why not.
https://developer.apple.com/documentati ... titlements
All I’m saying is, you can do JIT on Catalina. But the host’s executable needs to be signed with entitlements for JIT, if that host is also going to be notarized.
Adding those entitlements is not by any means impossible to do. It’s a checkbox in Xcode.
I’m not a host developer, but if I was, I would select all those checkboxes. I don’t see why not.
https://developer.apple.com/documentati ... titlements
Arne @ noteperformer.com
- KVRian
- Topic Starter
- 1158 posts since 17 Feb, 2010
I didn't and I'll never shoot the messenger !
To add some new element to this SOUL/DSA/HC thread, my post was just to say that also if there're companies which seem to "close" their system to JIT and similar stuff, on the long-term things will take a different way...
Again, any comment here directly from SOUL developers would be very welcome !
To add some new element to this SOUL/DSA/HC thread, my post was just to say that also if there're companies which seem to "close" their system to JIT and similar stuff, on the long-term things will take a different way...
Again, any comment here directly from SOUL developers would be very welcome !
Last edited by xhunaudio on Sun Nov 10, 2019 12:22 am, edited 1 time in total.
-
- KVRer
- 26 posts since 16 Oct, 2019
wait, is this a soul thread? i can't even...
- KVRAF
- 7960 posts since 12 Feb, 2006 from Helsinki, Finland
I hope you realise that "high performance computing" usually refers to the type of scenarios where you have a room or two full of servers (these days often stuffed full of GPUs), connected by high-speed interconnects and often working with datasets measured in terabytes or more. The type of CPU your laptop carries is essentially completely irrelevant when it comes to the HPC world.
Also, I'm rather skeptical that this "heterogeneous computing" is ever (again) going to happen with audio. We used to have special purpose DSPs back when our general purpose computers where slower, but if you've been following the audio market for a few decades, you must have noticed that separate DSP systems essentially became obsolete the moment our computers reached the point where the special-purpose DSP simply couldn't keep up with the performance anymore.