I think if people want to discuss the matters of AI, it deserves it’s own thread…
Unless AI mechanisms will become a language feature of SOUL.lang, which I doubt 
1 Like
Agreed 
Appart the fact that compilation approaches are entering the AI + machine learning scene, like SOUL for the audio languages domain (see https://www.c4ml.org). Since a bunch of the brightest engineers are going there, some ideas and developments are probably to be interesting to follow.
1 Like
I’m thinking about rewriting our old and ugly LLVM backend still using LLVM C++ API. Jules, are you using the LLVM C API in the SOUL runtime? Or the C++ API one? (stil not clear if the C API covers everything we may need…)
We’re using the C++ one - TBH we never even looked at the C one or how it works.
The C one is a bit higher level, and is supposed to be more stable… (One of the real pain using LLVM is the possible API break at each version…
) I recently took the C API in a simpler case, and it was much easier to use. But then I’m not sure it covers everything I’ll need in the real LLVM backend… I’ll continue to investigate.
I never managed to find the proper APIs in the C interafce, as it’s more geared towards tooling rather than code generation 
I’m using the LLVM C API to do code generation and JIT compilation here. It works quite well, but IR manipulation needs are not high in this case.
The reply to the above doesn’t seem to be addressing this point about midi processing. Rather it’s about the ‘let’ syntax. I’d also be interested in seanwayland’s idea about a simple per-event way of processing midi events.
I’m not actually sure I understand what the original question was asking/commenting on… SOUL does deal with events (MIDI or otherwise) as callbacks which you handle, it doesn’t use block-based processing like JUCE does, so I think it probably does exactly what he/you have in mind. Have a look at some of the example synth code and that’ll maybe make it clearer?
1 Like
Ah, OK, Excuse me, I realise now that this is inside the SOUL Lang forum, but I think seanwayland was referring to midi processing inside JUCE rather than soul. Actually, I was searching for information about midi processing in SOUL when I came across his post.
I think he was saying “I hope event processing in SOUL is less confusing than in JUCE” and the answer is “yes!”
1 Like
Cool, thanks!
Do you think I might be able to use SOUL and target this platform?
I would love to have a simple language to create stuff and to leave my computer at home!
1 Like
Yep, that’s absolutely one of the use-cases where we want to see it being used!
1 Like
Curious to hear if there are any updates as to when this might be released, now that we are in Q4.
Yes, we’ve been a bit quiet, but there’s a ton of work in progress, and we’re gearing up to let something out to the public before ADC in time for our SOUL workshop at the conference 
4 Likes
Awesome, can’t wait!
My apologies if this has been asked before, but I assume we will eventually be able to integrate Soul into JUCE? I mean how else would we be able to make our own GUI.
Well of course we’ll do plenty of tools that take advantage of JUCE/SOUL integration. But remember that the whole point of SOUL is that it’s dynamically JITed, so you can run it on any platform without needing a native compilation toolchain or build system. So if you don’t have to go through the hassle of natively compiling the DSP code, then to choose to use C++ just for its GUI would be a bit odd.
We’ll certainly support multiple formats for GUIs for SOUL patches, and will be fairly agnostic about what hosts choose to support, but would expect most people to write it in React or Javascript web-standards, or maybe simple declarative GUI framework using something like Lua.
1 Like