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

[JamminFool]

Fantastic stuff! However, I'm a little stuck at the moment:

The latest version seems not to be working. Using the 0.9.49 release of soul, it draws the frame, but then goes into an infinite load loop (circle going around and around) when trying to play the basic MonoSynth as shown in the video. The same thing happens using the latest beta's of Waveform (which was updated with the 0.9.49 release also).

Also, the video mentions a VSCode plugin which highlights errors in the code. When will this be available (or am I missing something - the current extension on Github only does code highlighting)?

Lastly, will the VSCode extension eventually also be able to run the soul tool from within VSCode (ie, no need for command line soul tool) ?

[xhunaudio]

Sadly, SOUL developers seem not to be particularly prone to join a KVRAudio forum discussion / thread.

And it's not dfficoult to understand why, after reading some users' posts (previously made).

It seems (very often) impossible to have a fair discussion on this forum, due to a (sadly) widespread quarrelsome behaviour of some users on almost every thread...

[jules]

Like you guessed there, I don't visit KVR very often, so only just noticed these posts!

We don't really have a website page set up for news updates, so I'd say that the best places to look are:

- To find out about new features and releases: https://github.com/soul-lang/SOUL/releases
- For more granularity, just have a look directly at the commits on github
- For a bug report, use github issues
- To contact us and chat directly, the public forum we probably visit the most is the https://theaudioprogrammer.com discord community, where we have a soul channel. I think this link might work: https://discord.gg/uQtUHW

[xhunaudio]

Thank you, Jules

[xhunaudio]

So, as an "update" :

- now we (developers) have dozens of plugin formats, operating systems, architectures and semiconductors to deploy for (for each single product to make or just to update).

- Apple made its own silicon, Microsoft is going to do the same, and so Nvidia, and others.

- Linux distros specially suited for music production are something growing of importance, supporting different ISAs.

Having to deply for all this combinations of hardware/software/os is becoming really ridiculous, I really wish SOUL or a SOUL-like alternative will be introduced soon.

If any SOUL / JUCE Team member will ever be aware of this post I would ask if there's any news about the way a SOUL patches/plugin are intended to be distributed (in a commercial scenario) :

- Is it possible to distribute a "protected" version of the HEART code instead of the SOUL patch itself ?

- Is it correct to say that distributing the HEART code directly is ok to preserve the cross-platform, auto-optimization and auto-parallelization properties of the original SOUL patch ?

[jules]

- Is it possible to distribute a "protected" version of the HEART code instead of the SOUL patch itself ?

- Is it correct to say that distributing the HEART code directly is ok to preserve the cross-platform, auto-optimization and auto-parallelization properties of the original SOUL patch ?

Yes, a program can either be in SOUL or HEART (which is assembly-level code if you strip out any meaningful names from it). If it's SOUL, it just gets compiled to HEART internally, and we've made it cross-platform so that there's no disadvantage in distributing a program in HEART.

[DPhil]

- now we (developers) have dozens of plugin formats, operating systems, architectures and semiconductors to deploy for (for each single product to make or just to update).

- Apple made its own silicon, Microsoft is going to do the same, and so Nvidia, and others.

- Linux distros specially suited for music production are something growing of importance, supporting different ISAs.

Having to deply for all this combinations of hardware/software/os is becoming really ridiculous, I really wish SOUL or a SOUL-like alternative will be introduced soon.

Nice, just yet another plugin format for devs to support Don't think if you introduce something like that, everything else will disappear. It's just one more thing to do.

[xhunaudio]

- Is it possible to distribute a "protected" version of the HEART code instead of the SOUL patch itself ?

- Is it correct to say that distributing the HEART code directly is ok to preserve the cross-platform, auto-optimization and auto-parallelization properties of the original SOUL patch ?

Yes, a program can either be in SOUL or HEART (which is assembly-level code if you strip out any meaningful names from it). If it's SOUL, it just gets compiled to HEART internally, and we've made it cross-platform so that there's no disadvantage in distributing a program in HEART.

@jules : thank you for the clarification, can't wait to hear more details about "real-world" applications of SOUL (nothing new from the ADC20, sadly).

[haslo]

I'm sure this xkcd has already been posted in this thread?

[Chaotikmind]

Yes, a program can either be in SOUL or HEART (which is assembly-level code if you strip out any meaningful names from it). If it's SOUL, it just gets compiled to HEART internally, and we've made it cross-platform so that there's no disadvantage in distributing a program in HEART.

Which also means that HEART is the soul IR, which make it easy to disassemble, or even decompile.

[jules]

Nice, just yet another plugin format for devs to support Don't think if you introduce something like that, everything else will disappear. It's just one more thing to do.

Nobody's expecting VST/AU to disappear overnight.

Widely-used standards always stick around for years, often way past their sell-by-date, but nothing lasts forever, and it's hard to imagine that VST or AU will still be the main way that audio instruments and effects are consumed in 10 years time.

What we're trying to do with SOUL is create a new platform that can complement the existing standards in the short-term (you can export a SOUL plugin as a native C++ VST/AU etc), but also be ready to solve the longer-term problems that the existing standards can't address.

Somebody's got to have a go at this in a way that isn't just a toy project, or nothing will ever improve!

Yes, a program can either be in SOUL or HEART (which is assembly-level code if you strip out any meaningful names from it). If it's SOUL, it just gets compiled to HEART internally, and we've made it cross-platform so that there's no disadvantage in distributing a program in HEART.

Which also means that HEART is the soul IR, which make it easy to disassemble, or even decompile.

<shrug>

All IRs can be decompiled. HEART is harder to decompile than a native x86 plugin, simply because there aren't yet any tools to do so.

If I'd been able to do the impossible task of creating a programming language that *can't* be disassembled, then you wouldn't see me here on KVR answering troll posts, I'd be off making billions of dollars in the security industry.

[JamminFool]

If I'd been able to do the impossible task of creating a programming language that *can't* be disassembled, then you wouldn't see me here on KVR answering troll posts, I'd be off making billions of dollars in the security industry.

Best wishes for this project. Happy New Year, Jules!

[haslo]

Widely-used standards always stick around for years, often way past their sell-by-date, but nothing lasts forever, and it's hard to imagine that VST or AU will still be the main way that audio instruments and effects are consumed in 10 years time.

It's not impossible either though. WAV and MIDI have been around for much longer, and they're here to stay (though MIDI 2.0 looks interesting - but one of the things that make it interesting is its backwards compatibility). Also, VST3 is just now starting to be ubiquitous over VST2, 12 years after it was introduced.

That being said, platform independent higher-level code is something I love. That's why when I now finally started developing plugins after being interested for quite a while, it was with modules for Voltage Modular - where I can write Java code that will run everywhere, and the repetitive work of wiring it all together in a plugin like shape is done for me by the dev environment.

So I'm definitely intrigued!

What we're trying to do with SOUL is create a new platform that can complement the existing standards in the short-term (you can export a SOUL plugin as a native C++ VST/AU etc), but also be ready to solve the longer-term problems that the existing standards can't address.

See post two below this one why this bit is struck through.

With this export you mean what can be achieved with the CLI and "soul generate", correct? Does that generate everything needed for a fully functional JUCE plugin, for example? Can I just generate a JUCE project with that, compile it as VST, and have it work - then modify my SOUL project with new stuff, export again and have it work again? Or will I have to modify the generated JUCE project every time I make an export?

I guess I'm really looking for a dev environment that lets me generate a series of versions of my plugin that run everywhere, with as few commands as possible, and in as few languages as necessary - and a version that runs on my system with just one batch, preferably. I'm a strong believer in at least continuous delivery (I guess continuous deployment doesn't make sense in this field, where offline functionality is still very important).

Is SOUL that environment, even while the format itself isn't supported in the majority of hosts and I really want to generate VST for that?

Oh, and how is IDE support? Is there syntax highlighting or more in IntelliJ, VS Code, or something else?
I like to heavily use stuff like autocomplete, auto indentation, refactoring methods, jump-to-definition or finding usages of a method - whether I have that or not has a huge impact on my productivity and, consequently, my motivation to use a framework and language...

[GRUMP]

I´m no Dev, stumbeled in .. ("Soul") - but a) it is not in anyones interest to have things running forever, but b) old things will always be overcome by new developments and their stakeholders interests. No matter if it´s an improvement or in how far. AI frameworks will prevail.

[haslo]

So after watching the keynote and reading pretty much all the threads on the forums, things have cleared up a bit for me and I'm even more excited. I like the way SOUL explicitly doesn't want to handle GUIs. I'm sure I'll find a way to handle that.

What remains is the question of dev tools. I've seen you use an editor in the keynote, but the only way I found to get syntax highlighting is using the online lab. Is there other support for the language in IDEs?