Re: Open Sound Control

On May 12, 10:54 pm, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:
On May 12, 11:30 pm, "dave.joub...@xxxxxxxxxxxxxx"



<dave.joub...@xxxxxxxxxxxxxx> wrote:
On May 12, 10:13 pm, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:

On May 12, 11:02 pm, "dave.joub...@xxxxxxxxxxxxxx"

<dave.joub...@xxxxxxxxxxxxxx> wrote:
On May 12, 8:51 pm, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>
wrote:

On May 12, 4:35 pm, "dave.joub...@xxxxxxxxxxxxxx"

<dave.joub...@xxxxxxxxxxxxxx> wrote:
On May 12, 1:54 pm, Uwe Klein <uwe_klein_habertw...@xxxxxxxxxxx>
wrote:

dave.joub...@xxxxxxxxxxxxxx wrote:
I had a read through my code again, and I can see that a re-write that
sticks to binary (rather than working in hex) would probably speed it
up.

Dave

What about enhancing binary scan with a "zero terminated string" format/object?

binary scan $buffer IzI..

uwe

Hi Uwe,

Such an enhancement would only be useful in an OSC context, if it
could follow the OSC rule that there will be between 1 and 4 bytes of
\0s at the end of the string to pad it to a 32bit boundary.

Unfortunately, one of the other OSC objects, the blob, will still
require additional passes, because it is specified as [32bit len][X
bytes of data][0-3 bytes of padding to bring it to a boundary]. The
two most obvious implementations of a 'z' specifier (consume one null
byte / consume all null bytes (might chomp a byte out of the following
32bit int)) will not work with the OSC spec.

While I admit that OSC payload format is not really [binary]-friendly,
there may be an acceptable middle ground, taking advantage of the
32bit-aligned scheme:

- first pass, scan the whole packet as i*, returning a list of
integers.
- indexing pass, scan this list one variable-length thing at a time,
looking for null-padding with

if {!($value & 0xFF)} {
# the string ends in this word
# a few more tests with 0xFF00, 0xFF0000 and 0xFF000000
# to get the precise length

and also keeping track of blob-lengths. While this scanning takes
place, you're building up a new formatString made of i (integers), f
(floats), aNUMBER(strings), xNUMBER(padding).

- final pass, one single [binary] with the built formatString (and
var list) swallows it all in one gulp.

Since I have no real OSC cases to play with, I have not yet written
the code, but if you send me a large sample of payload, we could go
into a nice timing race. Just tell me.

-Alex

Hi Alex,

That sounds like a good approach. I would suggest that you use the
code I put in the link, on the sender side. That way you can control
the payload and test the individual cases, ie you can keep using the
old library on the one side, and start writing the new unpack routines
on the other side.

I will sit down build a bulk-sender, in such a way that lots of UDP
packets are pre-calculated, and then fired off as quickly as possible.
I will not be able to do anything for the next 24 hours; we have a
company meeting to which I have to travel to.

OK. To optimize both our schedules, I would appreciate a raw binary
file to decode, instead of having to set up whatever contraption makes
sense in that strange OSC world. In case you wondered, I'm more
interested in helping you exploit 100% of Tcl's abilities and playing
with the technical challenge, than in learning much about OSC ;-)

There is a OSC spec issue that you need to be aware of. In one place,
the writer got himself confused, and said a string is terminated with
0-3 nulls, and in another place, the example he shows, uses 1 to 4
nulls. The 1 to 4 nulls is the correct spec for strings, and 0-3
correct for blobs. He forgot that the string has to have a termination
null (whereas the blob has a length (32bit int) to help it).

OK, I had somewhat groked that, thanks.

-Alex

A binary file containing one UDP packet or many? If many, what you you
like as the separator between the packets ?

Many, to be realistic.
For this I usually do the following simple text/binary alternance:

fconfigure stdout -translation binary
foreach packet $l {
puts [string length $packet]
puts -nonewline $packet
}

which is simply read back with

fconfigure stdin -translation binary
while {1} {
if {[gets stdin len]<0} break
set packet [read stdin $len]
...
}

-Alex

Initially, I have put sampledata.bin on the website, as well as a new
test program, tcl4c.tcl, which produce when decoded (via tcl4a.tcl):
path=/alpha/beta/gamma , types={iiissiiTsFNIssfisbssmssts} ,
values=[32767 32768 32769 omega gamma 32768 0 alpha beta alpha
12345.6787109 1 a 001133557799bbddff00 a alpha 195051776 beta alpha
-3759595228763401487 beta]

The only non-standard feature is that the blob is displayed in hex
(001133557799bbddff00)

I really have to prepare my report for tomorrow....

Dave
.

Relevant Pages

  • Re: Open Sound Control
    ... \0s at the end of the string to pad it to a 32bit boundary. ... 32bit int)) will not work with the OSC spec. ... A binary file containing one UDP packet or many? ... fconfigure stdin -translation binary ...
    (comp.lang.tcl)
  • Re: how to store list of varying types
    ... When there's a variable-length string, ... typedef struct { ... pointer null, and the second one the CString object. ... then have to finish constructing the packet by copying the two data objects ...
    (microsoft.public.vc.mfc)
  • Can anyone help me out?
    ... int main{ ... string fname; ... Packet *packet = new Packet; ... packet->package(filename, filesize, buffer); ...
    (comp.unix.programmer)
  • Re: Open Sound Control
    ... \0s at the end of the string to pad it to a 32bit boundary. ... 32bit int)) will not work with the OSC spec. ... place, you're building up a new formatString made of i, f ... 0-3 nulls, and in another place, the example he shows, uses 1 to 4 ...
    (comp.lang.tcl)
  • Re: Open Sound Control
    ... \0s at the end of the string to pad it to a 32bit boundary. ... 32bit int)) will not work with the OSC spec. ... packets are pre-calculated, and then fired off as quickly as possible. ... 0-3 nulls, and in another place, the example he shows, uses 1 to 4 ...
    (comp.lang.tcl)