[OSC_dev] OSC_dev Digest, Vol 57, Issue 2

[werteplus at gmail.com]

>
> I think it would be best if we stick to one "hello" protocol. Maybe you
> could take a look at the proposal on openmediacontrol.wetpaint.com, I have
> some tried and working suggestions there.
>
> Also, I am curious to know how you support variables in the namespace, for
> example ID1 and ID2.
>
> In all of the OSC code I have seen, only constant namespaces can be used.
> How do you for example, create an OSC branch with a variable namespace.
> And if you link this to a callback, how does the callback know the value
> of the variable part(s) of the message ?
>
> Regards,
> Gabriel "salsaman",


I have posted this proposal of mine as it was (made one year ago after I
learned about every protocol detail in MIDI). There are surely many stupid
things in it. It's not actuality a "hello" protocol, but a static namespace
for support of all the stuff that happens in MIDI. I didn't see the main
focus of OMC in this task (and there are *no* functions for controlling
synths in OMC AFAISee), I thought of it more as a media player control.
Sorry if I got you wrong here. I'm totally for merging if possible, but I'm
afraid the focus differs. Think of a stupid MIDI (now OSC) keyboard which
doesn't know about it's environment and you want to control some synths with
it. You at least have to know where and in which format you send played
notes to that's where I tried to standardize.

There is currently NO way of asking values of the destiny with SYNoscopy,
that's surely a todo.

IDs can currently have additional aliases /SYN/alias/etc, so that IDx can
still be used for dumb keyboards as stated above. that's because I think
it's needed to also support dumb gear (maybe it's not the way to go). same
could go for parameters.
but yes, differing parameter count + type should get communicated.


> I'm curious to know why you chose to stick to integral types to
> represent fractional values, like with pitch or tempo. Why not simply
> send floats, and let the synths interpret them to the best of their
> capacity? By using these integral types, you effectively just extend
> the limits a little more than what MIDI did, but not that much. For
> example 1.5 days worth of musical time is a rather strange restriction
> - not very useful if you're doing sound installations for example.
>
> Cheers,
> Carl
>

I thought about about this too, maybe customized types would indeed be
better (or two floats, one for the whole and one for the fractional part)


>
> PS. I would have left a comment on the wiki, but I'm not going to
> create yet another web account just for that. Any way to disable that?
>

I now opened the wiki http://synosc.wetpaint.com/ for everyone WITHOUT login
now. Hopefully no spammers will come.

Right. Yes please join in the discussion. A standard is badly needed -
> even within my own application there are conflicting syntaxes used, which
> makes it difficult to expand the commandset.
>
>
> > We are currently all bumping into the fact that OSC is a *partial*
> > standard. It says how to adresse methods, but that's about it. Those
> > of us building tools that need to interact smoothly with one another
> > need some standard ways to get return values, get/set parameters, etc.
> >
>
> Right again. This is precisely what is needed.
>
> As a minimum we should have:
>
> - a standard for getting/setting/querying values
>
> - standard for getting/setting parameters (including where there can be a
> variable number of parameters of various types)
>
> - a "hello" standard for unknown applications
>
> - a method of capability discovery with some standardised methods
>
> - possibly, standard notifications for events (for example, frame_synch
> for video, packet_synch for audio)
>

I'm with you here, but I also think a specialized MIDI-replacing standard is
aslo needed (which could be a subgroup of this).

No competition here :-)
Everyone is welcomned of taking parts of SYNoscopy and incorporate it into
OpenMediaControl.

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