[OSC_dev] Adding OSC support to VLC

[salsaman at xs4all.nl]

On Tue, November 25, 2008 00:56, Pascal Baltazar wrote:
> Hi !
>
> on the question of instances (i.e. here /deck ids), we've been
> considering introducing a new reserved character in our use of OSC in
> Jamoma (modular framework for Max/MSP), by using the dot.
>
> /deck.1/play
> /deck.1/pause
>
> which hopefully could help as well humans as machines to distinguish
> between subnodes and instances.
>
> This (and more about requests in Jamoma) is documented on
> http://www.jamoma.org/wiki/NameSpace/
>
> Hope this helps,
>
> pb
>
>
> Le 24 nov. 08 à 23:29, Forwind info a écrit :
>
>>
>> Good work !
>>
>> Would it be useful to consider multiple decks ?
>>
>> /deck/$id/play
>> /deck/$id/pause
>> /deck/$id/stop
>>
>> Conor
>>
>> On Mon, Nov 24, 2008 at 9:26 PM, Nicholas J Humfrey <njh at aelius.com>
>> wrote:
>> Hello,
>>
>> I am thinking about adding OSC support to VideoLan. I did some work on
>> using MPRIS (http://www.mpris.org/), which uses D-Bus to communicate
>> with with VLC, but I am missing OSC and could do without the hassle of
>> running D-Bus.
>>
>> I previously wrote MadJACK, an MPEG Audio Deck which sends its output
>> to Jack:
>> http://www.aelius.com/njh/madjack/
>>
>>
>> I tried to design the protocol to be generic, so that it could be used
>> by other media players too. There doesn't seem to be very much
>> standardisation of OSC messages in the community (apart from the 'SYN'
>> namespace).
>>
>> What do people think about my message format and namespace?
>> Is it useful to standardise the messages for inter-compatibility?
>> Would it be helpful to change the protocol to be able to address
>> multiple decks?
>>
>>
>> My plan is to initially just support the commands that don't need
>> replies:
>> /deck/play
>> /deck/pause
>> /deck/stop
>> /deck/cue (f)
>> /deck/eject
>> /deck/load (s)
>> /deck/volume (s)
>>
>> And if playlists were supported:
>> /deck/add_track (s)
>> /deck/next
>> /deck/previous
>> /deck/repeat (T/F)
>>
>>
>>
>> nick.
>>
>> _______________________________________________
>> OSC_dev mailing list
>> OSC_dev at create.ucsb.edu
>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>>
>> _______________________________________________
>> OSC_dev mailing list
>> OSC_dev at create.ucsb.edu
>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>



The question of standardising commands/namespaces across various
multimedia applications is always an interesting one for me.

There were some moves by Niels Elburg (author of veejay) and myself
(LiVES) to standardise commands for multimedia applications and create OMC
(Open Media Control), this was also supported at the time by the
organisers of piksel in Norway.

However, there has never seemed to be much of an interest amongst other
developers for this, perhaps that will change as more and more multimedia
applications start to implement OSC.

It would be great to get a proper discussion forum going on this. I think
a nice idea would be for the author(s) of each application to list the
functions that they would implement via OSC, and then try to work out some
common kind of syntax.

As was mentioned, the issue of discovery is a very important one. It
should be possible for a control application to query another application
to discover its capabilities, for example whether it supports video out,
audio out, video in, audio in, effects, recording, etc.

A few things I have found useful:

At present I use three ports in LiVES, one is the command socket to
receive commands, the second is a status socket for returning data, and
the third is a notification socket which listeners can monitor for various
events (such as a frame sync). The controller tells the application which
ports to use for status and notifications. Status and notifications are
sent in plain text, so that the control application/script does not need
to implement OSC message decoding.

I also found it useful to implement the following:

/name - returns the namespace of the application
/name/ping - returns "pong" on the status socket - very useful for telling
if the application is running


Gabriel.
http://lives.sourceforge.net