[OSC_dev] Everyone Invited - SYNoscopy

[salsaman at xs4all.nl]

On Tue, December 16, 2008 11:49, Gaspard Bucher wrote:
> On Tue, Dec 16, 2008 at 11:27 AM,  <salsaman at xs4all.nl> wrote:
>> On Tue, December 16, 2008 10:13, Gaspard Bucher wrote:
>>> On Tue, Dec 16, 2008 at 12:32 AM,  <salsaman at xs4all.nl> wrote:
>>>> On Mon, December 15, 2008 23:19, werteplus at gmail.com wrote:
>>>>> Come here for helping to work on a proposal of a STANDARD NAMESPACE
>>>>> for
>>>>> controlling SYNTHs and SEQUENCERs.
>>>>>
>>>>> http://synosc.wetpaint.com/
>>>>>
>>>>> Everyone is invited, I will add everyone who wants to take part here!
>>>>>
>>>>> greetings,
>>>>> fabb
>>>>>
>>>>> ps: *ad* Yes, we need YOUR opinion *ad*.
>>>>> _______________________________________________
>>>>> OSC_dev mailing list
>>>>> OSC_dev at create.ucsb.edu
>>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>>>>>
>>>>
>>>> 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 ?
>>>
>>> I am implementing a patcher that will be totally osc addressable
>>> (every node, every method, every inlet). To do this I build a tree
>>> with the objects. When an object's name changes, its url changes. What
>>> you call a "callback" is implemented through a hash of "url" -> object
>>> and every object responds to the C++ virtual "trigger". You can look
>>> at the code (MIT licence):
>>> http://github.com/rubyk/rubyk/tree/master/rubyk/src/core/object.h.
>>>
>>
>> Interesting. Are you planning a C interface also, or will you stick to
>> C++
>> only ?
>
> C++ is sooooo nice for this kind of things: virtuals / templates /
> ownership are things that "could" be implemented in plain "C", but at
> a huge cost.
>
> How would you write this kind of code in C ?
>
>     Root root;
>     SuperSynth * syn = root.adopt(new SuperSynth("super"));
>     Value res = root.call("/super/instrument", String("bells"));
>

I have no idea. What does it do ;-) ? But lets try to avoid the whole C /
C++ holy war.



> For some examples of Object uses, you can have a look at the unit tests:
> http://github.com/rubyk/rubyk/tree/master/rubyk/test/object_test.h
>>
>>
>>> Anyway, I would be glad to join in the discussion on openmediacontrol,
>>> since the "rubyk" protocol (way of addressing nodes, methods, get/set
>>> parameters, create/destroy) is going to be used both in the multimedia
>>> patcher (replacement for max/MSP/Jitter), the interface and some
>>> custom hardware (embedded), I think it needs to be robust and well
>>> thought.
>>>
>>
>> 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)
>>
>
> That's just what we need. Most of the ideas implemented in Object are
> on the general design page for rubyk:
> http://rubyk.org/en/article65.html.
>
>>
>> Please lets have a single discussion venue, which I propose be
>>
>> http://openmediacontrol.wetpaint.com
>>
>
>
> Ok, I posted some comments on openmediacontrol.wetpaint.com. In order
> to ease reading, it would be nice to sign entries or it's hard to
> guess what is an initial proposition and what is a reply.
>
> Gaspard


Yep, I saw that. I have started signing my comments GF.


Cheers,
Salsaman.
http://lives.sourceforge.net