The problem here is not how to communicate via OSC to Supercollider, OSC is actually a simple to implement protocol.
When I bought Pharo By Example I also bought the Supercollider book. To put things in perspective that book is 700 pages long and twice in width compared to the Pharo By Example book. And like Pharo By Example , its just an introduction to SuperCollider. SuperCollider is a monster. So again we go back to the "IT DEPENDS" phenomenon , the real question is what you want to do with it. Anything is doable. Hard is just something that take more time than something that is easy. And thats its. You CAN do anything you want if you commit to it and willing to spent the time. I decided to postpone making Orpheas (Interface to SuperCollider) because I wanted first to have good progress with Morpeas (a replacement of Morphic based on opengl). This is the issue here. If you want to create tools that people will use , especially music tools you need fancy easy to use GUIs. An average user is unlikely will be willing to sit down and learn SuperCollider cause it does a lot more than he wants. He most likely will want to use familiar music tools and that means you will need to build a lot of GUI tools. Cause SuperCollider is a programming language in the end not a GUI tool (though it has many GUI tools). I think a sound practice here (pun intended) is not to ditch SClang. There tons of tools that are made with SClang , so my initial plan was to have a trio SuperCollider [server] - Sclang - Pharo. Server as the audio engine, sclang for all the nice supercollider tools already available and Pharo for the GUI part (using Morpheas). Also Supercollider is far from the only option here, I have found similar solution for PD (aka Pure Data) which like supercollider is realtime and it uses a flow chart based interface to create its presets (nodes connected with cables) its commercial counterpart is the very popular MAX/MSP. And of course there are tons more other options too out there. I was even considering making a VST/AU bridge , so that users could use already familiar tools. 99% of modern music nowdays passes and/or is made with VST/AU synths and audio effects so having that is a huge plus. Again VST is a simple C API to implement but still needs someone to actually sit down and implement it. Bottom line is that all these things take A LOT of time, its not the kind of projects that you finish in a week or a month , they can easily take years (or decades). So it depends on you and how deep you want to go in the rabbit hole. Interfacing with OSC and Supercollider is only the start of the journey. On Monday, 21 October 2013, 3:06, Paul Davidowitz <[email protected]> wrote: SqueakMap for OSC (http://map.squeak.org/sm/accountbyid/13fa7a75-1e76-471e-8f42-b676f4d8e373/package/61f807be-83a3-4944-bfa1-686ddac7153c) states: One can remote control supercollider and other sound generators implementing OSC using UDP. Release 2-1.1 - Now even runs with Supercollider! So, it looks like the work has already been done!
