Re: [PD] looking for a circular buffer for dsp blocks or similar.

2009-05-22 Thread Martin Schied

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.

2009-05-22 Thread Martin Schied

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.

2009-05-21 Thread Georg Bosch


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.

2009-05-21 Thread Thomas Grill

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.

2009-05-19 Thread 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
Description: application/puredata
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list