[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