Re: [sc-users] Graphics, Video and SC

[crucial felix <felix@xxxxxxxxxxxxxxxxxxx>]

On Jan 3, 2006, at 9:47 AM, JostM wrote:
> The really big issues, it seems to me, is that int the end, it  
> becomes necessary to split things up between several computers, and  
> then things get rather complex . If I have an  installation in SC,  
> then somehow I have to tell my graphics programs which busses to  
> poll, etc.

I have thought a bit about this stuff recently.

The cleanest separation is to get the  pro55ecing/flash etc. app to  
send a message to an OSC address like :

/play
/stop

/agents/new "ralph" 23 0.1 0.05
/agents/spawn "ralph"
/agents/stop "ralph"

/players/play "path/to/player" "an-id"
/players/stop "an-id"

this is the way OSC is actually designed to be used : the addresses  
are nodes in a tree.  SC let's you set up handlers to those different  
node addresses.

then you can get the SC app itself to handle these messages and do  
whatever it needs to do to send to the sc server. so its a relay : SC  
app handles the request and then communicates with the scsynth.  thus  
the graphics app doesn't need to know about scsynth's OSC language  
(or write a lot of code).

its the way web APIs are structured.  it lets you later switch the  
underlying implementation or even the whole programming language.
but the API as expressed in these messages is fixed.

it also means you could have several different graphics apps using  
the same API with no extra work.

the problem would be that a real time control would have too much  
latency.  the solution then would be to have the graphics program ask  
SC to assign a bus :

/assign/bus "/assign/receive"  <- this is the callback

SC would then assign a bus and send a returning OSC message with that  
bus number and maybe also the full address of the sc synth (so that  
the flash etc. app doesn't need to hardcode or configure that)  then  
the graphics app can send its slider messages directly to it.

the flash etc. app should only have one configured relationship :  
with the SC app.

> If the intallation is constantly dynamically allocating and freeing  
> busses, is the solution then to have all of the programs  
> communicate with each other over OSC. Does that work smoothly? Has  
> any one here had experience with this yet?

there really aren't any OSC receiving handlers in the SC app other  
than the basics for getting stuff from the server.

this API for getting busses (and synth IDs) assigned could be really  
useful.
also good for multi-client SC pieces

with a simple dispatcher script in php or python or ruby you could  
set up SC on a web server and translate request URLs directly into  
OSC messages that are then sent to the SC app running on that server.

http://server.com/sc/assign/bus
the handler function would then return the bus number as text, and  
Flash would easily get the response.


> If anyone has had experience with this yet, I think quite a few SC  
> users might be interested.
> I'm looking into this stuff more closely at the moment, and will  
> also report back soon, perhaps with a vew examples.
>
>
> jostM
> _______________________________________________
> sc-users mailing list
> sc-users@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-users