[OSC_dev] Managing different osc implementations

Jamie Bullock jamie at postlude.co.uk
Fri Feb 20 09:13:38 PST 2009


On 20 Feb 2009, at 14:56, Mr.SpOOn wrote:

> Jamie Bullock wrote:
>> I suggest you have a look at our documentation:
>>
>> http://www.integralive.org/dokuwiki/doku.php/screencasts
>> http://www.integralive.org/dokuwiki/doku.php/
>
> I watched the screencasts and took a look at the slides. This seems a
> really great project. And my idea is not original at all.
>
> Is it still active?

Yes, it's very much active in fact 'round 2' of the project will be  
starting in March.

> What are the real difficulties in "bridging" other
> applications other than PD and Max/MSP ?
>

There aren't any specific difficulties, it's just a matter of time.

>
> Damian Stewart wrote:
>> every application that uses OSC implements the protocol in the same  
>> way
>
> Reading this it seems to me that it should be an easy task. Obviously
> I'm wrong, but I don't understand why.
>
> What am I missing?

You're not missing anything. Except possibly that there are several  
approaches being referred to here. I would call what Damien is  
referring to as an 'ad hoc' approach. You simply define your OSC  
addresses as needed on your OSC server(s) and send messages to those  
addresses on the server from a given client. Simple!

However, there are a number of approaches emerging: openmediacontrol;  
oscit; Integra static methods; oscqs, which support a degree of  
service discovery. In addition, the idea behind libIntegra is that you  
could load a module in SuperCollider then load the same module in Max/ 
MSP and be *guaranteed* that it will have not only the same OSC  
address space, but the same parameter ranges and units. It does this  
by providing an abstraction layer between the client and the target  
environment. It seemed to me that this was what your original question  
was getting at, but maybe I'm wrong.

Jamie




More information about the OSC_dev mailing list