Replies: 3 comments 4 replies
-
|
Hi @smoge thanks for your comments! You might be interested in checking the amazing work of @charlesneimog integrating Python in OM#: https://github.com/charlesneimog/OM-py |
Beta Was this translation helpful? Give feedback.
-
|
Another interesting pointer: OMCollider (not working on OM# as far as I know) |
Beta Was this translation helpful? Give feedback.
-
|
This is interesting, but this project is not a supercollider client. It just output textfiles. A language client communicates via OSC in realtime with the synthesis server. There are many examples of alternative clients. What could limit the possibilities is how the scheduling clock in OM# works (I don't know details about it). The second best option would be to output a binary osc file for NRT synthesis, which would be still better then the omcollider project. This options I'm sure is totally possible to implement, it's not so complicated. In sclang, one can do this way: https://doc.sccode.org/Classes/Score.html |
Beta Was this translation helpful? Give feedback.
-
|
The first thing that might be a big project for another dev would be to turn Om# and a real client of the synth server. But I'm not sure the scheduler can hold this talk. (Just for reference, there are Scheme and Common Lisp clients for scsynth (supercollider server). What would be simple would be producing binary OSC files for non-realtime-synthesis? SuperCollider is still the best synthesis engine we have. I would include it in the to-do list. |
Beta Was this translation helpful? Give feedback.
-
|
A SuperCollider client for CommonLisp. https://github.com/byulparan/cl-collider Scheme: https://rohandrape.net/?t=rsc3 And a list of other clientes: https://github.com/supercollider/supercollider/wiki/Systems-interfacing-with-SC |
Beta Was this translation helpful? Give feedback.
-
|
But if OM# can be a client of scynth/supernova, that would bring the most advanced real-time synthesis engine to the project, with real-time control via OSC. Not simple because you would need to have in the language every UGen and all basic OSC commands, |
Beta Was this translation helpful? Give feedback.
-
|
SuperCollider has already a client in CommonLisp, it's ready! |
Beta Was this translation helpful? Give feedback.
-
@j-bresson
The integration of objects with user-defined functions in this new project is truly remarkable, showcasing seamless interoperability that I find quite impressive. It addresses people with much more diverse backgrounds. And avoids the odd situation with OM of annoying composers with little or intermediate (or higher) computing knowledge, at the same time for different reasons.
My curiosity is piqued by Common Lisp's capacity for Foreign Function Interface (FFI) with programming languages like Haskell and Python. I am particularly interested in exploring the depth of compatibility and interaction achievable between Common Lisp and these languages. This inquiry extends beyond mere in-program interactions to include the feasibility of setting up communication channels between processes executed in both languages.
In pursuit of this understanding, I have initiated some experimental tests aimed at establishing an interface with Haskell. Intriguingly, Haskell serves as a client for the SuperCollider audio server (if sclang is not interfaced as well), presenting a unique opportunity for integration.
Another idea is just use real-time or NRT synthesis directly with scsynth (or supernova for massive parallel synthesis nodes), using OSC.
This new sfotware appears to be the beginning of an innovative path, brimming potential for many things such those I mentioned. It feels fresh, and I would be glad to see it going much further than OM.
Bernardo
Beta Was this translation helpful? Give feedback.
All reactions