iirc, for the very project the decoding is done outside of Pd anyhow (on specialized hardware), so the problem of [unpackOSC] not knowing what to do with a blob is a minor issue here. (and the use of specialized hardware is the reason why data (low-resolution fixed-point numbers) should actually be packed in a blob rather than floating-point).

The decoding should be done on a microcontrollerboard and in puredata too. The audio data will be sent over ethernet to the target device, there it should be decoded and played back. The problem lies at the ethernet layer, where only a 10Mbit/s wire is available. At a Samplingrate of 44100Hz and a word width of 32bit are only about 7 channels (without overhead,...) possible. So it would be fine to reduce the resolution from 32bit floating point to maybe 16bit or even 8bit fixed point (while 32bit floating point is still selectable in case of better hardware). Sending 16bit or 8bit samples over OSC (without losing the gained bit width (OSC-data-types are at least 32bit)) will require an arbitrary alignment of the bits within each OSC-data-argument, where BLOB comes into play.

i still think (see above) that even [packOSC] cannot provide a consistent interface to pack blobs into an osc message that is sufficiently more simple to use than manually constructing OSC messages.

Thanks

Wolfgang

Yes, try netsend~ and netreceive~, by Olaf Matthes.

There's a recent update (with some fixes) available at: http://www.remu.fr/sound-delta/netsend~/?page_id=7

older version: http://www.nullmedium.de/dev/netsend~/

or in svn: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/olafma... ~/

• It doesn't seem to be in Pd-extended though...

Nicholas Mariette

Researcher Audio and Acoustics group LIMSI-CNRS, Orsay, France http://www.limsi.fr/Scientifique/aa/ http://www.limsi.fr/Scientifique/ps/thmsonesp/SonEspace http://soundsorange.net nicholas.mariette@limsi.fr

On May 11, 2009, at 5:00 PM, Martin Peach wrote:

IOhannes m zmoelnig wrote:

...

Martin Peach wrote:

...

Wolfgang Jäger wrote:

...

Hello,

For sending audio efficiently over OSC I would need an OSC-"BLOB". Unfortunately the packOSC object supports no OSC-"BLOB"s. Is there any possibility to send BLOBs?

since blob is an arbitrary type, you have to interpret/generate
this list of bytes somehow in your patch. if you are working that low-level, i guess you can also de/ construct OSC-packages on your own.

...

...

ciao

I can probably add a Blob type to [packOSC] and [unpackOSC]. The
thing is that the blob type is supposed to consist of arbitrary
bytes (8-bits), but Pd audio works with 32-bit floats. There is
nothing [unpackOSC] can do with a received blob except output the
list of bytes, so some other object would be needed to pack groups
of 4 bytes into floats again. It may end up being just as efficient to send a bunch of floats
for each signal vector.

iirc, for the very project the decoding is done outside of Pd
anyhow (on specialized hardware), so the problem of [unpackOSC] not
knowing what to do with a blob is a minor issue here. (and the use
of specialized hardware is the reason why data (low-resolution
fixed-point numbers) should actually be packed in a blob rather
than floating-point). i still think (see above) that even [packOSC] cannot provide a
consistent interface to pack blobs into an osc message that is
sufficiently more simple to use than manually constructing OSC
messages.

It might be interesting to have a [netsend~] and [netreceive~] pair
that send/receive raw Pd sound vectors like [send~] -- no OSC or
fancy formatting, just UDP packets with floats, except that the
first element of the list would probably have to be the number of
floats in the vector unless it's fixed for all time.

[osc~ 330] | [netsend~ 127.0.0.1 9998]

[netreceive~ 9998] | [dac~]

Martin

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list