[PD] Re: Buffer Type Question

chris tyrrell shaper_mechanist at yahoo.co.uk
Thu Jul 29 09:44:56 CEST 2004


IOhannes m zmoelnig wrote: 
"i have heard about a love-patch that guarantees four
inches."

- nice comeback ;-) back to the issue at hand though:

I think we need to tease out the semiotics of what
stefan turner is talking about; a freezable delay
line. the thing is, an audio delay line "appears" to
be an audio buffer which outputs its contents after a
time delay, the time delay deciding the size of the
buffer (correct me if im wrong). In a sense then what
Stefan is asking for is not freezable delays but the
guts of the delay line laid open for use, don't know
what you would call that exactly, definitely not a
delay line though because i dont think delaying would
be its primary function.
Perhaps Stefan for what you want to do you could use
what i'm trying to make right now, which is an
xgroove~ object whose start and end points move as the
file is being played (you could of course use other
ways to play the file as i remember it someone made a
patch which worked in a very similar way to xgroove~),
the start and end points stay either side of the read
point and move with it while it is being played but
when the start and end point automation is paused the
whole thing loops for that portion of time. ultimately
as long as the file already exhists there is no need
to read in and out of buffers if you have the right
arrangements placed around your file player. The
problem im having is the automation, i need some way
to count along with the player but thusfar all the
counters i have tried haven't been fast enough as they
rely on metro which only goes so fast before it
becomes more of a hinderence than a help, possibly
i'll play with the maths - count up in 2's or 4's or
64's or something. on the other hand if you want to
stream data in live there seems to be no other way
than to write and read to an array (please do correct
me if im wrong), perhaps the kludging could be
improved by synchronising the mathematics since the
kludging seems to be caused by timing errors (overlaps
and gaps and such). Strangely i was reading the
max/msp tutorials and they seemed to say that the only
way to automate messages beyond the control speed
limit (1 millisecond on max and i thought i read
something about 1.45 milliseconds on pd - correct me
if im wrong) is to drive them using audio signals, but
i dunno, im probably misinterpreting it and am still
pretty clueless, i would very much appreciate someone
saying something sensible on the issue of control rate
versus audio rate....


=====
 



	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun!  http://uk.messenger.yahoo.com




More information about the Pd-list mailing list