[OSC_dev] Parsing question

[Martin Peach]

The types are all one-byte values packed together. The type list ends with 
at least one zero. After that the data is padded to 4-byte boundaries.
So you look for the comma that starts the list of types (no comma = no 
types) and then count characters until the first zero. That gives you the 
number of data values. For each type you can prepare an appropriate 
container for the data and then fill it later when you scan the data values, 
which arrive in the exact same order as the types.
Martin


Jaime Magiera wrote:
>Reply-To: "Developer's list for the OpenSound Control (OSC) 
>Protocol"<osc_dev at create.ucsb.edu>
>To: OSC_dev at create.ucsb.edu
>Subject: [OSC_dev] Parsing question
>Date: Mon, 17 Dec 2007 15:48:44 -0500
>
>Hey folks,
>
>I'm new to the list, but have been working with OSC for a couple years  
>now. I included the ability to navigate QuickTime VR movies with the  P5 
>Virtual Reality Glove using OSC. It's pretty cool. You can control  QTVR 
>over a network.
>
>I had been relying on third-party OSC frameworks to parse out the  data. 
>However, now I'm attempting to build a full client/server  framework. One 
>thing that I never noticed before about the format: The  argument types are 
>consecutive, with the values aligned afterward.
>
>[type][type][type][data][data][data]
>
>This is extremely counter-intuitive to me, having just spent the past  few 
>years tweaking QuickTime/mp4 atoms, which are...
>
>[[size][type][data]]	[[size][type][data]]	[[size][type][data]]
>
>Could someone give an example of a parsing algorithm to handle OSC  
>arguments? It's not clicking on how you know when the type values end  and 
>the data values begin. This is simple I'm sure, but it's just not  standing 
>out at the moment.
>
>thanks,
>
>Jaime
>
>
>_______________________________________________
>OSC_dev mailing list
>OSC_dev at create.ucsb.edu
>http://www.create.ucsb.edu/mailman/listinfo/osc_dev