Hello,
In the lighting domain, we transmit images to the control console by
using one protocol, the same that controls our media server (that
protocol is CITP/MSEX running on ArtNet).
When you control video devices, it would be nice to see on the
controller what you do, so that you don't need to be anymore along your
computer.
A VJ can for example go to the dancing floor playing with hiss iPhone
and controlling his VJ software there, in place of being stuck near his
computer, far away from the crowd.
In my case, transmitting images though OSC is a real need. And I will do
for my application. Up to the OSC controllers to support it or not.
Using more than one protocol to transmit so little data (thumnails, not
full HD videos) is overkill, even more for little controllers as iPhones.
Kind regards,
Xavier.
salsaman@... a écrit :
> Huh...? This makes no sense at all to me - the "C" in OSC stands for
> *control* - in other words it is a control channel, not a data channel...!
>
> To me it is far more logical to send any data out of band, but for example
> you could enclose this with a "sending data" / "data-received","checksum"
> exchange.
>
> This is exactly what I am doing with LiVES - OSC is control only, actual
> video and audio data are sent via other routes (e.g. video/audio jack,
> ogg)
>
> There are various advantages to splitting this way, for example you can
> more easily interlace/multiplex your data, you can send control messages
> during the data transfer (for example a restart/cancel, volume change,
> etc), also the command channels are kept quieter, thus more responsive.
>
> Seems a bit lazy to me to want to send control and data all on the same
> channel.
>
>
> Just my opinion...
>
> Salsaman.
>
http://lives.sourceforge.net>
>
>
> On Thu, March 5, 2009 19:33, Stephen Sinclair wrote:
>> The idea occurred to me once that it certainly would be nice to be
>> able to send meta data with blobs so that they could be interpreted
>> correctly. This could include applications like streaming audio data
>> -- you would want information about sample rate, compression, etc.
>> Another use case for meta data would be for sending things like
>> matrices: row/column information would be necessary. (Right now I am
>> sending matrices as lists of 9 or 16 floats)
>>
>> Well, for the former case (images, sound files), the internet is
>> fortunately already well-populated with standards for file types:
>> e.g,
http://en.wikipedia.org/wiki/MIME>>
>> I suppose you could even just send a message with two blobs: a MIME
>> header and a file. Of course, it might not fit in a UDP message, so
>> you might want to use TCP, and in that case, perhaps you also might as
>> well be using HTTP instead of OSC... but I digress.
>>
>> For the problem of sending metadata about vector/matrix formats, I
>> have no solution except to define application-specific standards.
>> (i.e., my receiver "knows" that a certain message has a 3x3 matrix as
>> its 9 arguments.) Does anyone know if there are any existing metadata
>> standards for identifying mathematical data structures?
>>
>>
>> Steve
>>
>>
>> On Thu, Mar 5, 2009 at 3:07 AM, Gaspard Bucher <
gaspard@...> wrote%3
>
> _______________________________________________
> OSC_dev mailing list
>
OSC_dev@...
>
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
smime.p7s (4K) 