OSC Query Systems & Binary Protocol

[Chris Graham-2]

I'm developing a family of modular electronic wind instruments that will use
OSC as their external interface to other applications.  You can see more
details at www.multiwind.com.

The plan is that the instruments are mainly rich sources of control data.
Higher level interpretation of the control gestures into music control
signals (in OSC or MIDI) is done on a host computer.  The hardware is
modular and highly configurable and it is desirable that the host computer
software be able to query what modules are present, i.e. what the overall
namespace of the instrument currenly is.  It will also be desirable for host
computer sofware to be able to configure the instrument using OSC commands
regarding what sensors to sample, sampling rate, prescaling, hysteresis to
apply, etc., and where to send the data.

Therefore I need a query interface, and preferably I would use one that is
compatible with what others are doing.

The closest proposal I have seen to what I need is the one by Martin Habets
which is available at http://liboscqs.sourceforge.net/ . This describes a
way to inquire of an OSC client the details of its namespace, and to ask it
to send specific data items to specific data consumers.  I would add to the
the ability to set the sampling rate for a given sensor, transformations to
apply, etc.

I see from the list archives that there was some controversy about whether
this, or any dynamic patching systems was desirable, but I definitely need
something like this and I expect that others do also.

Martin, if you see this post, could you explain more details about the
"category" field is in your patching system?  It's not clear to me how this,
an integer, specifies what item in the namespace is supposed to be sent to
the requested destination.

More generally, what is the current state of the art in query systems and
patching?  I saw in another post that the Lemur group was developing a query
system.  What is this?  Any others?

I'm also developing a compact binary version semantically equivalent to the
essential elements of OSC, but suitable for lower bandwidth connections.
For example the expansion bus in my instruments uses the SPI protocol with a
maximum shared rate of about 1Mbps.  Also, my devices use USB with a USB 1.1
equivalent data rate to link to the host, and I want to be efficient of
bandwidth on that link.  My binary protocol which will arrive at the host on
USB HID (for tighter timing than USB bulk) will be translated into normal
OSC by my USB driver, so it will not necessarily be seen to the outside
world, but my lower level solutions may be of interest to others.  I will
open source the host software for this project so others can use it.

I will be at NIME next week, so if anyone is interested in discussing these
things, please let me know.

- Chris Graham

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

[Stephen Sinclair]

Hi Chris,

> Therefore I need a query interface, and preferably I would use one that is
> compatible with what others are doing.

You might be interested in some work we've been doing at McGill.  We
are tackling this exact issue with controllers built in our lab.  So
far we've put together a mapping system that allows querying of
namespace and then making arbitrary connections with scaling operators
between the controller and a compatible synthesis engine.  The work
we've done so far has been in Max/MSP.  We've written a paper on the
subject which has been submitted (but not yet accepted) to ICMC.  You
might like to look at it, so I've put it up on my webspace:

http://www.music.mcgill.ca/~sinclair/pub/papers/Malloch_mapping2007.pdf

When we wrote this in fact I was not aware of liboscqs, so thank you
for bringing it to my attention!  Same as you, we of course do _not_
want to duplicate work.  Our paper merely presents what query protocol
we were using en lieu of something more standard being available.  We
are definitely open to suggestions, but you might find some ideas in
there nonetheless.

> I will be at NIME next week, so if anyone is interested in discussing these
> things, please let me know.

I will as well, as will Joe Malloch, the primary author of the
above... we'll be sure to talk! :)


Steve


On 6/2/07, Chris Graham <chrisgr@...> wrote:

> I'm developing a family of modular electronic wind instruments that will use
> OSC as their external interface to other applications.  You can see more
> details at www.multiwind.com.
>
> The plan is that the instruments are mainly rich sources of control data.
> Higher level interpretation of the control gestures into music control
> signals (in OSC or MIDI) is done on a host computer.  The hardware is
> modular and highly configurable and it is desirable that the host computer
> software be able to query what modules are present, i.e. what the overall
> namespace of the instrument currenly is.  It will also be desirable for host
> computer sofware to be able to configure the instrument using OSC commands
> regarding what sensors to sample, sampling rate, prescaling, hysteresis to
> apply, etc., and where to send the data.
>
> Therefore I need a query interface, and preferably I would use one that is
> compatible with what others are doing.
>
> The closest proposal I have seen to what I need is the one by Martin Habets
> which is available at http://liboscqs.sourceforge.net/ . This describes a
> way to inquire of an OSC client the details of its namespace, and to ask it
> to send specific data items to specific data consumers.  I would add to the
> the ability to set the sampling rate for a given sensor, transformations to
> apply, etc.
>
> I see from the list archives that there was some controversy about whether
> this, or any dynamic patching systems was desirable, but I definitely need
> something like this and I expect that others do also.
>
> Martin, if you see this post, could you explain more details about the
> "category" field is in your patching system?  It's not clear to me how this,
> an integer, specifies what item in the namespace is supposed to be sent to
> the requested destination.
>
> More generally, what is the current state of the art in query systems and
> patching?  I saw in another post that the Lemur group was developing a query
> system.  What is this?  Any others?
>
> I'm also developing a compact binary version semantically equivalent to the
> essential elements of OSC, but suitable for lower bandwidth connections.
> For example the expansion bus in my instruments uses the SPI protocol with a
> maximum shared rate of about 1Mbps.  Also, my devices use USB with a USB 1.1
> equivalent data rate to link to the host, and I want to be efficient of
> bandwidth on that link.  My binary protocol which will arrive at the host on
> USB HID (for tighter timing than USB bulk) will be translated into normal
> OSC by my USB driver, so it will not necessarily be seen to the outside
> world, but my lower level solutions may be of interest to others.  I will
> open source the host software for this project so others can use it.
>
>
> - Chris Graham
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://www.create.ucsb.edu/mailman/listinfo/osc_dev
>

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

[Christopher Graham]

Hi Steve,

Sounds good I'll review your paper and look for you at NIME.  I'll be there
as a vendor and will have a booth, although I don't quite have anything to
sell yet, just a prototype.

I may be at ICMC this year, so I may see you there also.

Sorry, everyone, if multiple copies my post appeared on the list.  It kept
sending me a bounce message.

- Chris

> -----Original Message-----
> From: osc_dev-bounces@...
> [mailto:osc_dev-bounces@...] On Behalf Of Stephen Sinclair
> Sent: June 2, 2007 5:00 PM
> To: Developer's list for the OpenSound Control (OSC) Protocol
> Subject: Re: [OSC_dev] OSC Query Systems & Binary Protocol
>
> Hi Chris,
>
> > Therefore I need a query interface, and preferably I would use one
> > that is compatible with what others are doing.
>
> You might be interested in some work we've been doing at
> McGill.  We are tackling this exact issue with controllers
> built in our lab.  So far we've put together a mapping system
> that allows querying of namespace and then making arbitrary
> connections with scaling operators between the controller and
> a compatible synthesis engine.  The work we've done so far
> has been in Max/MSP.  We've written a paper on the subject
> which has been submitted (but not yet accepted) to ICMC.  You
> might like to look at it, so I've put it up on my webspace:
>
> http://www.music.mcgill.ca/~sinclair/pub/papers/Malloch_mappin
> g2007.pdf
>
> When we wrote this in fact I was not aware of liboscqs, so
> thank you for bringing it to my attention!  Same as you, we
> of course do _not_ want to duplicate work.  Our paper merely
> presents what query protocol we were using en lieu of
> something more standard being available.  We are definitely
> open to suggestions, but you might find some ideas in there
> nonetheless.
>
> > I will be at NIME next week, so if anyone is interested in
> discussing
> > these things, please let me know.
>
> I will as well, as will Joe Malloch, the primary author of
> the above... we'll be sure to talk! :)
>
>
> Steve
>
>
> On 6/2/07, Chris Graham <chrisgr@...> wrote:
> > I'm developing a family of modular electronic wind instruments that
> > will use OSC as their external interface to other
> applications.  You
> > can see more details at www.multiwind.com.
> >
> > The plan is that the instruments are mainly rich sources of
> control data.
> > Higher level interpretation of the control gestures into
> music control
> > signals (in OSC or MIDI) is done on a host computer.  The
> hardware is
> > modular and highly configurable and it is desirable that the host
> > computer software be able to query what modules are
> present, i.e. what
> > the overall namespace of the instrument currenly is.  It
> will also be
> > desirable for host computer sofware to be able to configure the
> > instrument using OSC commands regarding what sensors to sample,
> > sampling rate, prescaling, hysteresis to apply, etc., and
> where to send the data.
> >
> > Therefore I need a query interface, and preferably I would use one
> > that is compatible with what others are doing.
> >
> > The closest proposal I have seen to what I need is the one
> by Martin
> > Habets which is available at
> http://liboscqs.sourceforge.net/ . This
> > describes a way to inquire of an OSC client the details of its
> > namespace, and to ask it to send specific data items to
> specific data
> > consumers.  I would add to the the ability to set the sampling rate
> > for a given sensor, transformations to apply, etc.
> >
> > I see from the list archives that there was some controversy about
> > whether this, or any dynamic patching systems was desirable, but I
> > definitely need something like this and I expect that
> others do also.
> >
> > Martin, if you see this post, could you explain more
> details about the
> > "category" field is in your patching system?  It's not
> clear to me how
> > this, an integer, specifies what item in the namespace is
> supposed to
> > be sent to the requested destination.
> >
> > More generally, what is the current state of the art in
> query systems
> > and patching?  I saw in another post that the Lemur group was
> > developing a query system.  What is this?  Any others?
> >
> > I'm also developing a compact binary version semantically
> equivalent
> > to the essential elements of OSC, but suitable for lower
> bandwidth connections.
> > For example the expansion bus in my instruments uses the
> SPI protocol
> > with a maximum shared rate of about 1Mbps.  Also, my
> devices use USB
> > with a USB 1.1 equivalent data rate to link to the host,
> and I want to
> > be efficient of bandwidth on that link.  My binary protocol
> which will
> > arrive at the host on USB HID (for tighter timing than USB
> bulk) will
> > be translated into normal OSC by my USB driver, so it will not
> > necessarily be seen to the outside world, but my lower
> level solutions
> > may be of interest to others.  I will open source the host
> software for this project so others can use it.
> >
> >
> > - Chris Graham
> >
> > _______________________________________________
> > OSC_dev mailing list
> > OSC_dev@...
> > http://www.create.ucsb.edu/mailman/listinfo/osc_dev
> >
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://www.create.ucsb.edu/mailman/listinfo/osc_dev
>

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

[Andy W. Schmeder-2]

USB interrupt transfer mode (e.g. HID) is given higher priority over bulk, but it isn't guaranteed bandwidth nor latency -- it also has a very small bandwidth allocation in USB 1.1 / Full-speed.  I would benchmark the latency of USB Bulk transport before discounting it as a possibility, since, as long as the bus isn't saturated, there shouldn't be any delay.

Ultimately, isochronous transfers are ideal and meet the requirements for transport outlined in the OSC spec.

...

OSC is already a binary format but assumes by design that the protocol is not significantly bandwidth-constrained.  I'm not certain that a version of "compact OSC" would have broad applicability.

For non-packetized transports (e.g. serial, TCP, etc) we recommend SLIP-encoding -- this is both microcontroller-friendly and already incorporated into commercial products (The Make Controller).

...

As for query systems, Matt Wright and I presented a paper on this at the OSC Conference 2004, which I have put online here: http://a2hd.com/query-system-open-sound-control

The query system described above is also partially implemented in Open Sound World, http://osw.sourceforge.net

However, my current line of reasoning is that putting the query system into OSC is technically flawed for a number of reasons (e.g. violates the state-machine-free requirement and also needs assured delivery), and furthermore is a redundant effort because query systems have already been defined in more appropriate meta-languages and are already sufficiently expressive for our requirements (e.g. web services).  At some near-future point we are planning to publish general recommendation on how to leverage these protocols in conjuction with OSC.

Best

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://www.create.ucsb.edu/mailman/listinfo/osc_dev