And what if you misunderstood? :) I apologise for not explaining it very well first time.
In an unfrozen delay line (always, currently) the most recent point (delay=0) is always 'now'. If you could 'freeze' that delay line at a certain point in time, call it t, then from then on the delay line will _always_ have that point t as the most recent (delay=0). Data between t and 'now' would not be stored in the line. The data stored in the line would not be changed until 'unfrozen', when it would go back to normal operation. You are talking about freezing the reading, and as you say this is quite easy. I am talking about freezing the _writing_.
As for why you would want to do this, one example I would like to use it for is granular sampling. At the moment you need to kludge it with a buffer: freezable delay lines would be much nicer, I think.
Sorry for the long reply, I hope this makes more sense.
Stefan
Message: 9 Date: Sat, 24 Jul 2004 18:31:36 +0200 From: IOhannes m zmoelnig zmoelnig@iem.at To: Stefan Turner stefan_turner@yahoo.co.uk CC: pd-list@iem.at Subject: Re: [PD] Buffer Type Question
Stefan Turner wrote:
Hi I think what Chris meant (correct me if wrong) was freezing a delay line so that the read and write pointers stay as they are and nothing new is
written:
then for example a vd~ on a frozen delay line with delay going from 1sec to 0sec over 1sec would have
the
same effect as delread~ on unfrozen delay line with delay of 1sec. This can sort of be done using a
normal
buffer instead, but it would be nice to just be able to send a 'freeze' (or whatever) message to a delwrite~ instead.
if i read the question correctly then: how do you create your delay going from 1s to 0s in 1000ms ? most probably you will use [line~] to control [vd~] and what if you could send a [stop( message to [line~] to freeze the delay-amount ? and what if this has been implemented into [line~] since i know it (which is probably *very* long)
mfg.a.sdr IOhannes
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Hello Stefan and list,
Tuesday, July 27, 2004, 10:59:36 PM, you wrote:
ST> You are talking about freezing ST> the reading, and as you say this is quite easy. I am ST> talking about freezing the _writing_.
you may write your signal to an array with [phasor] and freeze the recording process by sending it a zero-signal. To unfreeze the process (and continue from the point you get stopped) send the previous frequency value to a [phasor].
wow, i finally got back online (im having unexplained trouble with my email provider)...hmmmmm in hindsight that original message was vague and filled with innacurate statements (in my circle im famous for shooting my mouth off), i have a feeling i wasnt in a state of mind at the time which would allow me to ask incisive questions....what i was saying when i discussed freezing a delay sort of refered to the whole issue of "granular sampling" that mr. turner brought up, although it was mostly a rhetorical question, also i was thinking of freeverb~ which has a freeze reverb tail function and i was just trying to remember the exact ins and outs of the moorer schroeder reverb, but at the time i wasnt sure what i was thinking so i made a rather vague statement which probably isnt so useful to the issue of computer music (i'm an artist by trade - well i try - and in that field of work vagueness and mystery is often a virtue)...
anyhow all that stuff about block~ and signal~ was probably me just being a jerk, when things are going well on pd i want to give everyone hugs and kisses but when things go wrong i feel like chasing computer programmers through fields in a disturbing hommage to planet of the apes, i only wish though my terminology had at least been accurate, what i meant to say was there a way of sending data to the objects in a more "mobile" sort of way rather than by having "message" messages, "set 4096 1 1" for example, it probably would have been useful to ask why certain externals take certain messages, would it for example be really bad to change the buffersize constantly during operation?...oh yeah and that stuff about control inlets, well that was just a categorical error on my part...i wasnt thinking straight at the time...
oh yeah and finally mr. smoelning this is the second time you have been mean to me, dont you love me? why cant we all get along? has anyone done a patch implementing an internation group hug?
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
wow, i finally got back online (computer trouble - blah)...hmmmmm in hindsight that original message was vague and filled with innacurate statements (in my circle im famous for shooting my mouth off), i have a feeling i wasnt in a state of mind at the time which would allow me to ask incisive questions....what i was saying when i discussed freezing a delay sort of refered to the whole issue of "granular sampling" that mr. turner brought up, although it was mostly a rhetorical question, also i was thinking of freeverb~ which has a freeze reverb tail function and i was just trying to remember the exact ins and outs of the moorer schroeder reverb, but at the time i wasnt sure what i was thinking so i made a rather vague statement which probably isnt so useful to the issue of computer music (i'm an artist by trade - well i try - and in that field of work vagueness and mystery is often a virtue)...
anyhow all that stuff about block~ and signal~ was probably me just being a jerk, when things are going well on pd i want to give everyone hugs and kisses but when things go wrong i feel like chasing computer programmers through fields in a disturbing hommage to planet of the apes, i only wish though my terminology had at least been accurate, what i meant to say was there a way of sending data to the objects in a more "mobile" sort of way rather than by having "message" messages, "set 4096 1 1" for example, it probably would have been useful to ask why certain externals take certain messages, would it for example be really bad to change the buffersize constantly during operation?...oh yeah and that stuff about control inlets, well that was just a categorical error on my part...i wasnt thinking straight at the time...
oh yeah and finally mr. smoelning this is the second time you have been mean to me, dont you love me? why cant we all get along? has anyone done a patch implementing an internation group hug?
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
chris tyrrell wrote:
would have been useful to ask why certain externals take certain messages,
actually this is very complicated to answer. when i write externals i have 2 choices for messages to externals:
- something very simple; e.g: a "float" message to a [f] does really
what i would expect it to do 2) convention: 2a) e.g: gem-objects respond to a "gem_state" message; this has been true for years and i don't see a reason to change this - so every new gem-object will respond to a "gem_state" message too 2b) when extending the functionality of an object, sometimes you come to the point when you say "oh, why haven't i thought before! "set" would be an ideal message for this functionality but unfortunately it is already used"
ad 1) there are two things one could do about it: learn the pd-language and read the help-patches ad 2) convention is the daemon that is lurking everywhere in pd. by convention signal-objects end with a "~", by convention max-compatibility is not broken willingly,... ad 2a) who is to blame ? ad 2b) and who is to blame here ? it would be simple to change the messages an object responds to (from a programmer's side of view), but i try to avoid to do so because it would break each and every patch that relies on an older version of the external.
would it for example be really bad to change the buffersize constantly during operation?
basically pd's dsp-engine is not designed for this. this makes it quite unusable to work with compressed-data with non-fixed blocksizes; furthermore it only allows blocksizes which are 2^n.
indeed it would be a great feature to make the blocksize change deliberately, but i do think that it will be a lot of work (and performance is likely to decrease drastically)
oh yeah and finally mr. smoelning this is the second
feel free to call me by my forename like everybody else.
time you have been mean to me, dont you love me? why
it is my evil twin that is sitting before my computers, trying to answer questions on the pd-list.
cant we all get along? has anyone done a patch implementing an internation group hug?
i have heard about a love-patch that guarantees four inches.
mfg.a.sdr IOhannes
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
Thanks Yury and ba for replies. This is what I meant by kludging it with buffers...it doesn't seem too great a way of doing it, in my opinion, when the data is already stored in the delay line. Adding a 'freeze' (or 'stop' or whatever) method would be much more efficient and elegant and it does not break anything using delay lines already. Using the method below is essentially implementing a circular buffer like a delay line... which can also be frozen. I just think it would be nicer to do this using the proper built-in delay lines. It was just an idea anyway...
Stefan
--- Yury yurolog@mail.ru wrote: > Hello Stefan and list,
Tuesday, July 27, 2004, 10:59:36 PM, you wrote:
ST> You are talking about freezing ST> the reading, and as you say this is quite easy. I am ST> talking about freezing the _writing_.
you may write your signal to an array with [phasor] and freeze the recording process by sending it a zero-signal. To unfreeze the process (and continue from the point you get stopped) send the previous frequency value to a [phasor].
-- Best regs, Yury
mailto:yurolog@mail.ru
___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
-
chris tyrrell -
IOhannes m zmoelnig -
Stefan Turner -
Yury