OSC 1.1 Specification: Arrays
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
 |
OSC 1.1 Specification: Arrays
by Julian Rohrhuber
::
Rate this Message:
Reading the OSC 1.1 Specification, I realised that there is no
mention of making array typetags part of the standard. Is there a strong reason not to do so? I think this kind of nesting would be very useful to convey structural information, and avoid an explosion of special idiosyncratic commands. Implementation should be usually straightforward. In SuperCollider, the bracket-chars [ ] are already used to send arrayed arguments to the server, and there is a client side implementation to support arbitrary nesting of lists. any ideas / comments? -- . _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
|
|
|
Re: OSC 1.1 Specification: Arrays
by Julian Rohrhuber
::
Rate this Message:
>I also think using "[]" for array is a good idea.
> >We are already using this as a type signature within oscit values but >we still need to modify oscpack to support it (type supported inside >an oscit application but not through network). > >Example of such a typetag: fs[ffs] > >We also needed a dummy type tag: * > >This tag is used to answer type queries and say: "you can send me any >type". It does not correspond to any value (like TrueTag, Nil, etc). That seems like a good idea. Using brackets, this could even be delimited in size: fs[*]iif. >Gaspard > >On Mon, Jul 13, 2009 at 12:16 AM, Julian >Rohrhuber<rohrhuber@...> wrote: >> Reading the OSC 1.1 Specification, I realised that there is no >> mention of making array typetags part of the standard. Is there a >> strong reason not to do so? I think this kind of nesting would be >> very useful to convey structural information, and avoid an explosion >> of special idiosyncratic commands. >> >> Implementation should be usually straightforward. In SuperCollider, >> the bracket-chars [ ] are already used to send arrayed arguments to >> the server, and there is a client side implementation to support >> arbitrary nesting of lists. >> >> any ideas / comments? >> -- >> >> >> >> >> >> . >> _______________________________________________ >> 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 -- . _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
|
|
|
Re: OSC 1.1 Specification: Arrays
by Andy W. Schmeder-2
::
Rate this Message:
The [ ] typetags are already on the list of optional types from OSC
1.0, several implementations support it, and its existing semantics are adequately documented. Certainly it has some applications but I'm not sure that it should be moved up to "required" status. OSC doesn't handle highly structured data very well anyways (in particular at the message-level), would this make that much of a difference? On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote: > Implementation should be usually straightforward. In SuperCollider, > the bracket-chars [ ] are already used to send arrayed arguments to > the server, and there is a client side implementation to support > arbitrary nesting of lists. --- 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 1.1 Specification: Arrays
by Julian Rohrhuber
::
Rate this Message:
Ok, this makes sense. It would not be good to require it, I guess. It
could be encouraged though, since it seems to make sense whenever there is structural data being exchanged. >The [ ] typetags are already on the list of optional types from OSC >1.0, several implementations support it, and its existing semantics >are adequately documented. > >Certainly it has some applications but I'm not sure that it should be >moved up to "required" status. OSC doesn't handle highly structured >data very well anyways (in particular at the message-level), would >this make that much of a difference? > > >On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote: > >> Implementation should be usually straightforward. In SuperCollider, >> the bracket-chars [ ] are already used to send arrayed arguments to >> the server, and there is a client side implementation to support >> arbitrary nesting of lists. > >--- > >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 -- . _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: OSC 1.1 Specification: Arrays
by Jamie Bullock
::
Rate this Message:
Personally, I've given up trying to use OSC for structured data. Instead I generally run two parallel services -- XML-RPC for structured data and OSC over UDP for 'control' messages. Choosing the right tool for the job seems better than trying to make a circle fit in a square hole! Jamie -- http://www.jamiebullock.com On 12 Aug 2009, at 11:08, Julian Rohrhuber wrote: > Ok, this makes sense. It would not be good to require it, I guess. It > could be encouraged though, since it seems to make sense whenever > there is structural data being exchanged. > >> The [ ] typetags are already on the list of optional types from OSC >> 1.0, several implementations support it, and its existing semantics >> are adequately documented. >> >> Certainly it has some applications but I'm not sure that it should be >> moved up to "required" status. OSC doesn't handle highly structured >> data very well anyways (in particular at the message-level), would >> this make that much of a difference? >> >> >> On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote: >> >>> Implementation should be usually straightforward. In SuperCollider, >>> the bracket-chars [ ] are already used to send arrayed arguments to >>> the server, and there is a client side implementation to support >>> arbitrary nesting of lists. >> >> --- >> >> 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 > > > -- > > > > > > . > _______________________________________________ > 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 1.1 Specification: Arrays
by Julian Rohrhuber
::
Rate this Message:
Makes sense. A little bit of structure though as a convention
wouldn't hurt - after all it is much easier to implement arrays in osc than an xml parser, and it is faster as well I guess. >Personally, I've given up trying to use OSC for structured data. >Instead I generally run two parallel services -- XML-RPC for >structured data and OSC over UDP for 'control' messages. Choosing the >right tool for the job seems better than trying to make a circle fit >in a square hole! > >Jamie > >-- >http://www.jamiebullock.com > > > >On 12 Aug 2009, at 11:08, Julian Rohrhuber wrote: > >> Ok, this makes sense. It would not be good to require it, I guess. It >> could be encouraged though, since it seems to make sense whenever >> there is structural data being exchanged. >> >>> The [ ] typetags are already on the list of optional types from OSC >>> 1.0, several implementations support it, and its existing semantics >>> are adequately documented. >>> >>> Certainly it has some applications but I'm not sure that it should be >>> moved up to "required" status. OSC doesn't handle highly structured >>> data very well anyways (in particular at the message-level), would >>> this make that much of a difference? >>> >>> >>> On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote: >>> >>>> Implementation should be usually straightforward. In SuperCollider, >>>> the bracket-chars [ ] are already used to send arrayed arguments to >>>> the server, and there is a client side implementation to support >>>> arbitrary nesting of lists. >>> >>> --- >>> >>> 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 >> >> >> -- >> >> >> >> >> >> . >> _______________________________________________ >> 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 -- . _______________________________________________ OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
|
|
Re: OSC 1.1 Specification: Arrays
by Gaspard Bucher
::
Rate this Message:
I am currently building an iPhone application to test the oscit
protocol and library. Array support was mandatory in order to save bandwidth and processing. Parsing typetags like "[s[s[s[*s]][s[sss]][s[sss]][s[sss]][s[sss]][s[sss]][s[ssss]][s[fffss]]]]" is not unusual as replies when discovering urls and what they do. In order to use array markers, I had to add the type tags '[' and ']' to oscpack and adapt the parser (osc--> Value) for recursion. If you need more complex data types, there is also a fast json implementation based on ragel (json --> Value ---> json) so it's easy to transform data to json and send it all as a single string (or to save it on disk). Since the code is released under an MIT licence, feel free to reuse all or parts of the parsing code. Gaspard On Tue, Aug 18, 2009 at 10:40 PM, Jamie Bullock<jamie@...> wrote: > > Personally, I've given up trying to use OSC for structured data. > Instead I generally run two parallel services -- XML-RPC for > structured data and OSC over UDP for 'control' messages. Choosing the > right tool for the job seems better than trying to make a circle fit > in a square hole! > > Jamie > > -- > http://www.jamiebullock.com > > > > On 12 Aug 2009, at 11:08, Julian Rohrhuber wrote: > >> Ok, this makes sense. It would not be good to require it, I guess. It >> could be encouraged though, since it seems to make sense whenever >> there is structural data being exchanged. >> >>> The [ ] typetags are already on the list of optional types from OSC >>> 1.0, several implementations support it, and its existing semantics >>> are adequately documented. >>> >>> Certainly it has some applications but I'm not sure that it should be >>> moved up to "required" status. OSC doesn't handle highly structured >>> data very well anyways (in particular at the message-level), would >>> this make that much of a difference? >>> >>> >>> On Jul 12, 2009, at 3:16 PM, Julian Rohrhuber wrote: >>> >>>> Implementation should be usually straightforward. In SuperCollider, >>>> the bracket-chars [ ] are already used to send arrayed arguments to >>>> the server, and there is a client side implementation to support >>>> arbitrary nesting of lists. >>> >>> --- >>> >>> 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 >> >> >> -- >> >> >> >> >> >> . >> _______________________________________________ >> 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 > OSC_dev mailing list OSC_dev@... http://lists.create.ucsb.edu/mailman/listinfo/osc_dev |
| Free embeddable forum powered by Nabble | Forum Help |
