4 ms·

What a crazy coincidence. I just spent the last couple of days doing a survey of audio engines with a mind to find those that could run in wasm. Did you write

What a crazy coincidence. I just spent the last couple of days doing a survey of audio engines with a mind to find those that could run in wasm. Did you write your own engine or are you built on top of csound, supercollider, ChucK or something else? How do you compare against the higher level or pattern based implementations like Sonic Pi, Tidal Cycles, Overtone and Cabbage Audio? How about libraries like LibPD or even Max/MSP? I was even considering this space myself and on my list of todo's was checking out the licenses of the above to see what the ramifications of deploying a commercialized version of them would be. However, I must admit that the market for audio software is incredibly split. On the one end are the high-end audio effects with eye-watering prices. On the other OSS end many of the devs are literally begging for scraps on Patreon barely making enough to survive. There doesn't seem to be an in-between. I am very curious what you believe your market will be.

chaosprint 5y ago
You should check Glicol: https://github.com/chaosprint/glicol https://github.com/chaosprint/glicol For the marketing part, frankly speaking, I don't know. Since most of these projects you mentioned are based on academics, including myself.
- reggieband 5y ago
  I definitely did checkout Glicol, sorry I didn't call it out along with the others but I wanted to focus one the "uses existing old-school C/C++ audio engine compiled to wasm as a server" question. I understand you wrote your own custom engine in Rust. I saw your post in the comment section related to Overtone and was actually going to reply saying to you that I appreciated your work. I think I watched all of your Youtube video demos, even the ones on QuaverSeries. The other small project that was interesting to me (that seems to have partially disappeared) was Sporth. The webpage for that has an unfortunate message saying the project was taken down to respect csound community.
  - chaosprint 5y ago
    Wow, thanks for your interest! I haven't maintained QuaverSeries for a while as I kinda feel that there are some issues on Tone.js that cannot be fixed in the foreseeable future. For the topic you are interested (C++ audio engine as WASM), you should check these two: https://github.com/frantic0/sema-engine https://github.com/frantic0/sema-engine https://github.com/micknoise/Maximilian https://github.com/micknoise/Maximilian For those language you mentioned csound, supercollider, Chuck (should add Faust here), I think these languages focus more on different music programming philosophy. Of course, SC is probably the most famous for reusing its audio engine for other high-level langs like the Tidal, Sonic Pi you mentioned. Also, SuperCollider's scsynth can run in browsers now: https://scsynth.org/t/webassembly-support/3037 https://scsynth.org/t/webassembly-support/3037 If you are interested, https://strudel.tidalcycles.org/ https://strudel.tidalcycles.org/ is an ongoing work to port Tidal to browsers. Perhaps at some point it can be connected with Glicol audio engine.
    - reggieband 5y ago
      That supercollider/scsynth wasm thing was actually what I was thinking about. Unfortunately the implementation is still in a fork and hasn't been merged upstream. [1],[2] Thanks for the other links, sema-engine was new to me and not in my original investigation. I think I skimmed over Maximilian but it is probably worth a closer look. One of the benefits of csound/supercollider in my mind are their existing communities and the number of available open source modules. I've seen entire repos full of .scd definitions which would give any project starting with supercollider as its engine a big head start. The main downside is the esoteric languages these projects tend to use, which is why I think there are so many projects that build on top of it. This is one of the benefits of the client/server model I suppose. I also agree that this whole area is full of different philosophies. At the low end you have straight DSP kind of stuff which is mostly floating point buffer manipulation, FFTs/convultions, etc. and at the other you have sequencers, scale pattern generators and composition tools. And of course the live performance aspect comes into play as well as interfacing/syncing with devices/DAW using OSC/Midi. I'm very excited to see where it all is going to end up. 1. https://github.com/supercollider/supercollider/issues/5224 https://github.com/supercollider/supercollider/issues/5224 2. https://github.com/supercollider/supercollider/pull/5571 https://github.com/supercollider/supercollider/pull/5571

chaosprint 5y ago

You should check Glicol: https://github.com/chaosprint/glicol https://github.com/chaosprint/glicol For the marketing part, frankly speaking, I don't know. Since most of these projects you mentioned are based on academics, including myself.

reggieband 5y ago
I definitely did checkout Glicol, sorry I didn't call it out along with the others but I wanted to focus one the "uses existing old-school C/C++ audio engine compiled to wasm as a server" question. I understand you wrote your own custom engine in Rust. I saw your post in the comment section related to Overtone and was actually going to reply saying to you that I appreciated your work. I think I watched all of your Youtube video demos, even the ones on QuaverSeries. The other small project that was interesting to me (that seems to have partially disappeared) was Sporth. The webpage for that has an unfortunate message saying the project was taken down to respect csound community.
- chaosprint 5y ago
  Wow, thanks for your interest! I haven't maintained QuaverSeries for a while as I kinda feel that there are some issues on Tone.js that cannot be fixed in the foreseeable future. For the topic you are interested (C++ audio engine as WASM), you should check these two: https://github.com/frantic0/sema-engine https://github.com/frantic0/sema-engine https://github.com/micknoise/Maximilian https://github.com/micknoise/Maximilian For those language you mentioned csound, supercollider, Chuck (should add Faust here), I think these languages focus more on different music programming philosophy. Of course, SC is probably the most famous for reusing its audio engine for other high-level langs like the Tidal, Sonic Pi you mentioned. Also, SuperCollider's scsynth can run in browsers now: https://scsynth.org/t/webassembly-support/3037 https://scsynth.org/t/webassembly-support/3037 If you are interested, https://strudel.tidalcycles.org/ https://strudel.tidalcycles.org/ is an ongoing work to port Tidal to browsers. Perhaps at some point it can be connected with Glicol audio engine.
  - reggieband 5y ago
    That supercollider/scsynth wasm thing was actually what I was thinking about. Unfortunately the implementation is still in a fork and hasn't been merged upstream. [1],[2] Thanks for the other links, sema-engine was new to me and not in my original investigation. I think I skimmed over Maximilian but it is probably worth a closer look. One of the benefits of csound/supercollider in my mind are their existing communities and the number of available open source modules. I've seen entire repos full of .scd definitions which would give any project starting with supercollider as its engine a big head start. The main downside is the esoteric languages these projects tend to use, which is why I think there are so many projects that build on top of it. This is one of the benefits of the client/server model I suppose. I also agree that this whole area is full of different philosophies. At the low end you have straight DSP kind of stuff which is mostly floating point buffer manipulation, FFTs/convultions, etc. and at the other you have sequencers, scale pattern generators and composition tools. And of course the live performance aspect comes into play as well as interfacing/syncing with devices/DAW using OSC/Midi. I'm very excited to see where it all is going to end up. 1. https://github.com/supercollider/supercollider/issues/5224 https://github.com/supercollider/supercollider/issues/5224 2. https://github.com/supercollider/supercollider/pull/5571 https://github.com/supercollider/supercollider/pull/5571