Re: [PD] looking for a circular buffer for dsp blocks or similar.
Georg Bosch wrote: Am 19.05.2009 um 15:22 schrieb Martin Schied: My idea was, to use a kind of delayline which is big enough to contain the whole signal and then copy the entire content of this delayline in one moment, so in effect no time has been wasted for delaying the signal. It could save 11ms in this example. Hi, Eric Lyon has a delay line with copy-to-buffer feature called el.vdp~, el.vdb~ is also worth a look. i never used them in Pd though and I don't know how instantaneous it copies. thanks for that suggestion, those are nice externals... I tried vdb~ and vdp~ but both of them weren't much easier to use for my intention than creating a new abstraction, see attachment. It's still buggy in some case. It needs tab_copy (from iem_tab in pd-extended) cheers, Martin circular_buffer~-help.pd Description: application/puredata circular_buffer~.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] looking for a circular buffer for dsp blocks or similar.
Thomas Grill wrote: Hi Martin, although i don't fully understand your intentions, you could use xrecord~ and xplay~ (part of xsample) for implementing a circular buffer. gr~~~ Hi, I didn't try xplay~ and xrecord~ yet, but I'll do so when I have more time. to explain my intentions: for example I want to have a record of the past 10 seconds when something triggers the buffer object, in no time. I made an abstraction for this, see attachment in my previous post. thanks anyway! Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] looking for a circular buffer for dsp blocks or similar.
Am 19.05.2009 um 15:22 schrieb Martin Schied: My idea was, to use a kind of delayline which is big enough to contain the whole signal and then copy the entire content of this delayline in one moment, so in effect no time has been wasted for delaying the signal. It could save 11ms in this example. Hi, Eric Lyon has a delay line with copy-to-buffer feature called el.vdp~, el.vdb~ is also worth a look. i never used them in Pd though and I don't know how instantaneous it copies. cheers, g. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] looking for a circular buffer for dsp blocks or similar.
Hi Martin, although i don't fully understand your intentions, you could use xrecord~ and xplay~ (part of xsample) for implementing a circular buffer. gr~~~ Am 19.05.2009 um 15:22 schrieb Martin Schied: Hi! is there already something like a 'circular buffer' external or abstraction for dsp blocks? I want to detect onsets / attacks of 512 sample long signals using [fiddle~ 1024] and write them in arrays of 1024 samples. for now my patch looks like this: the signal is going to [fiddle~ 1024] and to a [delay~] with 576 samples (512 + 64) which is going to tabwrite~. after fiddle~ detects an attack it starts a recording of tabwrite. (see also attached patch) Altogether this process needs 33ms (1024 + 512 + 64 samples) after an attack has happened to record a signal of 22ms. (1024 samples) My idea was, to use a kind of delayline which is big enough to contain the whole signal and then copy the entire content of this delayline in one moment, so in effect no time has been wasted for delaying the signal. It could save 11ms in this example. I'm also open for other suggestions. I already thought of pre- recording blocks with multiple delay~ + tabsend~ and copying them together after a bang from fiddle~, but felt not well by thinking this... also some concerns for this: -using big blocks (1024) there's an additional uncertainity to match analysis windows of fiddle~ so their offset to fiddle~ must be known. -using small blocks (64) this becomes unhandy for long delays when not using dynamic patching (at least with my knowledge of pd) btw. can somebody explain where those additional 64 frames (1 Block) delay are coming from? Is fiddle's (and also bonk's) output delayed by one audio block? attached is an example showing this. (and also the above mentioned) cheers, Martin fiddletest.pd___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] looking for a circular buffer for dsp blocks or similar.
Hi! is there already something like a 'circular buffer' external or abstraction for dsp blocks? I want to detect onsets / attacks of 512 sample long signals using [fiddle~ 1024] and write them in arrays of 1024 samples. for now my patch looks like this: the signal is going to [fiddle~ 1024] and to a [delay~] with 576 samples (512 + 64) which is going to tabwrite~. after fiddle~ detects an attack it starts a recording of tabwrite. (see also attached patch) Altogether this process needs 33ms (1024 + 512 + 64 samples) after an attack has happened to record a signal of 22ms. (1024 samples) My idea was, to use a kind of delayline which is big enough to contain the whole signal and then copy the entire content of this delayline in one moment, so in effect no time has been wasted for delaying the signal. It could save 11ms in this example. I'm also open for other suggestions. I already thought of pre-recording blocks with multiple delay~ + tabsend~ and copying them together after a bang from fiddle~, but felt not well by thinking this... also some concerns for this: -using big blocks (1024) there's an additional uncertainity to match analysis windows of fiddle~ so their offset to fiddle~ must be known. -using small blocks (64) this becomes unhandy for long delays when not using dynamic patching (at least with my knowledge of pd) btw. can somebody explain where those additional 64 frames (1 Block) delay are coming from? Is fiddle's (and also bonk's) output delayed by one audio block? attached is an example showing this. (and also the above mentioned) cheers, Martin fiddletest.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list