zeroconf, namespace querying

[Stephen Sinclair]

Hello,

We've recently had a short discussion on the liblo mailing list
regarding a proposed patch to enable Avahi/Zeroconf support.
OSC servers created with liblo would announce themselves on zeroconf
with the service '_udp._osc'.

Some interesting comments followed, and the issue of namespace
querying was brought up.
(i.e., if you announce yourself on the network, some known way of
finding out what you can _do_ is quite useful.)

I thought I'd bring up the issue here, as this has become more of an
OSC issue than for any specific implementation.  These two points are
quite important for OSC, I think, because service discovery and
namespace querying are two functions often needed for OSC servers that
are not really yet standardized.  There have been several proposals,
but as far as I know nothing has been dubbed 'official' for the OSC
spec.  The longer this remains unofficial, the more people will
implement incompatible ways of solving these problems.

Now that we are considering adding zeroconf support to liblo, we'd
like to ensure it follows (or leads) some kind of standard that might
be compatible with other OSC implementations.

Some of the proposals thus far that I know of:

- Natually, OSC does not impose anything about what messages should do
what, however I think one of the original OSC papers suggested using
/namespace to enumerate accepted messages.  Unfortunately it didn't
specify what kind of message should be used as a response to the
/namespace message.

- The 2006 meeting minutes suggest using simply the address with a '/'
appended: http://opensoundcontrol.org/publication/nime-2006-osc-developers-meeting

- It also mentioned discovery via zeroconf which was later implemented
by Rémy Müller in the "oscbonjour" object for Max/MSP.

- Service discovery was mentioned in a paper I wrote last year with
Joseph Malloch:
http://www.idmil.org/_media/wiki/icmc2007_malloch_mapping.pdf

We implemented it using only OSC and a multicast port, instead of
going towards use of external services like ZeroConf.  Additionally
this solution addresses namespace querying via the /namespace message,
with a response containing Jamoma-like @-tagged parameters.

- Andrew Schmeder and Matt Wright proposed in 2004 using #-prepended
addresses to contain special commands such as #reply, #documentation,
#type-signature, to give information about namespaces.  This is
intentionally consistent with http GET queries.
http://opensoundcontrol.org/publication/query-system-open-sound-control

How have hardware vendors approached this problem?  I don't know about
the Lemur, but I know that in the case of the Kroonde, instead of
using any kind of announce support, it simply sends all messages to
'broadcast'.  (I don't know if this is configurable..)  This is
presumably with the expectation that the device will be connected over
a dedicated connection to a single computer or very small network.
While it definitely makes configuration easy, it would also horribly
flood any network one is tempted to connect it to.

In this liblo-devel thread, Lars Luthman suggests we should follow the
D-Bus introspection specification, which can be found here:
http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable

Also, Steve Harris suggests that we should use mDNS records to
announce more than just '_udp._osc', but include some descriptive
fields such as a URI with information on the service.
I don't really know enough about mDNS to say much more about this, so
I'll try to read up on it.

The thread on the liblo mailing list that I mention can be seen here
for your reference:
http://sourceforge.net/mailarchive/forum.php?thread_name=9b3e2dc20802212025m1d34fc3frcc974c00bba6b025%40mail.gmail.com&forum_name=liblo-devel

I think we need to open up and continue discussions on these topics if
we want to make OSC more generally useful as a messaging protocol.


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

[Andy W. Schmeder-2]

On Feb 24, 2008, at 1:14 PM, Stephen Sinclair wrote:

- The 2006 meeting minutes suggest using simply the address with a '/'

appended: http://opensoundcontrol.org/publication/nime-2006-osc-developers-meeting

The simplicity of this approach seems to be popular and it would probably work in many cases.

However there is a caveat to putting *any* sort of query system into OSC itself because it is not compatible with the isochronous transport.  (Oops!)

I personally favor an XML descriptor approach e.g. WSDL or the D-Bus introspection format.

Also, Steve Harris suggests that we should use mDNS records to

announce more than just '_udp._osc', but include some descriptive

fields such as a URI with information on the service.

There is a natural mapping from these mDNS TXT attributes to IANA type options.

OSC doesn't have a registered IANA type (for now I've used x-application/osc), but I am working on the application.

So far I've identified three attributes that I think are useful:

version=1.0 (or some later number, when available)

framing=slip (attribute used for serial transports making use of the SLIP RFC1055 framing mechanism)

schema=http://..... (any URI)

The schema URI is chosen to uniquely identify the device.  e.g. http://opensoundcontrol.org/implemenation/thingxyz#version-0.1.  (It does not have to be opensoundcontrol.org nor even necessarily http -- it could also be file:, ftp: etc)

At some future point it might also return a service descriptor, so it leaves that possibility for future development.

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

phone: [phone] x.313

Programmer/Analyst II

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

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

[remy muller]

hi,

nice to hear people concerned about these issues.

Stephen Sinclair a écrit :
> We've recently had a short discussion on the liblo mailing list
> regarding a proposed patch to enable Avahi/Zeroconf support.
> OSC servers created with liblo would announce themselves on zeroconf
> with the service '_udp._osc'.

just to clarify, oscbonjour uses '_osc._udp' to register and browse for
OSC services
http://recherche.ircam.fr/equipes/temps-reel/movement/muller/index.php?entry=entry060616-173626

best

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

[Andy W. Schmeder-2]

On Feb 24, 2008, at 1:14 PM, Stephen Sinclair wrote:

We've recently had a short discussion on the liblo mailing list

regarding a proposed patch to enable Avahi/Zeroconf support.

OSC servers created with liblo would announce themselves on zeroconf

with the service '_udp._osc'.

Question--does zeroconf/mDNS let one use dynamic port numbers?  It seems like that would be a major advantage to this approach when multiple copies of a service are running.

Cheers

Andy.

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

phone: [phone] x.313

Programmer/Analyst II

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

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

[remy muller]

Andy W. Schmeder a écrit :
> Question--does zeroconf/mDNS let one use dynamic port numbers?  It seems
> like that would be a major advantage to this approach when multiple
> copies of a service are running.

what do you mean by dynamic port numbers?

If you wanted to switch ports on the fly you would announce the service
once again but with a different port and let other applications update
their port configuration accordingly.

One nice mDNS feature in the case of multiple instances of the same
service (on 2 machines for example) is that it automatically appends
numbers at the end of service's names to avoid name clashes.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Andy W. Schmeder-2]

On Feb 24, 2008, at 4:50 PM, remy muller wrote:

Andy W. Schmeder a écrit :

Question--does zeroconf/mDNS let one use dynamic port numbers?  It seems 

like that would be a major advantage to this approach when multiple 

copies of a service are running.

what do you mean by dynamic port numbers?

e.g. high # ports assigned by the OS instead of being hard-coded into the application.

One nice mDNS feature in the case of multiple instances of the same 

service (on 2 machines for example) is that it automatically appends 

numbers at the end of service's names to avoid name clashes.

Yes, that is a nice feature...

A.

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

phone: [phone] x.313

Programmer/Analyst II

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

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

[Stephen Sinclair]

On Sun, Feb 24, 2008 at 7:36 PM, remy muller <remy.muller@...> wrote:
> hi,
>
>  nice to hear people concerned about these issues.

I feel like this issue has come up several times in the past years and
is always discussed but never resolved..
in some cases, like '/' vs. '/namespace', etc, it is almost
equivalent, and it would be best to just choose one or the other so
various programs can be made compatible.

Perhaps by 'resolved', I simply mean that the goal of this discussion
should be to come to a consensus on what should be the recommended
practice, and put this somewhere obvious on opensoundcontrol.org so
that there is something developers can reference.

These must be recommendations of course, rather than requirements,
since as Andy points out, there are clearly cases where services
cannot respond to queries.

>  just to clarify, oscbonjour uses '_osc._udp' to register and browse for
>  OSC services

absolutely, my mistake.


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

[Jason Hector]

Hi,

I am doing my Msc thesis project in OSC. Specifically I want to implement a OSC VST layer inbetween the vst host and plugin. This layer will have access to control data [parameter and midi] as well as audio data from both the host and plugin.

What i would like to solicit from you is whether such a system would add value [significant?] to the OSC research community as I would not like my efforts to be in vain.

Thanks in advance

Jason H

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

[Ross Bencina-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Jason

 

I'm not sure I understand exactly what you're proposing.. I assume you are aware of existing research in OSC/VST bindings.

 

My understanding is that you're thinking of wrapping existing VST plugins and intercepting data on the way through.. sounds like an interesting direction to me.

 

I've been thinking about writing an extension to the VST spec for passing OSC data between specially OSC-enabled plugins -- basically an OSC packet type of VST event. Nothing to do with your idea really, just thought I'd mention it.

 

Best wishes

 

Ross.

 

 

 

 

----- Original Message -----

From: JasonA.Hector@...

To: osc_dev@...

Sent: Tuesday, March 04, 2008 1:33 AM

Subject: [OSC_dev] OSC vst layer

Hi,

I am doing my Msc thesis project in OSC. Specifically I want to implement a OSC VST layer inbetween the vst host and plugin. This layer will have access to control data [parameter and midi] as well as audio data from both the host and plugin.

What i would like to solicit from you is whether such a system would add value [significant?] to the OSC research community as I would not like my efforts to be in vain.

Thanks in advance

Jason H

---

_______________________________________________
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

[Jason Hector]

Hi,

Thanks for the feedback. I think you hit it spot on in saying its a vst wrapper that intercepts data.

 

Unfortunately, I am not aware of the existing research in OSC/VST bindings. [this is why i asked my initial question to avoid duplication research]. Where would i be able to find information on this? This would help me very much.

 

I think if i do implement this wrapper then all plugins used within the wrapper would inherently be OSC enabled. ;)

 

Thanks in advance

Jason

>>> "Ross Bencina" <rossb-lists@...> 2008/03/06 05:34 >>>

Hi Jason

 

I'm not sure I understand exactly what you're proposing.. I assume you are aware of existing research in OSC/VST bindings.

 

My understanding is that you're thinking of wrapping existing VST plugins and intercepting data on the way through.. sounds like an interesting direction to me.

 

I've been thinking about writing an extension to the VST spec for passing OSC data between specially OSC-enabled plugins -- basically an OSC packet type of VST event. Nothing to do with your idea really, just thought I'd mention it.

 

Best wishes

 

Ross.

 

 

 

 

----- Original Message -----

From: JasonA.Hector@...

To: osc_dev@...

Sent: Tuesday, March 04, 2008 1:33 AM

Subject: [OSC_dev] OSC vst layer

Hi,

I am doing my Msc thesis project in OSC. Specifically I want to implement a OSC VST layer inbetween the vst host and plugin. This layer will have access to control data [parameter and midi] as well as audio data from both the host and plugin.

What i would like to solicit from you is whether such a system would add value [significant?] to the OSC research community as I would not like my efforts to be in vain.

Thanks in advance

Jason H

---

_______________________________________________
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

[Alexander Refsum Jensenius]

Hi, 

Unfortunately, I am not aware of the existing research in OSC/VST bindings. [this is why i asked my initial question to avoid duplication research]. Where would i be able to find information on this? This would help me very much.

Try for example: 

http://scholar.google.no/scholar?hl=en&lr=&q=control+vst+osc&btnG=Search

The ICMC paper by Zbyszyński would be a good start. 

Cheers, 

Alexander

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

[Andy W. Schmeder-2]

On Mar 6, 2008, at 2:57 AM, Jason Hector wrote:

Hi,

Thanks for the feedback. I think you hit it spot on in saying its a vst wrapper that intercepts data.

 

Unfortunately, I am not aware of the existing research in OSC/VST bindings. [this is why i asked my initial question to avoid duplication research]. Where would i be able to find information on this? This would help me very much.

Here are the two references that I know about:

http://opensoundcontrol.org/publication/control-vst-plug-ins-using-osc

and

http://opensoundcontrol.org/publication/osc-control-vst-plug-ins-0

And in general for any OSC-related research:

http://opensoundcontrol.org/publications

If there are any important papers missing from this database, authors are invited to add them.  Requires an account, then use "Create content > Bibliography".

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

phone: [phone] x.313

Programmer/Analyst II

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

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

[Jason Hector]

Hi,

I have read those papers mentioned [again yesterday] and they mostly address the flat namespace of vst control parameters. These papers date to 2004. However since vst 2.4 released in 2005, the vst parameter structure has been addressed in the sdk with the use of vstxml providing the hierarchy mentioned in the OSC paper. Have there been other developments/publications around OSC/VST since this 2004 paper?

 

thanks in advance

Jason

>>> "Andy W. Schmeder" <andy@...> 2008/03/06 20:20 >>>

On Mar 6, 2008, at 2:57 AM, Jason Hector wrote:

Hi,

Thanks for the feedback. I think you hit it spot on in saying its a vst wrapper that intercepts data.

 

Unfortunately, I am not aware of the existing research in OSC/VST bindings. [this is why i asked my initial question to avoid duplication research]. Where would i be able to find information on this? This would help me very much.

Here are the two references that I know about:

http://opensoundcontrol.org/publication/control-vst-plug-ins-using-osc

and

http://opensoundcontrol.org/publication/osc-control-vst-plug-ins-0

And in general for any OSC-related research:

http://opensoundcontrol.org/publications

If there are any important papers missing from this database, authors are invited to add them.  Requires an account, then use "Create content > Bibliography".

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

phone: [phone] x.313

Programmer/Analyst II

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

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

[Chris Graham-2]

I have searched for other OSC to VST bridge solutions and not found any.  Also, the most complete implementation in the papers uses Max/MSP, I believe.

I would very much like to have available a compact OSC to VST solution that directly uses the VST SDK.  I'm developing instruments that output OSC but I'm resorting to MIDI to get data into VST environments.

- Chris

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