[PD] how to avoid (most/many/some) readsf~ dropouts

Matt Barber brbrofsvl at gmail.com
Tue Jul 15 20:12:47 CEST 2008

> Of course, the 8-channel environment is useful for its ambisonic and other
> spatialization potential, and one solution that works well (for certain
> musical situations) is to spatialize monophonic soundfiles in real time.
>  This is a great solution for reducing performance demand on the hard drive,
> but quickly becomes expensive in CPU cycles...

Right.  You can split the difference, though, if you're using
ambisonics, provided you're using B-format (wxyz).  You can do all
your ambisonic encoding and room simulation ahead of time, and then do
the decoding in Pd. This way you'd only be reading four channels at a
time, and the conversion from B-format to 8-channels is a fairly
inexpensive set of multiplies and adds (a little more expensive if
it's a "cube" rather than an "octagon" array, I think, since you could
discard the "Z" harmonic with the octagon; in Pd a cube decode could
be on the order of 24 +'s and as few as 4 *'s, most of the adds taking
place in connections as the vectors are automatically added) -- you
could easily make an abstraction to just put on the end right before
you send it to [dac~], since b-format streams should mix linearly.
I'm sure there are externals which could do this more efficiently than
an abstraction (loathe as I am to use externals when there's an easy
abstraction solution).  In this setup, normalization becomes a little
harder, though.

It would also be useful if you later wanted to do some simple
ambisonic "panning" of the solo marimba throughout the array - you'd
have half the architecture you'd need for it, and B-format encoding of
two or three streams is not gonna break the bank (unless you were
doing some kind of full-on room simulation on top of it).

The point is moot if you're using 2nd-order ambisonics, though, or if
you've already spent a lot of time mixing and normalizing.

As an aside, for pieces with different sections and patches with
modularized processes, it might be a good idea to use the fade-in and
fade-out in conjunction with [switch~] for expensive processes so that
you're only burning cycles when the subpatch or abstraction for that
section or process is being used -- but you have to be careful when
there are delays involved since, iirc, delay lines maintain their
state when they're shut off.  You also have to insulate its [line~]'s
and such from being triggered while it's off -- but it's easy enough
to simply use [spigot]s to keep the patch from receiving any message
at all.


More information about the Pd-list mailing list