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