You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So the question is, would we be better using the API quark in superdirt, rather than continue rolling our own API? One complication is that scapi seems to only communicate with sclang, not scsynth, but I could be wrong about that.
The text was updated successfully, but these errors were encountered:
The API Quark is reliable, I'd be fine with relying on it. I've never used it, and have little time at hand currently, but I can help if you want to start something.
#190 and #199 involve making an OSC-based protocol between tidal, sclang and scsynth.
There's also the RMS stuff #74
For the latter, @shawnlawson is looking at getting access to the RMS data from javascript for Atom integration, as well as communicating with the https://github.com/tidalcycles/tidal-listener OSC API with Tidal.
Talking with sclang/scsynth needs some fairly low level socket operations, which https://github.com/crucialfelix/supercolliderjs/ has solved, so we're looking at that. supercolliderjs speaks to supercollider via the API quark https://github.com/supercollider-quarks/API via its scapi sub package https://github.com/crucialfelix/supercolliderjs/tree/develop/packages/scapi
So the question is, would we be better using the API quark in superdirt, rather than continue rolling our own API? One complication is that scapi seems to only communicate with sclang, not scsynth, but I could be wrong about that.
The text was updated successfully, but these errors were encountered: