[OSC_dev] SYNoscopy (or something like it)

[werteplus at gmail.com]

>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.create.ucsb.edu/pipermail/osc_dev/attachments/20090131/b5c01fd2/attachment-0001.html