julesrms

9 ms·

61.
by julesrms 6y ago
Right now, we haven't got an official position on how we'll handle the back-end licensing, but it's a sensible assumption is that we'll have an open-source reference implementation that people can use, and then our own o
62.
by julesrms 6y ago
Our "Minimum Viable Piano" example is a multi-sampled piano, which should show you how it works: https://soul.dev/lab/?id=MinimumViablePiano
63.
by julesrms 6y ago
Why COM? Well, I hate COM in general, but it was a much better fit for this particular API than flat C functions. It comes with a bunch of C++ helper classes to make it easy to work with, and the resulting code actually ends up looking OK.
64.
by julesrms 6y ago
Well, as the person who also created JUCE and its license, I can't really argue with that. :) We're very keen to make sure that the end-user developers are totally unencumbered and license-free, because we want lots of people to a
65.
by julesrms 6y ago
Full support for wide streams (i.e. streams of overlapping windowed blocks, suitable for frequency-domain work) is still to-do (though we've planned for it all along!) We've tried to make embedding it as easy as possible - there&#
66.
by julesrms 6y ago
The patch format is for the same use-case as VST, AudioUnit etc, where OSC isn't really a thing. OSC is more something you'd want to use for a stand-alone program, which needn't be written as a patch. But yes, would be nice t
67.
by julesrms 6y ago
We have two user-bases in mind: - end-user developers. This is kind of like being a user of any other language, there's no EULA, nothing to sign, you just write SOUL code, test and debug it with whatever tools (which may themselves hav
68.
by julesrms 6y ago
Joke answer: the bits that aren't in there. Real answer: Mainly the JIT engine, and the very complex rewriting algorithms that turn multi-threaded soul code into a form that can actually be executed. We're certainly keen to open-s
69.
by julesrms 6y ago
Yes - the command-line tool will take a SOUL patch and emit a full, ready-to-build JUCE project that will create all the plugin formats (and a standalone app).
70.
by julesrms 6y ago
We've had it running on Bela for ages now. This year we'll be releasing the SOUL network protocol, so that we can properly control remote "SOUL venues" on hardware like Bela (our current Bela network is a bit of a bodge
71.
by julesrms 6y ago
> Can I use SOUL to create freestanding interactive performance environments a la Pure Data? SOUL does have a JIT compiler and you can live-code it, and you can certainly use it to write programs that generate musical patterns etc.. So s
72.
by julesrms 6y ago
There's plenty of code to see! Our playground site has been up and running since 2019, and people are already developing products with SOUL. https://soul.dev/examples/ EDIT: ah, I misunderstood you.. You mean you&
73.
by julesrms 6y ago
Well, that's just a press release page, but it does have a link to the examples: https://soul.dev/examples/ You can also browse the example code on the github: https://github.com/soul-lang/SO
74.
Show HN: SOUL Language 1.0 – A platform for writing and running audio code(soul-lang.github.io)
119 points by julesrms 6y ago|81 comments
75.
by julesrms 7y ago
OK, fair point! Maybe a better way for me to phrase what I meant there would have been "pretty much all mainstream languages are out"
76.
by julesrms 7y ago
There'll actually be many ways of using it.. Javascript in a browser is just one of those ways. The real API is written in C++ and we'll be offering a C binding in many languages, which you'll use in a pretty similar way to h
77.
by julesrms 7y ago
Yes, we already have a prototype C++ generator as a command-line tool, so mixing that with some boilerplate to build a plugin will be something we do soon. And yes, the same thing would also work nicely if hosted as a web-service
78.
by julesrms 7y ago
This has been a great thread, thanks for all the comments! One final note I'd like to add is that we've also been running a closed early-adopter group for industry insiders, where we're sharing some other non-web tools includ
79.
by julesrms 7y ago
WASM will probably start catching up with natively-compiled C++ eventually, but we're working on the hypothesis that even natively-compiled C++ can't quite get the best performance out of audio hardware, because running it on the
80.
by julesrms 7y ago
oh.. I should also mention that we don't expect it to replace all the other audio systems and languages that are already established and have large user-bases. (At least not overnight ;) ) ..but we are attempting to do something that n
81.
by julesrms 7y ago
At a high level it might seem like that, but there's a big difference between "fast" and "realtime". We need to go fast, but the main problem the language needs to solve for us is to break the work down into a stead
82.
by julesrms 7y ago
We pre-emptively answered this inevitable question in the overview doc: https://github.com/soul-lang/SOUL/blob/master/docs/SOUL_Over... The main TL;DRs are: - this needs to get JITed to compete with
83.
by julesrms 7y ago
Have a read of the FAQ and overview docs, or watch the talk: https://github.com/soul-lang/SOUL The browser-based stuff is just a demo to let people explore the language and learn about what we're trying to do. The
84.
by julesrms 7y ago
thanks for the offer but I think we're a bit overloaded with URLs right now!
85.
by julesrms 7y ago
Yeah, this is on our to-do-list!
86.
by julesrms 7y ago
Yep. And even for very simple audio loads, there's often unused capacity in compute cores (even when running games) which would could do the job "for free" without bothering the CPU.
87.
by julesrms 7y ago
Yeah, we made both of those assumptions. But it's apparently less true of the latest generation of compute engines. We probably won't bother with CUDA, but Metal is certainly a viable platform to try. It's one of those things
88.
by julesrms 7y ago
Audio dev has always been insanely hard - that's part of the motivation behind creating this! It's hard because you need some serious mathematical skills to understand the DSP itself (that's the bit I'm lacking in..). Th
89.
by julesrms 7y ago
I think we'll probably want hot-reloading of sub-graphs in a larger graph, but that'll be a project for 1-2 years down the line when we're more involved in building DAW engines using it. Re: building a 3rd party back-end, I g
90.
by julesrms 7y ago
Our original thoughts on that was "nah, that'd be silly because GPUs are the wrong shape for audio workloads" ..however, having a few conversations with more knowledgable people has changed our mind and we're definitely

More ›