[OSC_dev] Keyboard Controller Keys vs Voices (Stephen Sinclair)

[Joseph Malloch]

Hi,

> Such a system would be great for external gear, just connect the devices,
> choose the name of the synth at the controller and start playing. For the
> out-of-the-box experience still some standardization has to be made, a
> standard mapping (which should be changeable off course).

The mapping tool was built to make mapping easy, not automatic, so it
doesn't generate any default mapping. From the paper:
    "we decided that approaching the problem of interoperation from a
networking and protocol point of view would yield greater long-term
results, and provide useful functionality for development of mapping
techniques in a collaborative environment, while not necessarily
precluding the use of other mapping approaches within its framework"

Thus while we tend to use the GDIF approach for namespace
standardization, our mapping tools do not require any namespace
standardization at all beyond the admin layer we have implemented.

> I've read through your descriptions on the website

The system is described and documented in the linked papers much
better than on the website. The longer one is behind a login at
Springer, so I've also posted it for anyone interested:

http://www.music.mcgill.ca/~mallochj/temp/malloch2008.pdf

> When we've got a controller & a synth: Is the mapping tool actually running
> on both sides? So the controller's original osc methods get linked +
> translated to the mapping tool on the controller side, get sent to the
> mapping tool on the synth side and there get again translated into the
> synths namespace?

yes the dot.admin max abstraction is running on each side, but
namespace translation, scaling, etc only takes place once. Mapped
connections are scaled and translated at the source device, and then
sent directly to the destination using the destination namespace. BTW,
a single device can be both source and destination using this system.

> I'm thinking of the problem several controllers -> one synth.

This is commonly referred to as "many-to-one" or "convergent" mapping
in the literature...

> a) should a key of controller A be able to get mapped to the very same voice
> from the synth as another key of controller B? Meaning further: should it be
> possible to send a "note on" message from A, and a following "note off"
> message from B to turn on that note?

Yes definitely, if you have mapped the two controllers to the same
synth. The system can handle many source devices controlling one
destination device, or one source device controlling many destination
devices.

> b) if not / if it should also be possible not to: has the synth a separate
> namespace for every connected controller? or one big linear one and the
> mapping tool on the synth side does the mapping (where it would have to know
> how many keys (-> fixed / bound number, maybe bad) each controller sends.

No, each device knows only its own namespace (though they can request
others - the GUIs do this in order to display them to the user). As
explained above, the namespace translation takes place before sending
the data over the network, so it arrives at the destination with the
correct control namespace for the destination device.

> Another question is if a controller & synth should ONLY have the mapping
> tool interface, or also its raw original namespace in addition.

Anything sending OSC data with the correct namespace to a destination
device will have the expected effect (it doesn't have to be set up
with the mapping tools). Source devices do not output anything unless
it's mapped - the alternative is every source device spitting out lots
of unused data on the network, which is how we used to do things :)

> And one more thing that regards the original key vs voice battle:
> How do you process simultaneously happening parameters, does the mapping
> tool support bundles? Is the higher level data transportation method
> applicable for really simultaneous things like "key down" + "velocity" +
> "panning" + etc? (for really free voice start definition methods, as there
> is a difference between initial parameters and running voice change
> parameters). It'd be unpractical to stuff them all into one method, as the
> "voice on" compounds shouldn't be restricted before hand.

Presently the system is not using OSC bundles, but there is no reason
why it couldn't - the high-level multicast stuff is only for setting
up p2p connections between mapped devices, namespace reporting, saving
and loading of mapping-sets, etc. All other data transportation is p2p
and device-specific, and OSC bundles could be used here as easily as
anywhere.

As an aside, I find there is a weird obsession with MIDI-style control
in this discussion - everyone keeps talking about "keys" and
"velocity" etc. As a contrary example, many of the "source devices" we
use with the mapping tools (gestural controllers in this case) are
capable of sending 50-100 parameters *at the same time*, many of which
are continuous. I think creating genuinely useful tools for OSC
mapping requires thinking outside the MIDI-box :)

Joseph Malloch
Input Devices and Music Interaction Laboratory
Schulich School of Music - McGill University
email: joseph.malloch at mcgill.ca
web: http://www.music.mcgill.ca/~mallochj