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
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.
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
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
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
-
Georg Bosch -
Martin Schied -
Thomas Grill