[OSC_dev] SYNoscopy (or something like it)

[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"???).