> 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

Sorry if this is a dumb question ... but why would you want to do this in PD, why not use a hardware solution as it would be much faster? Something like Cobranet, ie digital audio over Cat5:

http://www.audioscience.com/internet/products/sound_cards/asi54xx.htm

--
Dan Wilcox
danomatika
www.robotcowboy.com