[OSC_dev] OSC Query Systems & Binary Protocol

[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 at shaw.ca> 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 at create.ucsb.edu
> http://www.create.ucsb.edu/mailman/listinfo/osc_dev
>