4 ms·

Congrats Jules :) What's the latest on using SOUL with platforms like Faust and Bela?

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 to get it running). Faust has also had SOUL support for a while. Not sure what's new over there but maybe Stephane will see this and comment :)
- jarmitage 6y ago
  Nice, it's great to see this project go from C++ rant to reality. Can't wait to never write C++ ever again :) On licensing, how will it work for creators of open source hardware? Will they still need to pay a licensing fee if they are targeting a specific device with closed driver IP? Or could there be an exception there? Do you also see yourselves supporting open low-level hardware (RISC-V, FPGA, ...?), and in that case would you consider opening your driver IP for those targets?
  - justforyou 6y ago
    Please answer the above questions.
  - naewonawonga 6y ago
    Very important questions, deserving of an answer.
  - 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 optimised or custom versions that we can license. RISC-V is an easy one to support, as our JIT uses LLVM so it's just a case of adding a build flag for that. FPGA is more interesting. I think there could be some really clever tricks we can do for soul programs which are highly parallel, but that kind of rocket-science stuff is probably going to have to wait until we have a couple of PhD students to work on it :)
    - justforyou 6y ago
      Great ideas, and a road paved with good intentions. A lot of people have been down this road before, and it doesn't end well for the users. At least your lawyers are happy.
cesaref 6y ago
Hi there, the faust binaries include a faust2soul command which from faust dsp generates a soulpatch. We include a bela build of the soul command line tool (it's basically a tech demonstrator of the JIT and a backend). So at this point, the bits are all out there to take a faust.dsp file and JIT it on Bela.
- jarmitage 6y ago
  Ah, I wasn't thinking of combining Faust and Bela like that, but that raises an interesting possibility. So you're saying it should be technically feasible to live code/hot reload faust.dsp on Bela with no glitching?
  - cesaref 6y ago
    Yes, the soul command when playing a patch watches for updates and recompiles when changes are found (then it switches across from the current DSP to the new one when compilation is complete). This isn't totally seamless, as although parameters are retained, any state held within the DSP code (say delay lines) will be reset to initial conditions, but it's pretty good. So then, update your faust code, re-run faust2soul and the soul command will see the updated patch and recompile.
    - jarmitage 6y ago
      Oh boy :~) Even though this already sounds great, hot swapping state would be the really big deal here. Do you think the Faust program itself might be able to save/load state somehow?
      - cesaref 6y ago
        faust isn't in the loop at that stage. Saving/restoring state will be something the soul driver will have to do, and of course, this will then mean this ability works for all code using the driver, not just faust sourced soulpatches. We've sketched out how this would work, and it's on the project backlog as something we want to support, so at some point we'll improve this area of the runtime.

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 to get it running). Faust has also had SOUL support for a while. Not sure what's new over there but maybe Stephane will see this and comment :)

jarmitage 6y ago
Nice, it's great to see this project go from C++ rant to reality. Can't wait to never write C++ ever again :) On licensing, how will it work for creators of open source hardware? Will they still need to pay a licensing fee if they are targeting a specific device with closed driver IP? Or could there be an exception there? Do you also see yourselves supporting open low-level hardware (RISC-V, FPGA, ...?), and in that case would you consider opening your driver IP for those targets?
- justforyou 6y ago
  Please answer the above questions.
- naewonawonga 6y ago
  Very important questions, deserving of an answer.
- 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 optimised or custom versions that we can license. RISC-V is an easy one to support, as our JIT uses LLVM so it's just a case of adding a build flag for that. FPGA is more interesting. I think there could be some really clever tricks we can do for soul programs which are highly parallel, but that kind of rocket-science stuff is probably going to have to wait until we have a couple of PhD students to work on it :)
  - justforyou 6y ago
    Great ideas, and a road paved with good intentions. A lot of people have been down this road before, and it doesn't end well for the users. At least your lawyers are happy.

cesaref 6y ago

Hi there, the faust binaries include a faust2soul command which from faust dsp generates a soulpatch. We include a bela build of the soul command line tool (it's basically a tech demonstrator of the JIT and a backend). So at this point, the bits are all out there to take a faust.dsp file and JIT it on Bela.

jarmitage 6y ago
Ah, I wasn't thinking of combining Faust and Bela like that, but that raises an interesting possibility. So you're saying it should be technically feasible to live code/hot reload faust.dsp on Bela with no glitching?
- cesaref 6y ago
  Yes, the soul command when playing a patch watches for updates and recompiles when changes are found (then it switches across from the current DSP to the new one when compilation is complete). This isn't totally seamless, as although parameters are retained, any state held within the DSP code (say delay lines) will be reset to initial conditions, but it's pretty good. So then, update your faust code, re-run faust2soul and the soul command will see the updated patch and recompile.
  - jarmitage 6y ago
    Oh boy :~) Even though this already sounds great, hot swapping state would be the really big deal here. Do you think the Faust program itself might be able to save/load state somehow?
    - cesaref 6y ago
      faust isn't in the loop at that stage. Saving/restoring state will be something the soul driver will have to do, and of course, this will then mean this ability works for all code using the driver, not just faust sourced soulpatches. We've sketched out how this would work, and it's on the project backlog as something we want to support, so at some point we'll improve this area of the runtime.