Managing different osc implementations

[Mr.SpOOn]

Hi,
I'm new to the opensoundcontrol world. I've just read some of the
documentation about osc, but I've never tried anything in practice, so
I don't really understand how it works, yet.

I'm interested in developing some kind of musical interface, maybe
with Processing, to put in sequence audio objects/events. The idea is
not that simple, but doesn't matter here. What I'd like to do is
something that can let me use different sound engines.

I mean: if I can program with SuperCollider, I can make sounds with it
and using them in this interface. But I'd like to have the same
possibility with ChucK, or anything else that can produce sounds - as
long as it supports osc communication.

Does exist something similar?
And what is the real problem? That every application (SuperCollider,
ChucK, PureData etc.) that uses osc implements it in a different way?

Would it be possible to write some sort of wrapper to manage all (or
at least many of) the different implementations? Maybe some Python
program put in the middle between the interface and the engine(s) to
make them communicate in every case.

Sorry if I am a bit confused and if these are stupid questions.

Hope you can help.

Thanks,
bye

Carlo
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jamie Bullock]

On 20 Feb 2009, at 10:30, Mr.SpOOn wrote:

> Hi,
> I'm new to the opensoundcontrol world. I've just read some of the
> documentation about osc, but I've never tried anything in practice, so
> I don't really understand how it works, yet.
>
> I'm interested in developing some kind of musical interface, maybe
> with Processing, to put in sequence audio objects/events. The idea is
> not that simple, but doesn't matter here. What I'd like to do is
> something that can let me use different sound engines.
>
> I mean: if I can program with SuperCollider, I can make sounds with it
> and using them in this interface. But I'd like to have the same
> possibility with ChucK, or anything else that can produce sounds - as
> long as it supports osc communication.
>

This is one of the goals of libIntegra. Currently we only have  
'bridges' for Pd and Max/MSP, but SC3 and Chuck are high on our list.

> Does exist something similar?
> And what is the real problem? That every application (SuperCollider,
> ChucK, PureData etc.) that uses osc implements it in a different way?
>
> Would it be possible to write some sort of wrapper to manage all (or
> at least many of) the different implementations? Maybe some Python
> program put in the middle between the interface and the engine(s) to
> make them communicate in every case.

I suggest you have a look at our documentation:

http://www.integralive.org/dokuwiki/doku.php/screencasts
http://www.integralive.org/dokuwiki/doku.php/

It's very alpha at the moment, comments welcome!

best,

Jamie

--
http://www.jamiebullock.com



_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Damian Stewart]

Mr.SpOOn wrote:

> Does exist something similar?
> And what is the real problem? That every application (SuperCollider,
> ChucK, PureData etc.) that uses osc implements it in a different way?

every application that uses OSC implements the protocol in the same way. i
don't know about ChucK or SuperCollider, but with Pd you have to define
your own naming system that runs over OSC anyway. for example, if you want
to control the cutoff for a lowpass filter on a 303 emulator, then you
decide that the message would be something like /303emu/lowpass/cutoff
<value> , then in Pd you just listen for that message. same in
SuperCollider, same in ChucK.

d

--
damian stewart | skype: damiansnz | damian@...
frey | live art with machines | http://www.frey.co.nz
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[salsaman-3]

On Fri, February 20, 2009 11:30, Mr.SpOOn wrote:

> Hi,
> I'm new to the opensoundcontrol world. I've just read some of the
> documentation about osc, but I've never tried anything in practice, so
> I don't really understand how it works, yet.
>
> I'm interested in developing some kind of musical interface, maybe
> with Processing, to put in sequence audio objects/events. The idea is
> not that simple, but doesn't matter here. What I'd like to do is
> something that can let me use different sound engines.
>
> I mean: if I can program with SuperCollider, I can make sounds with it
> and using them in this interface. But I'd like to have the same
> possibility with ChucK, or anything else that can produce sounds - as
> long as it supports osc communication.
>
> Does exist something similar?
> And what is the real problem? That every application (SuperCollider,
> ChucK, PureData etc.) that uses osc implements it in a different way?
>

This is also a goal of open media control:

http://openmediacontrol.wetpaint.com/

However, despite the fact that many people _claim to be interested in
this_, debate there seems to have died off...

If we could agree the major points, then it would be a fairly simple
matter for any application to implement it.


Regards,
Salsaman
http://lives.sourceforge.net


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Mr.SpOOn]

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? What are the real difficulties in "bridging" other
applications other than PD and Max/MSP ?


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?
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Damian Stewart]

Mr.SpOOn wrote:
> 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 missing nothing. it's a very easy task. decide what you want to
communicate, decide on a message format for each communicated value in the
form /word/word/word <value> <value> <value> ... , and you're away. i've
used OSC for three years now and, for daily use on personal projects, i
still don't see any value in engineering some kind of ur-structure like is
being offered around here...

--
damian stewart | skype: damiansnz | damian@...
frey | live art with machines | http://www.frey.co.nz
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jamie Bullock]

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


_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jamie Bullock]

On 20 Feb 2009, at 11:40, salsaman@... wrote:

>>
>> Does exist something similar?
>> And what is the real problem? That every application (SuperCollider,
>> ChucK, PureData etc.) that uses osc implements it in a different way?
>>
>
> This is also a goal of open media control:
>
> http://openmediacontrol.wetpaint.com/
>
> However, despite the fact that many people _claim to be interested in
> this_, debate there seems to have died off...
>

I don't think people have lost interest (I certainly haven't). It's  
just that Gaspard came up with a good suggestion to test some of these  
ideas in practical implementations. I think this is a good idea, since  
we will surely find problems with the protocol(s) as we test them in  
practice. I don't see a problem with 2-3 similar protocols evolving in  
parallel so long as we keep the lines of communication open (sic) and  
ultimately converge on one of them.

> If we could agree the major points, then it would be a fairly simple
> matter for any application to implement it.

Agreed. We're not talking about a massively complex extension to OSC  
here.

Jamie


--
http://www.jamiebullock.com



_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Mr.SpOOn]

2009/2/20 Jamie Bullock <jamie@...>:
> 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.

Yes, this is exactly what I had in mind.

It's just that I needed to work on a project like this for a thesis.
But my teacher wants something original, so I suppose I have to search
for something else.

Thanks for you help :)
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Sciss-3]

stupid question: why would you want to try to do in SuperCollider  
exactly what you do in Max/MSP? these system are so fundamentally  
different that i cannot imagine why i would need the same addressing...

ciao, -sciss-


Am 20.02.2009 um 18:13 schrieb Jamie Bullock:

>
> 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
>
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jeff Glatt]

> I'm wrong, but I don't understand why.
> What am I missing?

What you're missing is something that the Open Sound Control
specification doesn't explicitly state, which is the following:

1) It has nothing whatsoever to do with sound. Its name is a
misnomer, since there is not even a mention of sound in the
specification other than the use of the word "sound" in the
name of the protocol itself. It should really be called "Open
Data-packing", not "Open Sound Control".

2) All Open Data-packing... err... Open Sound Control...
does is specify a way to pack up a bunch (ie, any amount) of
data values (in the form of C primitives -- ie, 32-bit and 64-bit
ints, nul-terminated 8bit strings, floats, doubles, etc) into one
"block" of data. That's all it is. It doesn't define any other
standards. For example, it doesn't define any standard set of
messages for actually controlling sound. It doesn't even specify
how to exchange/deliver/save that block of data. For example,
one entity could transmit OSC messages over an ethernet
port, and another entity could transmit messages over a serial
port. Obviously, those two entities can't communicate with each
other without some sort of hardware adapter.

In other words, Open Sound Control does absolutely nothing
useful on its own. In order to do something useful, some
device/program that uses OSC therefore has to decide for itself:

1) What data values are put into any given OSC message,
and what those data values mean. In other words, each entity
has to come up with its own proprietary set of OSC-formatted
messages. Yes, each OSC entity can receive _any_
OSC-formatted message and pull the data values out of it. But
what does it do with those values? Unless it recognizes the OSC
path of that message as something it happens to know about,
it can't know what to do with the message. And of course, since
each entity defines its own OSC messages (ie, it own set of
recognized path strings), an entity can't know what to do with
a given message unless the sender is written to send only those
messages that are recognized. (ie, The two entities have to be
written to use the same set of proprietary OSC-formatted
messages).

2) How to transmit those messages -- over an ethernet port
using TCP, or maybe UDP, or a serial port, or a USB port,
etc.

Because there's no standardization for the above 2 design
decisions, that's why each OSC-enabled entity ends up with its
own set of proprietary messages (that just happen to include a
bunch of C primitive datatypes packed according to Open
Sound Control). So two entities can't do anything useful with
OSC unless they are specifically written to use the same set of
proprietary messages. (That's the part that you're missing. You're
thinking that OSC is more than what it is, in order to be practical
as a standard. It isn't. It isn't useful by itself. It _must_ be
combined with other standards, even if those additional
standards are proprietary, before it can do anything practical).

There have been some people who have attempted to come up
with additional standards (in the form of some standardized sets
of OSC messages, such as "Open Media Control", oscit, etc).
But none of these has found a foothold, because the fact of the
matter is that, all the people currently using OSC, seem content to
have their own proprietary sets of messages, and basically just
use OSC as some sort of "scripting language" (ie, a way to allow
some other programmer to write a utility that specifically works
with a particular proprietary set of OSC messages). For example,
the author of PD/Max doesn't care if some third party utility
works with every other app that does basically what PD/Max
does. He cares only that the 3rd party app supports PD/Max --
not his competitor's stuff. And the author of "Super OSC App"
isn't worried about whether some 3rd party app supports
PD/Max. What he cares about is that the 3rd party supports
Super OSC App.

So OSC is not currently used for "interoperability". It's used only
as a way to pack up proprietary data.

I know what you're thinking. "Shouldn't an open standard be
concerned with interoperability? For example, what happens if app
A and B both define their own proprietary OSC message with
a path of /MyMessage, but the 2 messages contain entirely
different datatypes, and amounts of data?". Well, you'd better
hope those apps do really, really, really rigorous data checking
or they're going to do horrible, and perhaps destructive, things.
Actually, now that I think about it, given the existing implementations
and uses of OSC, I think the standard probably should be named
"Proprietary Message Data-packing".

If you found this message informative, then you may want to
look at my OSC library at:

http://home.roadrunner.com/~jgglatt/tech/easyosc.zip

The docs (and sources) for it will definitely help explain in more
detail what OSC is, and more importantly to you, what it isn't.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jamie Bullock]

On 20 Feb 2009, at 20:25, Sciss wrote:

> stupid question: why would you want to try to do in SuperCollider
> exactly what you do in Max/MSP? these system are so fundamentally
> different that i cannot imagine why i would need the same  
> addressing...
>

I was only using Max/MSP and SC as examples. The point is that there  
is functionality that is common to the range of Music-N derived  
languages for multimedia/audio programming, and libIntegra provides a  
way to define and address this functionality in a standardised way. It  
also provides a means to wrap functionality that is not common between  
environments and to spread module collections between environments so  
we can take advantages of their unique strengths.

SpectralDelay   <- standard module
|
SpecialEsotericSC3SpectralDelay <- inherits the interface of  
SpectralDelay but adds some special attributes unique to SC3.

The point is to standardise *representation* not to standardise usage  
or functionality.

Jamie

>
> Am 20.02.2009 um 18:13 schrieb Jamie Bullock:
>
>>
>> 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
>>
>>
>> _______________________________________________
>> OSC_dev mailing list
>> OSC_dev@...
>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Sciss-3]

ah ok...

Am 21.02.2009 um 13:50 schrieb Jamie Bullock:

> The point is to standardise *representation* not to standardise usage
> or functionality.

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[IOhannes m zmölnig]

Jeff Glatt wrote:
[...]
> For example,
> the author of PD/Max doesn't care if some third party utility
> works with every other app that does basically what PD/Max
> does. He cares only that the 3rd party app supports PD/Max --

how does this refer to the OSC-implementations in Pd or Max?
the author of Pd/Max hasn't even started using OSC as a network protocol
yet; instead he is still using FUDI;
or are you referring to the people who have written OSC implementations
for Pd and/or Max? these implementations (at least those i i know) are
generic and don't know anything about 3rd party apps, do not impose any
limitations on OSC-paths;
are you also implying that the implementors of the TCP/IP stack on (pick
your favourite OS) did not give a shit on interoperability with other
OSs, just because you cannot transport any meaning on the transport layer?
or are you talking about authors of applications written in Pd and/or
Max? but why do you call them "author of PD/Max" then?

don't know where to put this in this mail:
OSC is not on the application layer, but slightly below it.
oscit, OMC and however they are all called are application layer
protocols, on top of OSC.


sorry. couldn't resist...


fgamdrs
IOhannes
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[IOhannes m zmölnig]

IOhannes m zmoelnig wrote:
> sorry. couldn't resist...

and i guess i should have a look at the date before replying :-)

fgmasdr
IOhannes
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev