Once I tried to start a fair discussion... :)

[xhunaudio]

Hi !

Correct. The term "HPC market", *today* refers to the Compute Cluster area. Once - for several decades - the term HPC referred to a market area made of BOTH Clusters and Workstations (in a time when Clusters were considered as "cluster of workstations" indeed). In the past they were inter-dependant and they had a lot in common, both (cluster and workstations) shared the same CPU architectures for example (today is different) and coprocessors had a very marginal role (in this case I'm just talking about clusters).

I didn't use the term "HPC market" indeed, but a generic "high-performance computing scenarios" to point, well, "computing scenarios where high performace is crucial" like today's workstation market - and if today you make music using pro audio softwares, you are making it using a workstation-class hardware (indeed, today's x86 computing systems are NOT "PCs" AT ALL - from about 25 years - they are all 100% derived from the workstation-class hardware market of that time). So yes, my clarification was due, sorry for the misunderstanding.

JUST A SIDE NOTE : you said "a laptop CPU is irrelevant compared to HPC" - here's just a "kind provocation" to what you said : today, if you run a pure single-threaded task (a single voice of a single virtual instrument for example), a laptop CPU could outperform a computer cluster made of 1000s CPUs and GPUs, for the reasons I said above (today's cluster - workstation CPU difference). Please : it's just a "kind provocation", I don't want to argue !

Indeed, the "Special purpose DSP" you mentioned was the former "heterogeneous computing" developed during all the 80s and the first half of 90s as I said in my previous post. It was based on the hardware-side ONLY. To be more precise, this approach basically ended 20/25 years ago, when a single, mainstream CPUs computational power was more than adequate to run evoluted and consistent DSP (software), AND a full operating system, AND GUI elements, AND a solid audio engine - all at the same time. Instead, if you consider JUST the DSP-side (software), CPUs of that time have always been more powerful than any other DSP (from the end of 80s / start of 90s) - but they had a much greater cost ($) and required much more power.

During the first-half of 90s, if for example a "widely known research institute" was making a prototype (to exhibit in pro audio shows/fairs) of early physical modeling etc. or any generic synthesis softwares, it could do it making use of a Motorola 56xxx DSP or - if polyphony was crucial for that prototype - on a single, more powerful Intel or MIPS CPU (instead of using multiple 56xxx). Also, DSP only handled integers computing (with completely missing or VERY limited FP support) - while CPU natively handled full floating-points too (the "scientific" format). To say it all, several prototypes ran on an original (true CISC) Intel Pentium P5, before any completely different, *modern* RISC-based Intel CPU (P6 and beyond) was available. But this was an amazing revolution which would require a separate topic

Today (and for the future) you have to forget about *classic* DSP. They will never come back in the high end pro audio. The near future is made of FPGAs which can be rearranged to act as single threaded DSP coprocessors or parallel vector DSP boosters (or GPUs, or tensor engines, or anything you wish...).

And here comes the SOUL (DSA/HC) approach. You write a soul DSP-code *once in your life* and it will automatically run on any hardware (passed, present or future) - you choose : on your CPUs, or on your DSPs, or on your FPGAs, etc. at full native speed (as it was a native C++ / Assembly code specifically compiled for a specific architecture). Just a single SOUL driver has to be made for each *device / architecture* in order to run an unlimited number of SOUL "plugins" (their correct name is SOUL "patches/patchers").

This is what will, or *should* happen in the very near future. Then we'll see - I can't see the future eheh - things could always take a "detour" I can't predict, or be just *slightly* "variation on the theme" (Intel ONE API, Intel VISC, etc.). It will be a real fun to see...

Then, when materials will permit it, we'll continue with the CPU performance increases as we seen with the Dennard-scaling or Moore's law - even better if in the time-domain (higher clock cycles). That will make EVERYONE happy for sure...

Cheers !

[xhunaudio]

I just changed the thread title - now it's more clear that the main topic is SOUL (and similar approaches).

[BertKoor]

SOUL simply can't contain malware of any sort.

Don't count on that. My experience tells me that each and every harmless baby toy can be used to kill someone. In unsuspected ways, sure you have to be extremely creative. But just never say never.

Also it would give a fake sense of security. Cracked plugins of this language cannot be malicious, cracks become "safe" to use again.

So here's an evil scheme that can be done in such an audio language. Slowly decrease the volume. Slowly it gets softer and softer. And then suddenly: NOISEBURST!!
Ouch, that really hurts. Possibly much worse things can be done. Stealing all memory or whatever...

[Vokbuz]

because SOUL simply can't contain malware of any sort

But can SOUL code be replaced with bad behaving one? Sure it can. For example, the one that produces very loud signal in certain circumstances? That is not dangerous at all.

[xhunaudio]

Eheheh

Please, at least let's agree on considering an unexpected *noise burst* as an extremely (*extremely*) idiot form of malware... eheheh

Seriously, it can't be considered as "malware". It would be just a sort of idiot practice which could be done even today, but for comprehensible reasons nobody ever did it. A strange sort of malware, made by hackers moving from Cyberpunk to... Cyberpranks

Another form of malware could be on the GUI side, imagine an analogue modeling synth fading from its normal GUI to a pink-gold-acidgreen colored GUI every time you play key C#6... It would be very annoying indeed - damned Cyberpranks !

[Vokbuz]

which could be done even today

Pfff.. No, it is very hard (almost impossible) to change compiled dsp code. With SOUL "shaders" this task is trivial.

[xhunaudio]

No, SOUL code can be "obfuscated" before "shipping", so it would be difficult to modify the same way as it was binary code (not easy, but not impossible).

In addition, the specific kind of alteration you suggested for your "malware"(an unexpected noise burst), would be easy to bring on binaries too (it would represent the most trivial alteration you can make onto a binary). If nobody ever did it it's not because it's impossible, but because it's just... silly, eheh.

But why insisting on this ? It's not a "malware" - in that case your "antivirus" would just be a clipper

Peace !

[Vokbuz]

In addition, the specific kind of alteration you suggested for your "malware", would be easy to bring on binaries too (it would represent the most trivial alteration you can make onto a binary). If nobody ever did it it's not because it's impossible, but because it's insane, eheh.

The effort for binary code does not worth it. For SOUL (even obfuscated) it is trivial. It can even be automated. You can't automatically find dsp in the binary but you can for SOUL code. Virus that injects bad things in your SOUL code? Impossible? No, it is even simpler than you think.

And this is not the only possible thing that can have bad consequences. Malicious code can add watermarks to you audio or introduce other artefacts that people will notice too late.

No, SOUL code can be "obfuscated" before "shipping", so it would be difficult to modify the same way as it was binary code (not easy, but not impossible).

Why obfuscated in quotes? Is it a real obfuscation or just an intermediate code? Obfuscation can harden the task a bit but it is still a lot simpler than changing binary machine code. Automated injector won't even care if a code is obfuscated.

[xhunaudio]

Why obfuscated in quotes?

I wrote "obfuscated" in quotes just because I was not sure that was the proper term in english - I wrote my post "hastily" and I had no time for checking online...

PS : then, I wrote "hastily" in quotes because I'm not sure it's a widely used synonym for "quickly", "with hurry".

For the rest, it's ok, no problem... Let's see if the JUCE team will give us more infos and details (the ADC 2019 is expected in about a couple of weeks). Cheers !

[Max M.]

xhunaudio
Let's see if the JUCE team will give us more infos and details

There's plenty of details available at https://github.com/soul-lang/SOUL for about a year already. And these details are enough to see SOUL is not what you seem to expect or wish it to be.

(I hate to spoil the fun, but too high expectations are the source of great disappointments).

[xhunaudio]

Hi !

Eheh, I'm not ROLI affiliated (at all) and there're no SOUL plugins currently among my Company's products - obviously - so I have no reasons to promote or push on SOUL, or start a thread about it to "convince" people... I started this thread just because in my opinion SOUL has a great value and I wanted just to give my modest, personal, "moral" support to the JUCE team for their good work, by simply "spreading the voice".

I'm following it from the very first day since the ADC 2018 event and it seems to be exactly what I think it is going to be : a real revolution capable of improvements over the standard development (I *literally* love standard C++ development, but SOUL/DSA/HC opens up far greater scenarios while offering the same, or even slighly greater, level of excellence).

Definition :
"SOUL (SOUnd Language) is an attempt to modernise and optimise the way high-performance, low-latency audio code is written and executed".

https://github.com/soul-lang/SOUL/blob/ ... verview.md

https://github.com/soul-lang/SOUL/blob/ ... OUL_FAQ.md

My opinion is that if you take a deep read and you also have a very solid knowledge of what computer science currently is (and what it has been in the passed decades), you'll find SOUL just amazing - a modern take to the entire pro-audio software and (extremely important for me) a sneak-preview into the future of computing architectures and semiconductors industry.

Said that, everyone is free to discard it ! Don't follow it if you don't like it

Cheers,

[jules]

Just noticed this thread is getting some attention on KVR and thought I'd drop in to say hello.

I can also give you an exclusive! We've just this morning quietly made our first v0.8 soul beta release, so you can start building hosts that load soul patches now if you want... Best place to look for more info is on github: https://github.com/soul-lang/SOUL
(We'll also shortly release a version of Tracktion Waveform out which has built-in support for soul patches, and can live reload them etc)

SOUL is a huge project and this is just the beginning - there are years of interesting work to do on it but great that the industry is already engaging with it! Next week we'll be running our first SOUL workshop at ADC19 and showing it running on some special guest hardware!

@xhunaudio - thanks for your comments here, it sounds like you really get what we're trying to do

There are some strange comments here that seem to be suggesting that people could maliciously somehow "change" your soul code... well, sure, if a person or virus has write access to your disk then it can change anything it wants... A SOUL patch is just a bundle of files, and sure, a nasty virus could modify a soul patch on your disk to make a noise burst, but if you've been pwned and that's the worst they do then I'd say you got off lightly!

The security concern that we ARE taking seriously is the idea that a SOUL patch could have deliberately crafted to try to escape the sandbox. It's obviously tricky to prove 100% that any sandbox is perfect, but there are plenty of trusted techniques that have been used for a long time and which we can lean on - e.g. the Berkely Packet Filter checker, or using WebAssembly as a well-tested intermediate layer, and we're going to explore Metal/Vulkan's JIT engines as possible runtimes too. But part of the plan all along was for us to make the HEART intermediate language suitable for static sanity checking without compromising runtime performance.

[Vokbuz]

There are some strange comments here that seem to be suggesting that people could maliciously somehow "change" your soul code... well, sure, if a person or virus has write access to your disk then it can change anything it wants... A SOUL patch is just a bundle of files, and sure, a nasty virus could modify a soul patch on your disk to make a noise burst, but if you've been pwned and that's the worst they do then I'd say you got off lightly!

So basically you just confirmed that this attack is possible but at the same time the comment about it is strange. You need to pick one. If you follow the conversation this was an example why an app with SOUL code still needs code-signing. The OP suggested that SOUL doesn't need it:

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.

[jules]

So basically you just confirmed that this attack is possible but at the same time the comment about it is strange. You need to pick one. If you follow the conversation this was an example why an app with SOUL code still needs code-signing. The OP suggested that SOUL doesn't need it.

Erm.. no.. I "confirmed" that obviously anyone who can write to your files can change the content of those files. But I suspect any malicious attacker which had that kind of access would be busy encrypting your hard-disk for ransom rather than trying to make your DAW play a noise burst.

Yes: code-signing soul programs is certainly on our roadmap, and maybe in future, some (most?) SOUL back-end drivers or hardware devices might decide to reject programs that aren't signed. but that'll be up to the vendors to decide.

But given that we specifically designed SOUL's architecture to give it a huge head start over native code in terms of security, and since native executables themselves are only recently starting to get code-signed, I wouldn't really expect anyone to worry much about that aspect for some time. It'd be like code-signing WASM or GLSL. Sure, there will be situations where that makes sense, but people mainly trust the sandbox and host to prevent really egregious stuff getting through.

[xhunaudio]

Hey Jules, nice to hear from you,

keep up the good work, I'm following it with much interest !