[OSC_dev] Everyone Invited - SYNoscopy
Gaspard Bucher
gaspard at teti.ch
Sun Dec 21 12:06:04 PST 2008
On Sun, Dec 21, 2008 at 8:21 PM, Jeff Mann <jeff at jeffmann.com> wrote:
> Hi all -
>
> Interesting discussion going on here. Thought I'd throw in my 2 cents.
> My use of OSC is perhaps different from most of the applications being
> talked about in this "open media control" discussion.
>
> I'm working more with interactive art installations, kinetic/robotic
> sculpture, physical computing, and so on. So for me, most of the
> concepts of "multimedia" being talked about, i.e. decks, play/pause,
> etc., are not relevant. And even more fundamental concepts like a
> "controller" and "synth/player", tend to make assumptions about overall
> system architecture that are not appropriate for my needs (I've found
> this is also a bias of OSC itself). For example, I would be more
> interested in interactions within networks of autonomous peer nodes with
> various capabilities, behaviours, and intelligence...
This is also my field (live art with some AI).
>
> On the other hand, there are some topics being addressed here that are
> highly relevant for what I'm working on, and I think for users of OSC in
> general. I'm very eager to see some solutions. For example:
>
> salsaman at xs4all.nl wrote:
> >> On Tue, December 16, 2008 10:13, Gaspard Bucher wrote:
>>>>> 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
>
> One of the most frustrating things about OSC for me - and apparently for
> many others - is the lack of definition for querying values and
> parameters, discovery, and other closely related issues.
>
> For example, the MAKE Controller microcontroller board uses this system:
>
> /servo/1/position 26 - set servo motor 1 to position 26.
> /servo/1/position - with no argument, query the current position.
> /servo/1/position 26 - this is the response to the above query.
>
> This is all well and good, until you try to get two MAKE controllers to
> talk to each other - board A queries board B, but the response actually
> sets the position of board A's servo...
To avoid this problem, I propose that the answer is :
/~/servo/1/position 26
One char = light and fast.
>
> This might seem like a simplistic example, but consider that this is one
> of the more popular commercial products that implements OSC...
>
> There have been numerous discussions and proposals about these issues in
> OSC, but so far it seems like no consensus at all. I would love to see
> this worked out! So I'm happy to see some interest in this at the moment.
>
> On the other hand, and this is the main point I'd like to make, I don't
> think this has - or should have - anything to do with "multimedia".
>
> I'm sure it's a good idea to make some standardizations, namespaces,
> etc., for general purpose multimedia applications - audio synths, video
> players, etc. - to talk to each other using OSC. And maybe that could
> have a name, like "Open Media Control", similar to the "MIDI Show
> Control", that's based on MIDI. However, I think the above issues about
> queries and so on are issues that pertain to, and need to be solved for,
> OSC in general - and not only in the context of multimedia application
> software. Multimedia applications are just one subset of things that OSC
> can be used for. In other words, it would not be a good idea to think in
> terms of replacing or superceding the name "Open Sound Control" with a
> new and improved "Open Media Control", any more than it would be to
> replace MIDI with MIDI Show Control. We all know that OSC does more than
> sound, but it also does more than media.
>
I agree (see my other mail on the "browser" use case). We do not need
names, we need a way to get them from the running applications through
a set of tiny conventions.
> I don't want to discourage people from talking about it in the context
> of the "open media control" discussion/wiki - on the contrary, I think
> it's really needed. The desire to do something very practical and useful
> - standardizations for multimedia apps - highlights some of the
> fundamental things missing from OSC in general, and I hope will drive it
> towards some solutions.
>
> So basically I'd suggest a two-pronged approach. The first would be to
> look further at these issues of mechanisms for queries and so on, but in
> a more general OSC scope, so that any solutions will be applicable
> generally in OSC, and not be tied to any of the specifics of multimedia
> apps. Then, building on that to create a more domain-specific set of
> standards for multimedia apps.
>
I also want to stay at the low level of these things and only move as
far as to show the "browser" thing I mentioned in my previous mail.
Gaspard
More information about the OSC_dev
mailing list