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

[werteplus at gmail.com]

On Sat, Jan 17, 2009 at 9:00 PM, <osc_dev-request at create.ucsb.edu> wrote:

> On Fri, Jan 16, 2009 at 2:55 PM,  <werteplus at gmail.com> wrote:
> > [...]
> > BUT one problem came to my mind with a system where the synthesizer has
> to
> > know + handle which key is which frequency: what if a second controller
> has
> > a different mapping and sends this mapping to the synthesizer?
> >
> > either: a) the keys of the two controllers "overlap" and the first one
> now
> > triggers a different frequency for each key (yuk)
> >
> > or: b) each controller has its own "namespace" at the synthesizer. this
> is
> > the more preferable way to go with the keys concept in my opinion. but
> the
> > synthie will have to handle a table for every controller connected =>
> > connection handshakes become necessary and no more optional + the
> controller
> > will probably have an upper limit for simultaneously connected
> controllers
> > which also depends on the keys per controller.
> >
> > i try to be open here, but are these things justifyable in your opinion?
> (no
> > sarcasm)
>
> Hi,
>
> I just wanted to mention that this is basically describing what we
> implemented last year using Max/MSP.  The patches to create
> synthesizers and controllers are available for download if anyone's
> interested.  The system provides a GUI showing what synthesizers and
> controllers are on the network (using multicast), and the user can set
> up connections from controllers to synthesizers which become
> peer-to-peer connections.  Then connections between particular
> namespace items can be made, with some signal conditioning such as
> scaling and filtering if requested.
>
> http://idmil.org/software/mappingtools
>
> [...]
>
> Steve


Hey Steve, thanks for the input!

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).

I've read through your descriptions on the website and thought about the
uses with standardized key on/off messages. I have some questions:

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?

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

the instance of dot.admin will negotiate with other instances for a unique
name and port, and announce itself on the mapping admin bus.

Does that mean that the receiving instance can also distinguish which
controller the note messages came from and map them into separate namespaces
of the synth respectively?
The main concern is:

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?

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.

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

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.

greetings,
fabb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.create.ucsb.edu/pipermail/osc_dev/attachments/20090118/a1ea987d/attachment.html