SYNoscopy (or something like it)

[Jeff Glatt]

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

I'm planning on writing a developer library that implements some sort
of OSC-based "standard" that replaces MIDI. As someone previously
mentioned, you currently can't use OSC for anything but a proprietary
protocol because there are no standardized set of messages (like
MIDI's Note-On, Note-Off, Program Change, Controller, etc, messages).

 

So, I was taking a look at this SYNoscopy specification (because what
I'd need to do is what this specification proposes). First of all, is
there any device/software currently implementing/using this particular
spec? Secondly, since there are aspects of the spec that I think could
be changed for the better (ie, make it easier, and more efficient, to
actually implement in software), I'm wondering where is the best place
to discuss them. There is a message board on the SYNoscopy site, but
it has only 1 message that looks to be dating back to 2007. Is that
board active? There looks to be some other site where people leave
comments, but the formatting makes it very difficult to follow, and
without any reply threading, it's really hard to determine who is
commenting on what.

 

Is this list better for discussing a full OSC replacement for MIDI?

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

[werteplus]

well, the synoscopy board isn't really active, i just uploaded the whole synoscopy thing to this site some months ago to make it findable and not get completely rotten.

i wanted to build a hardware adapter with a microcontroller which translates between midi and synoscopy to oscenable old equipment, but i never got to it.

you're completely welcome to do any changes for your needs (as there are no implementations i know of anyway), i guess here would be a good place to discuss these things. and i'm definately interested in how you use it!

greetings,
fabb

Date: Mon, 26 Jan 2009 12:08:31 -0500
From: "Jeff Glatt" <jgglatt@...>
Subject: [OSC_dev] SYNoscopy (or something like it)
To: <osc_dev@...>
Message-ID: <5C8268FDC3CB4D62828088005EADAB62@jeffdesktop>
Content-Type: text/plain; charset="iso-8859-1"

I'm planning on writing a developer library that implements some sort
of OSC-based "standard" that replaces MIDI. As someone previously
mentioned, you currently can't use OSC for anything but a proprietary
protocol because there are no standardized set of messages (like
MIDI's Note-On, Note-Off, Program Change, Controller, etc, messages).

So, I was taking a look at this SYNoscopy specification (because what
I'd need to do is what this specification proposes). First of all, is
there any device/software currently implementing/using this particular
spec? Secondly, since there are aspects of the spec that I think could
be changed for the better (ie, make it easier, and more efficient, to
actually implement in software), I'm wondering where is the best place
to discuss them. There is a message board on the SYNoscopy site, but
it has only 1 message that looks to be dating back to 2007. Is that
board active? There looks to be some other site where people leave
comments, but the formatting makes it very difficult to follow, and
without any reply threading, it's really hard to determine who is
commenting on what.

Is this list better for discussing a full OSC replacement for MIDI?

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

[Gaspard Bucher]

I know of a midi message format (type tag "m" in oscpack) that just
wraps midi messages (4 bytes: port / status / data1 / data2) in OSC.
The "status" thing implements a mixture of the type of message (4bits)
and the channel (4bits). Details can be found here
(http://www.planetoftunes.com/sequence/messages.html). If you just
need MIDI over OSC, I think it's a good idea to use this format.

For a "standard" on where to send the midi information and things like
this, we are working on a minimal protocol that should ease
connections between applications (automatic or user based). Some of
the work can be found on http://rubyk.org/en/oscit (minimal protocol,
zeroconf) and another part is at http://openmediacontrol.wetpaint.com/
(media application control). These researches should finally merge
when we have implementations to test and discuss about.

Hope that helps,

Gaspard

On Mon, Jan 26, 2009 at 6:08 PM, Jeff Glatt <jgglatt@...> wrote:

> I'm planning on writing a developer library that implements some sort
> of OSC-based "standard" that replaces MIDI. As someone previously
> mentioned, you currently can't use OSC for anything but a proprietary
> protocol because there are no standardized set of messages (like
> MIDI's Note-On, Note-Off, Program Change, Controller, etc, messages).
>
> So, I was taking a look at this SYNoscopy specification (because what
> I'd need to do is what this specification proposes). First of all, is
> there any device/software currently implementing/using this particular
> spec? Secondly, since there are aspects of the spec that I think could
> be changed for the better (ie, make it easier, and more efficient, to
> actually implement in software), I'm wondering where is the best place
> to discuss them. There is a message board on the SYNoscopy site, but
> it has only 1 message that looks to be dating back to 2007. Is that
> board active? There looks to be some other site where people leave
> comments, but the formatting makes it very difficult to follow, and
> without any reply threading, it's really hard to determine who is
> commenting on what.
>
> Is this list better for discussing a full OSC replacement for MIDI?
> _______________________________________________
> 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

[Jeff Glatt]

>midi message format (type tag "m")

Right. I saw that. But this just imposes the limitations/hacks of MIDI
upon OSC. For example, if you want to change a patch, you need to
send one or two Bank Select controller messages and then a Program
Change. If you want greater than 7-bit resolution in controllers, then
you need to use both the MSB and LSB controllers. If you want to
adjust a setting that doesn't have a specific controller number defined
for it, then you need to use RPN (or NRPN) controllers along with
Data Slider (or Inc or Dec) controllers. If you want to adjust master
volume you need to send a system exclusive message (which isn't even
supported by the "m" datatype). And I'm not even sure if the "m"
datatype requires you to always supply a MIDI status byte. (The OSC
spec doesn't spell this out). For example, if it allows you to send a
message with running status, then you have to resolve that upon receipt.
You have to "unpack" the 14-bit pitch wheel value into 2 8-bit bytes
when you send it, and then repack the 2 bytes into one short upon
receipt. Ditto with other messages such as Song Position Pointer.
MIDI Time Code is a horrible hack. You still have the 16 channel
limitation, which is really, really inadequate today. And there's more
about MIDI that is antiquated, largely due to the fact that all
messages (except system exclusive) _must_ be limited to containing
at most 2 data bytes. There's not a hell of a lot you can do with
that.

Don't get me wrong. I'm a big MIDI guy (and my web site
at http://home.roadrunner.com/~jgglatt has proven a popular
destination for people who want to know all about MIDI).

But today, all these MIDI limitations/hacks need to go. It was a
mistake for OSC to endorse this "m" datatype, rather than a real
standardized set of OSC messages to offer the sort of control that
MIDI does. I mean, if you're going to call it Open Sound Control,
don't you think it ought to define/standardize something that actually
and specifically controls some aspect of sound???

But, "m" datatype is just an "optional" datatype not supported
in a number of the OSC dev libs (which is yet one more obstacle).

So, there needs to be additional standardization done with OSC.

>standard on where to send the midi information

I took a brief look at the oscit proposal. Although this could
be something that is useful, and should be standardized, it's not
really what I'm talking about. I'm talking about a standardized set
of OSC messages to specifically control a synth. (ie, a message to
turn a note on or off, move the pitch wheel, change the patch,
etc). Every OSC-supported synth would support these messages
so that a controller would not need to assume that every synth had
its own set of proprietary messages which must be "queried" (using
something like oscit) before the controller could do something
useful. (And that's assuming that a given controller _could_
intelligently map out any, potentially incompatible set of messages
to its own hardware features without lots and lots of user
intervention. ie, Like asking "What button/slider/wheel/whatever do
you want me to map this "/Something/Blort" parameter to?". Not
very useful when a musician has gotten used to attaching his MIDI
controller's MIDI Out to the MIDI In of his synth, pressing a few
keys and instantly hearing sound, pressing patch buttons and
hearing the sound change, moving the pitch wheel and hearing the
pitch go up and down, etc. All without the controller needing to
ask him what keys/buttons/sliders/etc spit out what OSC
messages).

But in regards to oscit specifically, I do have a question that I'll
ask in the other thread about it.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jeff Glatt]

I've looked at the SYNoscopy specification, and here's the first
thing that puzzled me.

Does the spec assume that every synth (ie, sound module, device,
whatever) is "listening" to _every_ OSC message sent from any
given device, much like daisy-chained MIDI devices? In other words,
SYNoscopy assumes that there is one "bus", without any means of
data routing in the "bus transport" itself, just like daisy-chained
MIDI? And that's the reason why each synth must have a unique ID
number? It's a very basic "routing number" built into the spec
itself?

In other words, the spec pretty much assumes that you're using
something like UDP with multicasting? Because otherwise, every
device _can't_ see every message, because UDP delivers each
message to just one specific host/port. Ditto with TCP. (That's
true with most transport protocols that support the concept of
multiple devices attached to a single bus. Each message is
addressed to a specific device).

So my first thought was -- Is this ID scheme an unnecessary
complication? Would it not be easier to simply require that this
spec be used with a protocol that either supports only one device
per bus, or does automatic routing of each message to a specific
device? That seems quite practical to me, given that busses such
as ethernet, USB, firewire, SCSI, etc, support the requirement.

And of course, my second thought was "How does each synth get a
unique ID number anyway?". Obviously, two synths can't both
arbitrarily assume that they have an ID number of 1. Or does
the user have to manually set the ID for every device, along with
other needed routing settings such as UDP port number and
hostname? This will really confuse most musicians. The less
settings to make, the better.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Gaspard Bucher]

Sorry for my first post on "m", you obviously know your midi.

For what you need, I think "oscit" can be the first step. It handles :

1. getting applications to talk with user intervention
2. get "schema" for specific protocols supported

The "schema" definition for a Midi replacement is yet to be written.
If you would like to endorse such a task (which would be really
great!), then it has to overcome the actual limitations of Midi
without making it too complicated for hardware vendors to support it.
Some things on my midi-replacement wish list:

1. replace note values by floats with a logarithmique notation: 60.50
(Middle 'C' + 50 cents = quarter tone). This notation is backward
compatible and seems much better for musicians then raw frequencies.
It also means that musical structures can be easily transposed (by
adding a value).
2. possibility to use named channels/ctrls (should keep numbers for
low cost hardware without big display).

If you want to join the discussion on "oscit", you are welcome: it's
still a draft so lots of things can be changed if it's for the better
(faster, better design, easier for end user).

Gaspard

On Wed, Jan 28, 2009 at 3:58 AM, Jeff Glatt <jgglatt@...> wrote:

>>midi message format (type tag "m")
>
> Right. I saw that. But this just imposes the limitations/hacks of MIDI
> upon OSC. For example, if you want to change a patch, you need to
> send one or two Bank Select controller messages and then a Program
> Change. If you want greater than 7-bit resolution in controllers, then
> you need to use both the MSB and LSB controllers. If you want to
> adjust a setting that doesn't have a specific controller number defined
> for it, then you need to use RPN (or NRPN) controllers along with
> Data Slider (or Inc or Dec) controllers. If you want to adjust master
> volume you need to send a system exclusive message (which isn't even
> supported by the "m" datatype). And I'm not even sure if the "m"
> datatype requires you to always supply a MIDI status byte. (The OSC
> spec doesn't spell this out). For example, if it allows you to send a
> message with running status, then you have to resolve that upon receipt.
> You have to "unpack" the 14-bit pitch wheel value into 2 8-bit bytes
> when you send it, and then repack the 2 bytes into one short upon
> receipt. Ditto with other messages such as Song Position Pointer.
> MIDI Time Code is a horrible hack. You still have the 16 channel
> limitation, which is really, really inadequate today. And there's more
> about MIDI that is antiquated, largely due to the fact that all
> messages (except system exclusive) _must_ be limited to containing
> at most 2 data bytes. There's not a hell of a lot you can do with
> that.
>
> Don't get me wrong. I'm a big MIDI guy (and my web site
> at http://home.roadrunner.com/~jgglatt has proven a popular
> destination for people who want to know all about MIDI).
>
> But today, all these MIDI limitations/hacks need to go. It was a
> mistake for OSC to endorse this "m" datatype, rather than a real
> standardized set of OSC messages to offer the sort of control that
> MIDI does. I mean, if you're going to call it Open Sound Control,
> don't you think it ought to define/standardize something that actually
> and specifically controls some aspect of sound???
>
> But, "m" datatype is just an "optional" datatype not supported
> in a number of the OSC dev libs (which is yet one more obstacle).
>
> So, there needs to be additional standardization done with OSC.
>
>>standard on where to send the midi information
>
> I took a brief look at the oscit proposal. Although this could
> be something that is useful, and should be standardized, it's not
> really what I'm talking about. I'm talking about a standardized set
> of OSC messages to specifically control a synth. (ie, a message to
> turn a note on or off, move the pitch wheel, change the patch,
> etc). Every OSC-supported synth would support these messages
> so that a controller would not need to assume that every synth had
> its own set of proprietary messages which must be "queried" (using
> something like oscit) before the controller could do something
> useful. (And that's assuming that a given controller _could_
> intelligently map out any, potentially incompatible set of messages
> to its own hardware features without lots and lots of user
> intervention. ie, Like asking "What button/slider/wheel/whatever do
> you want me to map this "/Something/Blort" parameter to?". Not
> very useful when a musician has gotten used to attaching his MIDI
> controller's MIDI Out to the MIDI In of his synth, pressing a few
> keys and instantly hearing sound, pressing patch buttons and
> hearing the sound change, moving the pitch wheel and hearing the
> pitch go up and down, etc. All without the controller needing to
> ask him what keys/buttons/sliders/etc spit out what OSC
> messages).
>
> But in regards to oscit specifically, I do have a question that I'll
> ask in the other thread about it.
> _______________________________________________
> 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

[Gaspard Bucher]

PS: in my last message, it's

1. getting applications to talk **without** user intervention
2. get "schema" for specific protocols supported

sorry for the typo.

On Wed, Jan 28, 2009 at 8:46 AM, Gaspard Bucher <gaspard@...> wrote:

> Sorry for my first post on "m", you obviously know your midi.
>
> For what you need, I think "oscit" can be the first step. It handles :
>
> 1. getting applications to talk with user intervention
> 2. get "schema" for specific protocols supported
>
> The "schema" definition for a Midi replacement is yet to be written.
> If you would like to endorse such a task (which would be really
> great!), then it has to overcome the actual limitations of Midi
> without making it too complicated for hardware vendors to support it.
> Some things on my midi-replacement wish list:
>
> 1. replace note values by floats with a logarithmique notation: 60.50
> (Middle 'C' + 50 cents = quarter tone). This notation is backward
> compatible and seems much better for musicians then raw frequencies.
> It also means that musical structures can be easily transposed (by
> adding a value).
> 2. possibility to use named channels/ctrls (should keep numbers for
> low cost hardware without big display).
>
> If you want to join the discussion on "oscit", you are welcome: it's
> still a draft so lots of things can be changed if it's for the better
> (faster, better design, easier for end user).
>
> Gaspard
>
> On Wed, Jan 28, 2009 at 3:58 AM, Jeff Glatt <jgglatt@...> wrote:
>>>midi message format (type tag "m")
>>
>> Right. I saw that. But this just imposes the limitations/hacks of MIDI
>> upon OSC. For example, if you want to change a patch, you need to
>> send one or two Bank Select controller messages and then a Program
>> Change. If you want greater than 7-bit resolution in controllers, then
>> you need to use both the MSB and LSB controllers. If you want to
>> adjust a setting that doesn't have a specific controller number defined
>> for it, then you need to use RPN (or NRPN) controllers along with
>> Data Slider (or Inc or Dec) controllers. If you want to adjust master
>> volume you need to send a system exclusive message (which isn't even
>> supported by the "m" datatype). And I'm not even sure if the "m"
>> datatype requires you to always supply a MIDI status byte. (The OSC
>> spec doesn't spell this out). For example, if it allows you to send a
>> message with running status, then you have to resolve that upon receipt.
>> You have to "unpack" the 14-bit pitch wheel value into 2 8-bit bytes
>> when you send it, and then repack the 2 bytes into one short upon
>> receipt. Ditto with other messages such as Song Position Pointer.
>> MIDI Time Code is a horrible hack. You still have the 16 channel
>> limitation, which is really, really inadequate today. And there's more
>> about MIDI that is antiquated, largely due to the fact that all
>> messages (except system exclusive) _must_ be limited to containing
>> at most 2 data bytes. There's not a hell of a lot you can do with
>> that.
>>
>> Don't get me wrong. I'm a big MIDI guy (and my web site
>> at http://home.roadrunner.com/~jgglatt has proven a popular
>> destination for people who want to know all about MIDI).
>>
>> But today, all these MIDI limitations/hacks need to go. It was a
>> mistake for OSC to endorse this "m" datatype, rather than a real
>> standardized set of OSC messages to offer the sort of control that
>> MIDI does. I mean, if you're going to call it Open Sound Control,
>> don't you think it ought to define/standardize something that actually
>> and specifically controls some aspect of sound???
>>
>> But, "m" datatype is just an "optional" datatype not supported
>> in a number of the OSC dev libs (which is yet one more obstacle).
>>
>> So, there needs to be additional standardization done with OSC.
>>
>>>standard on where to send the midi information
>>
>> I took a brief look at the oscit proposal. Although this could
>> be something that is useful, and should be standardized, it's not
>> really what I'm talking about. I'm talking about a standardized set
>> of OSC messages to specifically control a synth. (ie, a message to
>> turn a note on or off, move the pitch wheel, change the patch,
>> etc). Every OSC-supported synth would support these messages
>> so that a controller would not need to assume that every synth had
>> its own set of proprietary messages which must be "queried" (using
>> something like oscit) before the controller could do something
>> useful. (And that's assuming that a given controller _could_
>> intelligently map out any, potentially incompatible set of messages
>> to its own hardware features without lots and lots of user
>> intervention. ie, Like asking "What button/slider/wheel/whatever do
>> you want me to map this "/Something/Blort" parameter to?". Not
>> very useful when a musician has gotten used to attaching his MIDI
>> controller's MIDI Out to the MIDI In of his synth, pressing a few
>> keys and instantly hearing sound, pressing patch buttons and
>> hearing the sound change, moving the pitch wheel and hearing the
>> pitch go up and down, etc. All without the controller needing to
>> ask him what keys/buttons/sliders/etc spit out what OSC
>> messages).
>>
>> But in regards to oscit specifically, I do have a question that I'll
>> ask in the other thread about it.
>> _______________________________________________
>> 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

[werteplus]

Date: Wed, 28 Jan 2009 01:18:16 -0500
From: "Jeff Glatt" <jgglatt@...>

I've looked at the SYNoscopy specification, and here's the first
thing that puzzled me.

Does the spec assume that every synth (ie, sound module, device,
whatever) is "listening" to _every_ OSC message sent from any
given device, much like daisy-chained MIDI devices? In other words,
SYNoscopy assumes that there is one "bus", without any means of
data routing in the "bus transport" itself, just like daisy-chained
MIDI? And that's the reason why each synth must have a unique ID
number? It's a very basic "routing number" built into the spec
itself?

good thoughts. the answer is no.
the (to discuss) reason for this was that it would be possible in this way that a synthesizer hosting program has one osc-listening port open and does the routing to the hosted destination IDs=synths (that are not all in the network!). otherwise when you play with your external osc keyboard, and want to control a different synth, you have to change that on the keyboard, and it's not direct possible from the synthesizer hosting program.

IDs would only have to be unique within the host, so no broadcasting.

greetings,
fabb

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

[Jeff Glatt]

>a synthesizer hosting program has one osc-listening port open and does
>the routing to the hosted destination IDs

Ok, so it _is_ a very basic "routing number".

I still don't know why you need this ID number. All you need is the hostname
and port number of each connected device. If some "hosting program" wants
to route messages between devices, all it needs to know are those two pieces
of info about each device. And of course, it must already have that info if
the
software is communicating with those devices individually.

So what's the extra ID for?

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

[werteplus]

From: "Jeff Glatt" <jgglatt@...>

>a synthesizer hosting program has one osc-listening port open and does
>the routing to the hosted destination IDs

Ok, so it _is_ a very basic "routing number".

I still don't know why you need this ID number. All you need is the hostname
and port number of each connected device. If some "hosting program" wants
to route messages between devices, all it needs to know are those two pieces
of info about each device. And of course, it must already have that info if
the
software is communicating with those devices individually.

So what's the extra ID for?

ok, it's not really necessary. the host could offer some ports and route the data from this port to any synth.

i read through your spec. why are you then using "musician numbers" at all? you could keep consistent and have a dedicated port for every musician.

please don't just use just Hz for notes. i really beg you to not make this mistake. make it possible to additionally be able to either use cent or a ratio (see scala .scl tuning standard) + a base frequency for the whole musician/synth.

btw, how does your tuning for the middle A work if you send frequencies?

and what about other initial parameters than velocity? when you e.g. look at FL Studio, a note can also have additionally a x- and y-value (which can be mapped to anythig by internal synths as Sytrus).

i find it a bit strange that every note can only have a limited + named set of parameters (cutoff, resonance, lfo...). it could eg have 20 filters where i would want to set cutoff-frequency, type, etc for every filter. or just a 20 band eq.

other than that: thanks for reusing some of my thoughts, i'm glad my research didn't die alone in the cold!

greetings,
fabb

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

[Jeff Glatt]

> why are you using "musician numbers" at all?

Because it's intuitive for a real musician. In an electronic studio, the
real musician is a "conductor". He has a bunch of "musicians" at his
disposal. The conductor points to the first musician and says "You
play a C4 note". He points to the second musician and says "You
play an E4 note".

In his "OSC capable" sequencer, he has 2 tracks. On the first track,
he drops down the box labeled "Output" and selects "Fantom X,
musician 1". On the second track, he selects "Fantom X, musician
2". Or maybe he selects "Yamaha Motif, musician 1". He enters a
C4 note on the first track, and an E4 note on the second track. His
workflow is exactly the same as with any MIDI sequencer. (Goodbye
steep learning curve). But now he's using a speedy connection,
hopefully with "plug and play" (which falls outside of the spec I'm
proposing).

Essentially, my "musician" is the same thing as a MIDI channel
(except he doesn't have to worry that both Motif's and Fantom's
musician 1 will play each other's parts, even if their ethernet ports
are daisy-chained together, or they're on the same WIFI -- we're
talking new OSC versions of these units, after all).

Now, I could call it an "OSC channel", and essentially keep the same
terminology as MIDI. But my experience shows that to be a bad
choice. I have a devil of a time explaining what a MIDI channel is to
most musicians. It's too abstract for them. So I explain to them
exactly what I explain at http://home.roadrunner.com/~jgglatt/tutr/multi.htm
and in every single case, I've seen a lightbulb go off in their minds,
and they say "Oh! That makes perfect sense! Why didn't you say
that in the first place??".

Well, now I'm saying it in the first place.

> have a dedicated port for every musician.

A couple reasons why not:

1) A real musician doesn't know what a port is. Too abstract. They have
trouble even with MIDI channels, and at least those are consequently
numbered the same way on every synth. Now, you want him to drop
down the "Output" box and see "Fantom X, port 10043" and "Motif,
port 21156"??? He's going to say "Oh dear. I see big random numbers
following a word I don't even recognize or know what it refers to. I
can't use this". Not a good plan for a UI.

2) You don't need a whole bunch of ports for one device. It's totally
inefficient, uses too many resources, and introduces a whole lot of
complexity where it's not needed. Dealing with one port number is
abstract enough. Dealing with a dozen per synth will drive a musician
mad. They're musicians. Not network programmers.

>don't use Hz for notes

Why not? That's exactly what the synth needs before it can make any sound.

> either use cent

That's a frequency abstraction primarily designed for a 12 tone, equal
tempered western scale. It doesn't work well for other forms of music
because intervals of something besides equal tempered 100 cents per
semi tone look just as strange and arbitrary an abstraction to a musician
as would a frequency. But if that's what you want to inflict upon a
musician, you can easily do that. Just translate the freq to cents.

But don't force the synth to do the opposite. The synth needs a frequency
(or period) -- not cents. You shouldn't be putting user interface
abstractions in a message designed to be used by a CPU.

> or a ratio (see scala .scl tuning standard) + a base frequency

Same abstraction problem as above. Except this is even more alien to a
musician. A musician _may_ have an inkling of what cents relate to,
because the "master tune" parameter on a synth _may_ display the
tuning amount as +/- cents. But he'll typically not be able to tell you
what that means. All he knows is that when the minus sign appears,
the pitch is going down, and when the plus sign appears, the pitch is
going up. When it gets to 100, his equal tempered 12 tone western
scale instrument is a half step sharp or flat.

> how does your tuning for the middle A work if you send frequencies?

You mean for equal-tempered western 12 tone scale? It's 440 Hertz.
For some other tuning scheme? Depends upon the tuning scheme. The
sender of the message has total control over the tuning system used,
and the receiver automatically conforms to that tuning system. All devices
(controlled by the sender) are in tune. The receivers don't even need to
know what tuning scheme is being used.

> what about other initial parameters than velocity? when you e.g. look at
> FL Studio, a note can also have additionally a x- and y-value

Right, and a Roland RD-300 has a controller to control its V-beam. I'm
not trying to define the non-standard, proprietary stuff. Just the stuff
that
you can expect to see upon most pro gear. Remember, it's a standardized
set of messages, which means "the stuff that is applicable to a majority of
products".

> i find it a bit strange that every note can only have a limited + named
> set
> of parameters (cutoff, resonance, lfo...). it could eg have 20 filters
> where
> would want to set cutoff-frequency, type, etc for every filter. or just a
> 20 band eq.

It could. And it could even offer remote, individual control over each one
of the numerous settings for every individual filter. But that would make it
unlike most other gear, in which case, it's left up to the synth to define
any
other OSC messages to control its "proprietary features".

On the other hand, if the day comes when this OSC standard is actually
used by a majority of synths, and we start to see manufacturers wanting
to include 20 band eqs remotely controllable, I'm sure we'll see folks
proposing additional standard messages. You know, the MIDI 1.0
spec was a heck of a lot different than today's MIDI spec. There has
been _tons_ of stuff added. The problem is, due to the nature of the
spec, the expansion capability has pretty much run out. OSC hasn't
even begun to tap into its limit. In fact, it's been vastly underperforming
its limit given how long it has been around now. I was looking through
the archives for this very list, and do you realize that some people were
talking about how they'd like a standardized set of OSC messages to
control music gear back in 2004? And here it's 2009. One would almost
think that OSC is not capable of such a thing. (Incidentally, they're been
talking about standardizing a "discovery system" to make OSC "plug
and play", for even longer. One would almost think that OSC is
incapable of that too... if it weren't for the fact that the few folks who
are actually doing it have all run off and done their own, proprietary,
incompatible schemes. This is "open standardization"???).

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

[Joe Malloch]

Using the term "musician" for synth timbres is confusing - why not
"voice" or "instrument"? Usually instruments make sounds, and
musicians play the instruments.

And what if multiple (human) players are controlling multiple synths
(which may have the same name) on the same network?

This is why id's are desirable.

Joseph Malloch
Input Devices and Music Interaction Laboratory
Schulich School of Music - McGill University
email: joseph.malloch@...
web: http://www.music.mcgill.ca/~mallochj
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Jeff Glatt]

> Using the term "musician" for synth timbres is confusing

Absolutely.

But of course I'm not doing that, and never would.. My
"musicians" have nothing whatsoever to do with timbres (ie,
actual sound). My musicians are the "control routes" -- what
in MIDI is called "channels". (Well, Roland calls them "parts".
Still too abstract, but a little better. It's meant to suggest a
"musical part").

I think you're getting confused by the word "multi-timbral"
(which I do use in my doc, but now that you mention it, I need
to get rid of it. Bad, bad technical abstraction. Evil.). "Multi-timbral"
is the marketing term that pro music companies use for a synth
that supports playing multiple MIDI channels simultaneously (with
each channel "playing" a completely different MIDI stream than
the other channels). If a synth can't do that, it's not multi-timbral.
If it can play upon two or more MIDI channels simultaneously, it's
called "multi-timbral". Why did they use "timbral", which obviously
refers to sound? Because multiple MIDI channels in practical terms
means you can have multiple patches playing simultaneously. So
some marketing genious said "Let's call it multi-timbral so the
musician realizes this feature means his synth can play multiple
patches simultaneously". Bad, bad choice. I wish it weren't so, but
that's what companies like Roland, Yamaha, Korg, Kurzweil, EMU,
etc, etc, all started calling their new "multiple channel" synths when
they started appearing around the late 1980's. They didn't call
them simply "multi-channel synths" because, by then, they realized
what a horrid mistake it was to call the "control paths" channels,
instead of something intuitive to a musician such as... well...
"musicians". Real musicians _still_ didn't understand what a MIDI
channel was years after they were buying Prophet 5's, DX7's,
Roland D-110's and everything else that had a MIDI jack on
it. If the companies called the synths "multiple channels", then
musicians would have said "I _still_ don't know what these channel
things are. I'm not paying even more money for more of these
things.". And the "multi-channel synths" would have been a
marketing bomb. It actually _was_ a marketing bomb. Sequential
Circuits released the first such "multi-timbral" synth, but they didn't
call it multi-timbral. They called it multi-track (actually "trak" cuz
that's such a cute spelling don't you know), which ain't any better
than multi-channel. Musicians didn't know what that meant in
practical terms and it was Sequential Circuits' first total marketing
bomb. I mean, they couldn't give these things away, and this was
during the time when EVERY synth-pop band on MTV had a
Prophet 5 they were pretending to play. (SQ made the Prophet
5).

So all the other companies coming out with their "multiple channel
synths" said "well we know musicians don't understand what MIDI
channels are. And we sure as hell ain't gonna call 'em multi-trak
because this has just about put Seq Circuits out of business". (It
did. SQ went under soon after). The companies _had_ to come up
with a new name anyway, and someone said "Let's sell musicians
on the idea you can play multiple patches simultaneously. Patches
are sounds, right? And timbre is a word that refers to sound. How
about multi-timbral?". And all the music execs said "Oooooo! We
have a winner! Now let's go get some prostitutes.".

And multi-timbral synths were a huge success. I haven't seen a
non-multi-timbral synth in years and years and years. Well, since
the 80's really.

Pay no attention to the man behind the curtain. Whenever you see
the word "multi-timbral" in MIDI specs, always substitute the words
"multiple channels".

But my proposal doesn't call them multiple channels either. I'm
calling them "musicians".

> why not "voice" or "instrument"?

In my proposal, "patches" are called "instruments". Since I believe
you're thinking that I'm talking about patches, as opposed to
"control routes", I'm doing exactly what you've suggested. Good idea.

"Voice" would be closer to "musician", but it still implies "sound"
rather than "control". But "Voice" is already used to refer to
the number of simultaneously sounding oscillators or digital audio
routes in gear (ie, the polyphony). So it would be a really bad choice
to now make it refer to something else. Plus it's still not nearly as
intuitive as "musician". I know, because people visiting my site keep
sending me emails telling me "I never understood what a MIDI channel
was until you described it as a musician in your tutorial. That makes
perfect sense to me".

> Usually instruments make sounds, and
> musicians play the instruments.

Exactly! You got it. That's how a musician sees it. That's
why in my proposal the patches (or "timbres") as you call
them are referred to as "instruments". And the channels (ie,
the things that control, or "play" the instruments) are called
"musicians".

> And what if [there are] multiple synths
> (which may have the same name) on the same network?

You mean like, what if there are two "Roland Fantom XR"
units being used? How does he know which one his sequencer's
"Output" setting is using?

Well, the synth software detects that there are two XRs on
the system, so the choice it gives him are "Fantom XR 1, musician
1", "Fantom XR 1, musician 2", etc. "Fantom XR 2, musician 1",
"Fantom XR 2, musician 2", etc.

Actually, what would be very intuitive would be for the
sequencer software to have an icon of a musician for each synth
on the system. You drag the icon for the synth onto a track, and
the sequencer automatically uses another "musician" on that
particular synth. There's absolutely no reason for the real musician
to know which "musician number" the seq assigned to the track.
When you've run out of musicians for a given synth, then its
icon "grays out", and can't be dragged to another track. This would
be really easy. Musicians would love it.

> This is why id's are desirable.

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

[werteplus]

> why are you using "musician numbers" at all?

Because it's intuitive for a real musician.

err, that's again protocol implementation vs user interface presention
if i may cite you:

I think what you're arguing is that you don't want to show a freq to
an enduser. Fine. You don't have to (and you _shouldn't). You take
the frequency and translate it to a MIDI note (using the chart shown
above), or more appropriately for a musician, translate it to a pitch
name such as C#4 (or draw that note on a manuscript). The fact that
the /SYNTH/NOTE/ON message I propose specifies freq has no
bearing whatsoever upon what manner you present that info to an
enduser. (But for musicians,_ do_ translate it into a note name. Be
nice to your musician friends).

 

why not the same with musicians? doesn't need to be in the protocol, just show it like that to the end user. you could even transfer the name of the device + musician to the host via osc. no precarious midi ways with numbers in the ui.

the only thing against one port per "musician" in in your lenghty argumentition was that it would be inefficient. maybe. but then i'd have to ask you what you had to dismiss with my IDx.x way.
 

>don't use Hz for notes

Why not? That's exactly what the synth needs before it can make any sound.

> either use cent

That's a frequency abstraction primarily designed for a 12 tone, equal
tempered western scale. It doesn't work well for other forms of music
because intervals of something besides equal tempered 100 cents per
semi tone look just as strange and arbitrary an abstraction to a musician
as would a frequency.

 

The whole thing with cents is that it is a logarithmic measurement, so a +20cent interval sounds the same no matter what the original frequency is. independent of what temperament you are using.

But if that's what you want to inflict upon a
musician, you can easily do that. Just translate the freq to cents.

it's not about talking to the musician but about talking to the synth, as the first one is an absolute measurement and the second a relative one. this is no user interface abstraction.
off course the controller *could* always translate its intended cents to frequency, but only if it knows the actual base frequency. and i designed the protocol to let the tone system easily retuned while playing (to enable modulation just by retuning the base frequency). but when there are two controllers and one wants to modulate a synth (or all) globally and a second controller still sends frequency to this controller, it doesn't work out.

 

> or a ratio (see scala .scl tuning standard) + a base frequency

Same abstraction problem as above. Except this is even more alien to a
musician. A musician _may_ have an inkling of what cents relate to,
because the "master tune" parameter on a synth _may_ display the
tuning amount as +/- cents. But he'll typically not be able to tell you
what that means. All he knows is that when the minus sign appears,
the pitch is going down, and when the plus sign appears, the pitch is
going up. When it gets to 100, his equal tempered 12 tone western
scale instrument is a half step sharp or flat.

it should be common knowledge that the 3rd harmonic (on which also the equal temperament builds up) has the frequency ratio of 3/1 or most commonly known as 3/2. my girlfriend learnt that in the first month of her musical school (with 15). ratios are the base of harmonic relationships (and also of the equal temperament!!!) and should therefore *finally* be accessible with tools like osc.

also a ratio is just a ratio, a relative measurement, so we need a base frequency (method) just like with cents.
 

> i find it a bit strange that every note can only have a limited + named
> set
> of parameters (cutoff, resonance, lfo...). it could eg have 20 filters
> where
> would want to set cutoff-frequency, type, etc for every filter. or just a
> 20 band eq.

It could. And it could even offer remote, individual control over each one
of the numerous settings for every individual filter. But that would make it
unlike most other gear, in which case, it's left up to the synth to define
any
other OSC messages to control its "proprietary features".

And cutoff is standard?? i don't agree. all parameters should be accessible. (maybe a linear space as i proposed isn't a great solution, but starting again with a new protocol and forcing controllers to do NRPN-like per-device specific messages makes me puke). sure, one doesn't fit all, but this doesn't fit too many. you couldn't even link those few parameters to all the macro knobs of NI Massive as they are too few.

greetings,
fabb

p.s.: i'm doing what i should have done before: writing down what requirements there are (for my and some other known uses) for such a new protocol.

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