[OSC_dev] OSC_dev Digest, Vol 57, Issue 17

[Gaspard Bucher]

As I see it there are two things needed:

1. common protocol "oscit"
2. known namespaces

The second point either means that the controller B knows the specific
synthetiser A or the namespace this synth is using. This is how
complex midi systems are mapped when a controller has settings for
"Logic Pro", "Reason", etc.

The second point could be implemented on top of "oscillate" (I'll
change the thing name every time until a name is found) by defining a
namespace (response to "/.schema").

Conclusion: there is a need for further standardization in order to
ease compatibility. At least at the "send note" level. But this is a
*big* thing. For example, I think a new implementation of midi should
avoid the 12 notes per octave division. For example, I would like my
keyboard to send the notes from the "Pythagorean tuning" with the base
scale being changed as I play. If we want compatibility at the midi
level but from osc devices that are much more clever, we should use a
translating software from the "better advanced musical thing" to the
"too limited midi". Rubyk would be ideal for this: you write the
mappings in a Lua script. It could even be a standard object
"Synoscopy" that does just the translation between "clever, fine
musical thing" to "midi".

Season's Greetings to you all !

Gaspard

On Wed, Dec 24, 2008 at 1:36 PM,  <werteplus at gmail.com> wrote:
>> About the "oscplanet" name, I prefer names that are somehow linked to
>> metaphors ("Bonjour", "zeroconf", "Safari") but I do not really care.
>> It seems to make sense to include something in the name about the
>> distributed nature of the protocol, since the name refers to the full
>> stack above and not only the query system conventions. Propositions
>> (Only lower-case letters, digits, and hyphens; must begin and end with
>> lower-case letter or digit) :
>>
>> "oscnet" (this sounds a bit too much like .NET to me, but it's easy to
>> pronounce and is meaningful)
>> "oscit" (Open Sound Control it, fun)
>> "oscsqp" (Open Soundc Control Server Query Protocol, cryptic)
>> "oscplanet" (seems too related to rubyk metaphors)
>> "openmediacontrol" (illegal = too long)
>> "omc" (french acronym for WTO: please no)
>
> how about "symbioscis" as things have to communicate symbiosis-like with
> each other?
>
>
> Gaspard, do you think my synoscopy synthesizer thingie was too shortsighted
> in the first place? (i'm now holding off rewriting all of it until a best
> practice thingie seems to take final form)
>
> Back then i looked at the whole thing from the synthesizer manufacturers
> view where gear just has to be able to talk to each other without
> configuration and thus several standard communication capabilities have to
> be understood. without that, there's no chance of osc replacing midi.
>
> such a minimum thing with synthesizers would be how to turn on/off notes (or
> voices as in my proposal). (and maybe other things as volume, pitch bend
> etc).
>
> what i'm now thinking is what when synthesizers get more complicated than to
> offer several "flat" parameters (as at the moment in synoscopy mimed the
> midi way)? i'm totally for the bonjour thing you're talking about, but:
>
> how should the plug'n'play mapping be in the end?
>
> imagine a simple setup, a synthesizer A and a controller B with a piano
> keyboard and some knobs. you connect the two, they say hello (or kiss ;-) ).
> what parameters of A does B control now without doing anything? what if A is
> a complicated synth with many subsynths, each with its own piano roll, which
> one will B's piano control?
>
> generics...
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>