Nabble - OpenSound Control (OSC) - Dev

Re: namespace best practice?

2008-08-01T11:19:23Z

On Aug 1, 2008, at 6:32 AM, mart wrote:

> thanks for your suggestion.
> one thing which came to my mind was:
> why not use Xpath as syntax base?

OSC predates the widespread popularity of the XML protocol suite;
however if we were to re-invent the protocol today it would probably
be based on one of the binary XML formats, and XPath would serve a
similar role as does OSC pattern matching syntax. However...
possibly with some restrictions: OSC patterns are restricted
considerably compared to XPath/XQuery, so they can be evaluated in
bounded time (e.g., there is no backtracking, non-greedy qualifiers,
etc).

---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: namespace best practice?

2008-08-01T06:32:44Z

pascal baltazar wrote:

> Hi !
>
> Well, I'm not sure that's a "best practice" (I'm not even sure it's a
> good one, but it exists ;-)
>
> You can have a look here : http://www.jamoma.org/wiki/NameSpace
> where we have described the common namespace for Jamoma (which is a
> framework for MaxMSP)
>
> amongst the addressed points, there is the question you mentioned
> about "instances" and numerical containers :
> our (current) proposal for this kind of problem uses the dot as a
> separator :
>
> "/control.0/control.1/uosc_dev.2/pwm.3 ,i 255"
> to recycle your example
>
>

Hi,

thanks for your suggestion.
one thing which came to my mind was:
why not use Xpath as syntax base?

greetings
mart
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: namespace best practice?

2008-07-30T03:43:53Z

Hi !

Well, I'm not sure that's a "best practice" (I'm not even sure it's a
good one, but it exists ;-)

You can have a look here : http://www.jamoma.org/wiki/NameSpace
where we have described the common namespace for Jamoma (which is a
framework for MaxMSP)

amongst the addressed points, there is the question you mentioned
about "instances" and numerical containers :
our (current) proposal for this kind of problem uses the dot as a
separator :

"/control.0/control.1/uosc_dev.2/pwm.3 ,i 255"
to recycle your example

there's also a discussion about addressing methods rather than values,
using the colon separator. This was extensively discussed in a paper
we published at last NIME (the link is on the webpage above...)

we're also (theoretically) investigating the use of a reserved
character for queries (could be "?") - but that's not mentioned in the
above webpage...

hope this helps....

Best,

pb

Le 29 juil. 08 à 21:10, mart a écrit :

> Hi All,
>
> i am new to OSC and I am pretty much stuck:
> i want to setup a distributed system with several (a lot) of nodes.
> This could be uOSC-devices or so.
> Defining the namespace of methods of one node is pretty much straight
> forward to me:
>
> "/device/id"
> "/device/status"
> "/device/firmware"
> etc..
>
> cool.
>
> I know that the OSC-spec does not provide a namespace convention
> and it is all up to me
> but when it comes to trees of higher orders I don't know what to do:
>
> "/control/0/control/1/uosc_dev/2/pwm/3 ,i 255",
> "/control0/control1/uosc_dev2/pwm3 ,i 255"
> or just
> "/pwm 0 1 2 3 255" ?
>
> it doesn't matter to the specs...
> but containers just called "1" seem ugly to me
> same time "name+id" also doesn't feel right
>
> monome solves the problem by flatting the tree:
> /40h/led [x] [y] [state]
>
> although they could have as well
> put each pixel of the matrix in the path:
>
> /40h/row/1/col/2/pixel/state ,i
>
> and when i got 100 monomes?
> /40h/100/row/1/col/2/pixel/state, i
> or just
> /40h/led [dev] [x] [y] [state] ?
>
> (actually i would be happy if I had one 40h :)
>
> supercollider seems to do the same:
> "/group0/group1/group2/synth/set"
> seems to be representing the setup best, but instead
> something like
> "/n_set <value> <value> <value> <value>"
> is used...
>
> Is OSC here only another network transport layer?
>
> Main problem is that pattern matching does not work anymore.
> Imagine i have a mixer-device with 16 channels
> and another one with 16 channels.
> Don't ask me why, but i want to mute all channels all together:
>
> /mixer/*/chn/*/volume ,f 0
>
> possible?
>
> or only:
>
> /mixer/1/chn/*/volume ,f 0 ?
> /mixer/2/chn/*/volume ,f 0 ?
>
> surely not with a flat representation:
>
> /mixer [id] [chn] [volume]
> /mixer * * 0
>
> I like to use OSC instead of XML.
> I like the idea of publishing OSC-Servers
> via zeroconf in a distributed system (like SC).
> And I like the idea to query a namespace
> by sending "/" (like make controller)
> and getting values by just sending /container/method
> without parameters (like ?)
>
> but i don't know how to nest
> and somehow automatically name
> my units...
>
> so how would look a well-designed namespace of an
> OSC-based distributed system of (u)OSC-entities?
>
> all the best
> mart
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Pascal BALTAZAR
pb@...
http://www.zkrx.org

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: namespace best practice?

2008-07-29T14:52:24Z

Andy W. Schmeder wrote:
> This is a somewhat broad question, however...
>
sorry
> Generally people approach OSC address space design it in terms of the
> RESTful architecture, although not all of its principles apply.
>
>
thanks that was the info i was looking for!
> Generally this would suggest an organization scheme of the sort, /
> devices/{device}/{properties,methods}/{...}
>
>
yes, in the meantime i found the structure of the make controller:

/subsystem/device/property argument

so in an example kind of thing it would be:

/cloud/rain/drop/fall

to make it rain i will call:
/cloud/rain/*/fall "now!"

if i wanna distribute this:

/sky/clouds/cloud/rain/drop/fall

how to make it rain on the whole earth?

thanks for you quick response
i will dive into REST now...
mart

> Another way to look at this is that pattern matching an address
> against the space of known addresses should terminate with the fewest
> possible comparisons.
>
>

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: namespace best practice?

2008-07-29T12:40:44Z

This is a somewhat broad question, however...

Generally people approach OSC address space design it in terms of the
RESTful architecture, although not all of its principles apply.

REST is basically resource-enumeration oriented, i.e., with emphasis
on nouns. Some examples (shamelessly lifted from http://en.wikipedia.org/wiki/Representational_State_Transfer
...)

http://example.com/users/
http://example.com/users/{user} (one for each user)
http://example.com/findUserForm
http://example.com/locations/
http://example.com/locations/{location} (one for each location)
http://example.com/findLocationForm

Generally this would suggest an organization scheme of the sort, /
devices/{device}/{properties,methods}/{...}

Another way to look at this is that pattern matching an address
against the space of known addresses should terminate with the fewest
possible comparisons.

On Jul 29, 2008, at 12:10 PM, mart wrote:

---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

namespace best practice?

2008-07-29T12:10:22Z

Hi All,

i am new to OSC and I am pretty much stuck:
i want to setup a distributed system with several (a lot) of nodes.
This could be uOSC-devices or so.
Defining the namespace of methods of one node is pretty much straight
forward to me:

"/device/id"
"/device/status"
"/device/firmware"
etc..

cool.

I know that the OSC-spec does not provide a namespace convention
and it is all up to me
but when it comes to trees of higher orders I don't know what to do:

"/control/0/control/1/uosc_dev/2/pwm/3 ,i 255",
"/control0/control1/uosc_dev2/pwm3 ,i 255"
or just
"/pwm 0 1 2 3 255" ?

it doesn't matter to the specs...
but containers just called "1" seem ugly to me
same time "name+id" also doesn't feel right

monome solves the problem by flatting the tree:
/40h/led [x] [y] [state]

although they could have as well
put each pixel of the matrix in the path:

/40h/row/1/col/2/pixel/state ,i

and when i got 100 monomes?
/40h/100/row/1/col/2/pixel/state, i
or just
/40h/led [dev] [x] [y] [state] ?

(actually i would be happy if I had one 40h :)

supercollider seems to do the same:
"/group0/group1/group2/synth/set"
seems to be representing the setup best, but instead
something like
"/n_set <value> <value> <value> <value>"
is used...

Is OSC here only another network transport layer?

Main problem is that pattern matching does not work anymore.
Imagine i have a mixer-device with 16 channels
and another one with 16 channels.
Don't ask me why, but i want to mute all channels all together:

/mixer/*/chn/*/volume ,f 0

possible?

or only:

/mixer/1/chn/*/volume ,f 0 ?
/mixer/2/chn/*/volume ,f 0 ?

surely not with a flat representation:

/mixer [id] [chn] [volume]
/mixer * * 0

I like to use OSC instead of XML.
I like the idea of publishing OSC-Servers
via zeroconf in a distributed system (like SC).
And I like the idea to query a namespace
by sending "/" (like make controller)
and getting values by just sending /container/method
without parameters (like ?)

but i don't know how to nest
and somehow automatically name
my units...

so how would look a well-designed namespace of an
OSC-based distributed system of (u)OSC-entities?

all the best
mart

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-21T08:07:16Z

I need to send EEG data that can only be acquired via a PC - I was just
worried about sending (via UDP Multicast) up to 128 channels which are
24bit (although we are converting to 16bit before sending after
filtering out the DC) and can run at up to 8096hz although again we are
down sampling to 256hz before sending although would like to use 512.
All of the filtering, downsampling and sending is done in a small
command line program which accesses the EEG via a DLL via USB.

We are using gigabit ethernet on a local switch and our addressing
information will be very small ie "/eeg1" and i'll send all the channels
in an array of floats to minimize packets.

So things should be fine and I'll get into some implementation and
testing and post results...although im about to go to Europe for 4 weeks
so don't expect anything soon

Thanks again - James

P.S - I was planing to use liblo in the send prog - good idea?

Adrian Freed wrote:

>> Thanks all for your great comments - that micro controllers are slower
>> than a PC was what I was after, during my initial research (I was
>> looking for a paper just like your's Angelo, thanks - and I did check
>> the opensoundcontrol.org website Andy mentioned so might be worth
>> putting it there if you want some more citations) I read that micro
>> controllers could only send at 500hz and I'd just assumed that a micro
>> controller would be much faster than a computer for this type of stuff
>
> I worry your concern about speed is detracting you from the real advantage of microcontrollers over desktop processors for OSC and that is they run simpler, real-time operating systems that can perform the data acquisition and OSC time stamping more accurately than desktop operating systems. Our ICMC2008 paper explains this.
> _______________________________________________
> 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

Re: OSC bandwidth

2008-07-21T06:46:28Z

>Thanks all for your great comments - that micro controllers are slower
>than a PC was what I was after, during my initial research (I was
>looking for a paper just like your's Angelo, thanks - and I did check
>the opensoundcontrol.org website Andy mentioned so might be worth
>putting it there if you want some more citations) I read that micro
>controllers could only send at 500hz and I'd just assumed that a micro
>controller would be much faster than a computer for this type of stuff

I worry your concern about speed is detracting you from the real advantage of microcontrollers over desktop processors for OSC and that is they run simpler, real-time operating systems that can perform the data acquisition and OSC time stamping more accurately than desktop operating systems. Our ICMC2008 paper explains this.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-21T06:42:53Z

>Thanks all for your great comments - that micro controllers are slower
>than a PC was what I was after, during my initial research (I was
>looking for a paper just like your's Angelo, thanks - and I did check
>the opensoundcontrol.org website Andy mentioned so might be worth
>putting it there if you want some more citations) I read that micro
>controllers could only send at 500hz and I'd just assumed that a micro
>controller would be much faster than a computer for this type of stuff
>
>Thanks again everyone

I wonder what conclusion you came to?
We have a cheap microcontroller board we use on our large sensor count instruments that does OSC MUCH faster than the $25 ones we sometimes use. We use it to simultaneously send OSC and 256 channels of 96kHz 24-bit audio over ethernet packets.
The microcontroller in the $100 Make Controller board can also do a lot of I/O.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-21T06:08:44Z

Thanks all for your great comments - that micro controllers are slower
than a PC was what I was after, during my initial research (I was
looking for a paper just like your's Angelo, thanks - and I did check
the opensoundcontrol.org website Andy mentioned so might be worth
putting it there if you want some more citations) I read that micro
controllers could only send at 500hz and I'd just assumed that a micro
controller would be much faster than a computer for this type of stuff

Thanks again everyone

Regards - James
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

XML DTD for OSC

2008-07-21T05:35:07Z

NB: This email and its contents are subject to the Eskom Holdings Limited EMAIL LEGAL NOTICE which can be viewed at http://www.eskom.co.za/email_legalnotice

Hi,
I am busy developing a Vst plugin that bridges OSC and VST data including audio, parameters and TimeInfo data. This is for my thesis project.
I would also like to do a mapping/ translation from VSTXML supplied with post Vst2.4 plugins to an OSC XML file. [This file would be supplied to OSC clients requesting documentation from the OSC server - is this a good idea?]
Has anyone already defined an XML DTD for OSC Packets and/or OSC Server Address Spaces. I would like to avoid re-inventing the wheel here. I have stumbled upon Ben Chuns XML DTD for OSC but I think its incomplete.

Thanks in advance
Jason

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

LibLo 0.25 released

2008-07-18T12:35:49Z

We are pleased to present stable release 0.25 of LibLo, the
lightweight, easy to use implementation of the Open Sound Control
protocol.

Open Sound Control (OSC) is a protocol for communication among
computers, sound synthesizers, and other multimedia devices that is
optimized for modern networking technology.

This release brings several new features, including support for
broadcast messages, multicast UDP groups, message deserialisation, and
input validation.

Details:
- Check for buffer overflows
- Added oscsend and oscdump command-line tools
- Added lo_message_add_varargs() for variable-argument C functions.
- Added lo_bundle_free_messages()
- Bug fix for pattern matching. (curly braces)
- Broadcast support
- Added lo_message_deserialise()
- Multicast support
- Fixes for compiling on OS X
- General bug fixes

Contributions by:
- Camille Troillard
- Chris Hixon
- Kentaro Fukuchi
- Dave Robillard
- Nicolas Humfrey
- Stephen Sinclair

Please feel free to download it at SourceForge:
http://downloads.sourceforge.net/liblo/liblo-0.25.tar.gz

Or read the online documentation:
http://liblo.sourceforge.net

Stephen Sinclair
LibLo maintainer
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC compression (was: OSC bandwidth)

2008-07-17T11:06:31Z

>On Thu, Jul 17, 2008 at 1:28 PM, Andy W. Schmeder
><andy@...> wrote:
>> I am well aware that the O(1) overhead of the header can be a rather
>> large fraction of the total in practice--but this depends greatly on
>> the message, which is why for analysis it should be considered
>> separately. Incidentally, a compression strategy applied to OSC would
>> likely approach this part of the protocol first--e.g. by using a
>> lookup table of common strings. Also, because OSC addresses are human-
>> readable they are an obvious target for compression due to their low
>> information-density (english being only ~1 bit per character).
>
>I've had in mind for a while to try running a stream of OSC messages
>over a TCP connection going through a gzip compression-decompression
>on either side of the connection to see how well that would work.
>However I haven't read up on whether or not gzip is the most
>appropriate approach to compression of streams. Has anyone tried
>this? Are there other compression algorithms better designed for
>streaming data? (In particular I'm imagining problems with an
>ever-growing string table.) I wonder how much CPU overhead it would
>incur. Maybe something extremely simple like run-length encoding
>would even improve bandwidth.

It is best to build or share a dynamic data dictionary for the strings and substitute dictionary references for OSC message strings. There maybe some merit to representing streams of 0's efficiently (e.g.RLL) because so many OSC streams contain values that are cast up from short 8-12-bit integers.

The only case for me where these space efficiencies matter is wireless. It is interesting in many of these applications that the carbon footprint and silicon associated with encryption of the data streams far exceeds any packet encoding costs.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

OSC compression (was: OSC bandwidth)

2008-07-17T11:04:16Z

On Thu, Jul 17, 2008 at 1:28 PM, Andy W. Schmeder
<andy@...> wrote:
> I am well aware that the O(1) overhead of the header can be a rather
> large fraction of the total in practice--but this depends greatly on
> the message, which is why for analysis it should be considered
> separately. Incidentally, a compression strategy applied to OSC would
> likely approach this part of the protocol first--e.g. by using a
> lookup table of common strings. Also, because OSC addresses are human-
> readable they are an obvious target for compression due to their low
> information-density (english being only ~1 bit per character).

I've had in mind for a while to try running a stream of OSC messages
over a TCP connection going through a gzip compression-decompression
on either side of the connection to see how well that would work.
However I haven't read up on whether or not gzip is the most
appropriate approach to compression of streams. Has anyone tried
this? Are there other compression algorithms better designed for
streaming data? (In particular I'm imagining problems with an
ever-growing string table.) I wonder how much CPU overhead it would
incur. Maybe something extremely simple like run-length encoding
would even improve bandwidth.

Steve
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-17T10:28:54Z

On Jul 16, 2008, at 7:14 PM, Angelo Fraietta wrote:

>> With respect to the original query, note that OSC has a protocol
>> overhead of 400% for transmission of single bytes (3-bytes padding
>> + 1
>> typetag)
>
> This statement implies that it only takes four bytes to transmit a
> byte
> of information over OSC. Apart from the four bytes needed for the
> typetag (you need the comma + any padding top keep at the four byte
> boundary), the address space has not been taken into account.

To be precise: everything in the header is worst-case a constant
overhead, i.e., O(1) in space (the "worst-case" qualifier includes the
padding of address and typetag sections), and everything in the data
section is O(n)...

I am well aware that the O(1) overhead of the header can be a rather
large fraction of the total in practice--but this depends greatly on
the message, which is why for analysis it should be considered
separately. Incidentally, a compression strategy applied to OSC would
likely approach this part of the protocol first--e.g. by using a
lookup table of common strings. Also, because OSC addresses are human-
readable they are an obvious target for compression due to their low
information-density (english being only ~1 bit per character).

Arguments considered separately, the overhead of transmitting n 4-byte
datums (e.g. float32, int32) is +1 byte, or 5/4*n. For a null-
terminated string length n, worst case is n + 5. A blob length n is
worst-case n + 9 (when n == 0). Datums smaller than the 4-byte
boundary will obviously have the highest cost--for example, n single
bytes, packed individually gives 5*n. For n single bits, 8*n using
the "T" and "F" typetags.

It is possible that a future version of OSC will recommend a vector
typetag that makes transmission of floats something more like that of
the blob -- that has been requested here before.

OSC does not claim to be optimized for low-bit depth integers
(contrast to MIDI). There is an assumption that float32 is a
preferable format for gesture data, e.g. for uniform representation
over multiple bit depths. A specific use-case for this was described
in the micro-OSC paper at NIME08, which presents functionally
identical data-streams for two variants of a microprocessor having 10-
and 12-bit ADCs [1]. This is an example of convenience over
compactness, which is also a justifiable design decision in terms of
the "carbon footprint" -- in 2002 NIST estimated that software bugs
cost the US economy $60 billion annually [2].

1: http://cnmat.berkeley.edu/publication/uosc_open_sound_control_reference_platform_embedded_devices
2: http://www.nist.gov/public_affairs/releases/n02-10.htm

---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-16T19:14:09Z

Andy W. Schmeder wrote:

> With respect to the original query, note that OSC has a protocol
> overhead of 400% for transmission of single bytes (3-bytes padding + 1
> typetag)

This statement implies that it only takes four bytes to transmit a byte
of information over OSC. Apart from the four bytes needed for the
typetag (you need the comma + any padding top keep at the four byte
boundary), the address space has not been taken into account.

Also, overhead is more than just the number of bytes contained in a
message. If anyone is interested in efficiency and speed, have a read
of the research paper as it dispels a lot of the myths regarding OSC on
these issues.

--
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page

http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-16T15:49:10Z

With respect to the original query, note that OSC has a protocol
overhead of 400% for transmission of single bytes (3-bytes padding + 1
typetag), however for transmission of floats the overhead is only 25%.

Reminder for the list; any paper which discusses OSC (e.g. such as the
one referenced below) may be added to the repository at http://opensoundcontrol.org/publications
-- after creating an account on the site, go to http://opensoundcontrol.org/node/add/biblio

On Jul 16, 2008, at 3:13 PM, Angelo Fraietta wrote:

>
>
> James Sheridan wrote:
>> Hi - im looking at sending EEG data over OSC and was wondering how
>> quick
>> I can reliably transmit messages.
>>
>
> I just presented a paper about this at NIME this year. It might
> explain
> things a bit.
>
> http://www.smartcontroller.com.au/publications/Nime2008.pdf
>
> --
> Dr Angelo Fraietta
> A.Eng, A.Mus.A, BA(Hons), Ph.D.
>
> PO Box 859
> Hamilton NSW 2303
>
> Home Page
>
>
> http://www.smartcontroller.com.au/
>
> There are those who seek knowledge for the sake of knowledge - that is
> CURIOSITY
> There are those who seek knowledge to be known by others - that is
> VANITY
> There are those who seek knowledge in order to serve - that is LOVE
> Bernard of Clairvaux (1090 - 1153)
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-16T15:13:56Z

James Sheridan wrote:
> Hi - im looking at sending EEG data over OSC and was wondering how quick
> I can reliably transmit messages.
>

I just presented a paper about this at NIME this year. It might explain
things a bit.

http://www.smartcontroller.com.au/publications/Nime2008.pdf

--
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page

http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-16T10:01:58Z

16 floats * 500 hz = 0.25 Mbit/sec, plus some overhead for the OSC
protocol, which I'd guess is about 20+8 bytes * 500 hz =~ 0.1 Mbit.
For an embedded microprocessor, this may be a fairly fast rate, but
for a standard computer it is trivial.

Where you might get into trouble, however, is with software commonly
used with OSC--for example, event-domain numerical processing in Max/
MSP or PD may easily be 10-100 times slower than the equivalent
implemented with hand-coded in C. That is the (rather large) cost of
convenience that we pay for using these rapid-prototyping
environments. Even in these environments, rates of 500 hz and up
shouldn't immediately be problematic.

On Jul 16, 2008, at 5:16 AM, James Sheridan wrote:

> Hi - im looking at sending EEG data over OSC and was wondering how
> quick
> I can reliably transmit messages.
>
> I know it depends on message length but I'd be keeping things simple
> and
> sending 16 floats at a time and would like to achieve rates above
> 512hz?
>
> is this possible with OSC? I've tried to find some stuff on the web
> and
> the only thing that mentioned message rates was about how the hardware
> implementations of OSC can achieve 500hz - they didn't say if the
> receiving computer was limiting this or if it was faster than a
> computer
> can handle.
>
> Regards - James
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC bandwidth

2008-07-16T07:02:19Z

Hi James,

On Wed, Jul 16, 2008 at 8:16 AM, James Sheridan
<james.sheridan@...> wrote:

> Hi - im looking at sending EEG data over OSC and was wondering how quick
> I can reliably transmit messages.
>
> I know it depends on message length but I'd be keeping things simple and
> sending 16 floats at a time and would like to achieve rates above 512hz?
>
> is this possible with OSC? I've tried to find some stuff on the web and
> the only thing that mentioned message rates was about how the hardware
> implementations of OSC can achieve 500hz - they didn't say if the
> receiving computer was limiting this or if it was faster than a computer
> can handle.

It's incorrect to say that OSC can "achieve" anything.. it's just a
message packet format. The speed you can achieve depends on how much
overhead it adds, vs. the capabilities of your network connection. On
today's 1 Gbps ethernet I'd say that it's more than likely possible to
go at that speed. Particularly if it's unidirectional.

In terms of raw speed, OSC adds a little overhead over custom UDP
networking, but (imho) not all that much. It adds a few bytes for the
address string, which can be short or long depending on how verbose
you want to be, and then one byte per message argument for the type
string. It requires a bit of processing on the receiving side to
parse the format and the address string.

There may be other constraints depending on what implementation you're
using and in what software/hardware context, but you haven't given any
of those kind of details. To get an answer more concretely, I suggest
you just perform some tests. This can be done pretty easily using
PureData, for example, if you want to avoid C programming.

Steve
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

OSC bandwidth

2008-07-16T05:16:10Z

Hi - im looking at sending EEG data over OSC and was wondering how quick
I can reliably transmit messages.

I know it depends on message length but I'd be keeping things simple and
sending 16 floats at a time and would like to achieve rates above 512hz?

is this possible with OSC? I've tried to find some stuff on the web and
the only thing that mentioned message rates was about how the hardware
implementations of OSC can achieve 500hz - they didn't say if the
receiving computer was limiting this or if it was faster than a computer
can handle.

Regards - James
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

data transport

2008-07-13T12:07:49Z

hi stephen, there's a couple of options.

here's a direct libpcap to OSC converter:
http://xdv.org/cgi-bin/viewcvs.cgi/gsniff/

or check this work:
http://delysid.org/schearnet.html

at the xdv site we also have a perl wrapper for tcpdump and i think
the wiretap project has similar utilities (try google).

you should get a good start from any of these.
bst, opt

stephen@... writes:
> Hi,
>
> My end goal is to get live data from the tcpdump application (network traffic sniffer) into the SuperCollider environment so that I can produce sound based on the input from tcpdump. I have gotten some feedback, and am wondering if having a C/C++ program in the middle the accept piped data from tcpdump and then send it to Supercollider as OSC messages would be the best way to go? Any other suggestions? What would be the best way to get started with this? I really need to know how to setup a program to read data piped to it in the first place, and then I need to know how to take that data and send it as an OSC message.
>
> All input is greatly appreciated!
>
> Thanks!
>
> _______________________________________________
> 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

data transport

2008-07-13T10:47:37Z

Hi,

My end goal is to get live data from the tcpdump application (network traffic sniffer) into the SuperCollider environment so that I can produce sound based on the input from tcpdump. I have gotten some feedback, and am wondering if having a C/C++ program in the middle the accept piped data from tcpdump and then send it to Supercollider as OSC messages would be the best way to go? Any other suggestions? What would be the best way to get started with this? I really need to know how to setup a program to read data piped to it in the first place, and then I need to know how to take that data and send it as an OSC message.

All input is greatly appreciated!

Thanks!

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: OSC_dev Digest, Vol 51, Issue 4

2008-05-01T02:11:17Z

an usb pic for osc? i'm excited! since i successfully built the
midibox http://www.ucapps.de/ , i want to do the same with an osc
controller!
will it also be as easily buildable as the midibox?

how do you translate the osc messages to the tcp/udp port so the
applications understand?

greetings
fabb

> >> BTW:
> >> the upcoming OSC hardware kit will implement time tags and
> >> scheduling.
> >> -Is this a new version of CNMAT's Connectivity Processor?
> > Was never answered...
>
>
> No it is a microcontroller firmware for the USB PIC processors.
> Details will be published in the NIME08 proceedings.
>
> Unfortunately the project isn't up for public release yet but we are
> close.

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: Invitation: OSC meeting at NIME08

2008-04-28T18:53:52Z

Arie van Schutterhoef wrote:
>>Nime08 is in Genova, Italy. It will take place near or at the conference...
>
> -Prevailing ignorance: are there already dates settled for this [for the
> conference-not my ignorance]?

5-7 June
http://nime2008.casapaganini.org/

--
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page

http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: Invitation: OSC meeting at NIME08

2008-04-28T17:42:45Z

>Nime08 is in Genova, Italy. It will take place near or at the conference...
-Prevailing ignorance: are there already dates settled for this [for the
conference-not my ignorance]?

AvS

PS: So close in Europe. Would be nice talking to you in realtime...

......................................................................
......................................................................
` *===========================================================+++
` |arsche.net sound-image-word http://www.arsche.net/index.html |
*===========================================================+++
` |Schreck Ensemble/Assembly - live electro-acoustic music- |
` | http://www.schreck.nl/index.html |
` *===========================================================+++
` |S T R A T I F I E R - a multi-dimensional controller- |
` | http://www.stratifier.nl/index.html |
` *============================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
......................................................................

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: Invitation: OSC meeting at NIME08

2008-04-28T17:22:00Z

> >I am organizing an informal OSC meet at NIME08
>-Hopefully not being too much behest with ignorance, but where will this
>glorious event take place?

Nime08 is in Genova, Italy. It will take place near or at the conference...
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: Invitation: OSC meeting at NIME08

2008-04-28T16:13:40Z

On Apr 28, 2008, at 3:09 PM, Arie van Schutterhoef wrote:

>> BTW:
>> the upcoming OSC hardware kit will implement time tags and
>> scheduling.
>> -Is this a new version of CNMAT's Connectivity Processor?
> Was never answered...

No it is a microcontroller firmware for the USB PIC processors.
Details will be published in the NIME08 proceedings.

Unfortunately the project isn't up for public release yet but we are
close.

---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu
phone: +1-510-643-9990 x.313
cell: +1-510-717-6653

Programmer/Analyst II
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: Invitation: OSC meeting at NIME08

2008-04-28T15:09:11Z

>I am organizing an informal OSC meet at NIME08
-Hopefully not being too much behest with ignorance, but where will this
glorious event take place?

AvS

BTW:
>the upcoming OSC hardware kit will implement time tags and scheduling.
>-Is this a new version of CNMAT's Connectivity Processor?
Was never answered...

......................................................................
......................................................................
` *===========================================================+++
` |arsche.net sound-image-word http://www.arsche.net/index.html |
*===========================================================+++
` |Schreck Ensemble/Assembly - live electro-acoustic music- |
` | http://www.schreck.nl/index.html |
` *===========================================================+++
` |S T R A T I F I E R - a multi-dimensional controller- |
` | http://www.stratifier.nl/index.html |
` *============================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
......................................................................

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Invitation: OSC meeting at NIME08

2008-04-28T11:53:19Z

Following the tradition Matt started I am organizing an informal OSC meet at NIME08 - probably around a dinner meal. Please let me know if you are interested in attending and also if there are any particular things you would like to discuss at the meeting.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: using oscgroups for routing between apps on a singlemachine

2008-04-28T02:41:57Z

Hi Tim

Yeah. The way the sockets are multiplexed doesn't really support the way you want to set things up at the moment.

1) I think the main issue you need to sove is supporting multiple client applications on a single machine. The simplest way to solve this would be to support multiple localrxports (just keep a vector of them and forward incoming traffic to all of them). This wouldn't give each client application its own oscgroup user name, but it might be enough.

2) Point-to-point routing is a bit different, and means being able to address OSC packets to specific users (endpoints) rather than broadcasting them out to every listener. My idea for this would be to just routing messages within the osc packets sent to oscgroups so it knows which client(s) to forward to.

Much as I would like to help you implement this, my schedule is pretty busy at the moment. Feel free to take a look at the code and ask questions if things seem unclear.

Cheers

Ross.

----- Original Message -----

From: tjt@...

To: osc_dev@...

Sent: Saturday, April 19, 2008 2:49 PM

Subject: [OSC_dev] using oscgroups for routing between apps on a singlemachine

I'd like to use oscgroups ( http://www.audiomulch.com/~rossb/code/oscgroups/ )

for routing messages between applications. I've got it working in an environment where each application

and the server run on separate machines, but I'd like to route messages between applications on the same machine,

and I haven't been able to figure out how to do that. If I run only one OscGroupClient, multiple applications

can't all listen to its output port simultaneously, and if I try to run two OscGroupClient's on the same machine,

things seem to get confused. In the README of oscgroups, Ross says that one of the planned   extensions is

"point-to-point routing in OscGroupClient", which sounds like what I would want.   Does anyone know of a way

to use oscgroups with multiple applications (that all want to access the tx and rx ports of OscGroupClient)

on the same machine?   Has anyone extended OscGroupClient to do point-to-point routing?

        ...Tim...

_______________________________________________
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

using oscgroups for routing between apps on a single machine

2008-04-18T21:49:49Z

I'd like to use oscgroups ( http://www.audiomulch.com/~rossb/code/oscgroups/ )

for routing messages between applications. I've got it working in an environment where each application

and the server run on separate machines, but I'd like to route messages between applications on the same machine,

and I haven't been able to figure out how to do that. If I run only one OscGroupClient, multiple applications

can't all listen to its output port simultaneously, and if I try to run two OscGroupClient's on the same machine,

things seem to get confused. In the README of oscgroups, Ross says that one of the planned extensions is

"point-to-point routing in OscGroupClient", which sounds like what I would want. Does anyone know of a way

to use oscgroups with multiple applications (that all want to access the tx and rx ports of OscGroupClient)

on the same machine? Has anyone extended OscGroupClient to do point-to-point routing?

...Tim...

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[ANN] NetUtil 0.34

2008-04-15T06:40:16Z

hello,

this is a micro update of the java OSC library NetUtil. the code
remains the same as v0.33, but i added the missing javadoc comments
for OSCPacketCodec which was introduced in v0.33. In particular, the
docs of OSCPacketCodec.Atom briefly show how you would design codecs
to deal with extra types such as RGBA colour values or Boolean values.

this update v0.34 is synced with SVN revision 5, but anyone
interested in the development should preferably stick to SVN.

http://sourceforge.net/projects/netutil

ciao, -sciss-

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Re: handling nil/inf in oscpack

2008-03-31T10:22:06Z

Typically "N" goes to NULL or its equivalent in the target environment (C: int 0, Python: None, etc).

Mapping "I" to infinity is redundant with the existing capabilities of "f", and also doesn't cover the standard use cases of that number class (e.g. positive and negative infinity) -- if this was the original intention then it wasn't well thought-out (I have no idea...).

In Open Sound World, we mapped "I" to the impulse (i.e., "bang" for MaxMSP/PD users). Also in CNMAT's resonators~ object the bang input is equivalent to a dirac impulse, so this sort of makes sense on that level.

I've seen other implementations setup some sort of class or typedef for these "weird" types and just pass that on to the user to interpret.

On Mar 29, 2008, at 12:16 AM, Ross Bencina wrote:

Probably the correct fix for the stream interface would be to return INF as a float with value numeric_limits<float>::infinity() and Nil perhaps as an int with value 0.

---

Andy W. Schmeder

andy [at] cnmat.berkeley.edu

phone: +1-510-643-9990 x.313

Programmer/Analyst II

Center for New Music and Audio Technologies

University of California at Berkeley

http://cnmat.berkeley.edu

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev