hi,
i'd like to record continuously into an array to make a circular
buffer/array.
i'm using tabwrite~ to record, retriggering the recording start by a
metro.
this - no surprise - results in clicks at the start/end of the array.
is there some way to make this work without dropouts?
delwrite~/read~ would be an option if the memory space could be
accessed in pd from other objects.
v
how do you read the array? just fast, I'm thinking of adding a fade in +
fade out. you can put it either before the recording, or after reading it.
just depends where it's easier to detect the array's writing/reading point
going from xxx to 0.
I don't know if Grill's xsample library can help you, I don't know it
myself - http://puredata.info/Members/thomas (not included in Pd-ext).
João
hi, i'd like to record continuously into an array to make a circular
buffer/array. i'm using tabwrite~ to record, retriggering the recording start by a
metro. this - no surprise - results in clicks at the start/end of the array. is there some way to make this work without dropouts?delwrite~/read~ would be an option if the memory space could be accessed
in pd from other objects.v
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
thanks for your suggestions, guys. sorry, if i wasn't clear, but i'm not looking for (cross)fades.
i'd like to perform circular recording into an array, constantly
overwriting what has been recorded before.
so if you put the playhead a little behind (or before - as it's
circular it depends on your view) you get a simple delay.
as the trigger to start recording with tabwrite~ is not sample
accurate, i can't get a constant recording without clicks at the
trigger points - at least not with my limited understanding of pd.
but i think i've just found a solution using poke~ (which seems to be
the same as in max).
thanks, volker.
On 18.01.2010, at 11:46, João Pais wrote:
how do you read the array? just fast, I'm thinking of adding a fade
in + fade out. you can put it either before the recording, or after
reading it. just depends where it's easier to detect the array's
writing/reading point going from xxx to 0.I don't know if Grill's xsample library can help you, I don't know
it myself - http://puredata.info/Members/thomas (not included in Pd- ext).João
It would also be possible to do this using [delay~] objects instead of arrays.
~Kyle
On Mon, Jan 18, 2010 at 10:15 AM, volker böhm vboehm@gmx.ch wrote:
thanks for your suggestions, guys. sorry, if i wasn't clear, but i'm not looking for (cross)fades.
i'd like to perform circular recording into an array, constantly overwriting what has been recorded before. so if you put the playhead a little behind (or before - as it's circular it depends on your view) you get a simple delay. as the trigger to start recording with tabwrite~ is not sample accurate, i can't get a constant recording without clicks at the trigger points - at least not with my limited understanding of pd.
but i think i've just found a solution using poke~ (which seems to be the same as in max).
thanks, volker.
On 18.01.2010, at 11:46, João Pais wrote:
how do you read the array? just fast, I'm thinking of adding a fade in +
fade out. you can put it either before the recording, or after reading it. just depends where it's easier to detect the array's writing/reading point going from xxx to 0.
I don't know if Grill's xsample library can help you, I don't know it myself - http://puredata.info/Members/thomas (not included in Pd-ext).
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry, I skimmed that first email too quickly.
Delaywrite~/read~ objects would definitely be a decent alternative if you want to avoid clicking sounds. It is possible to tap a delay from multiple patches, as long as it is not named with a $0 at the beginning. I would use this approach unless you for some reason would want to save the internals of the delay buffer, which seems unlikely.
~Kyle
On Mon, Jan 18, 2010 at 2:26 PM, Kyle Klipowicz kyleklip@gmail.com wrote:
It would also be possible to do this using [delay~] objects instead of arrays.
~Kyle
On Mon, Jan 18, 2010 at 10:15 AM, volker böhm vboehm@gmx.ch wrote:
thanks for your suggestions, guys. sorry, if i wasn't clear, but i'm not looking for (cross)fades.
i'd like to perform circular recording into an array, constantly overwriting what has been recorded before. so if you put the playhead a little behind (or before - as it's circular it depends on your view) you get a simple delay. as the trigger to start recording with tabwrite~ is not sample accurate, i can't get a constant recording without clicks at the trigger points - at least not with my limited understanding of pd.
but i think i've just found a solution using poke~ (which seems to be the same as in max).
thanks, volker.
On 18.01.2010, at 11:46, João Pais wrote:
how do you read the array? just fast, I'm thinking of adding a fade in +
fade out. you can put it either before the recording, or after reading it. just depends where it's easier to detect the array's writing/reading point going from xxx to 0.
I don't know if Grill's xsample library can help you, I don't know it myself - http://puredata.info/Members/thomas (not included in Pd-ext).
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If I'm not mistaken, I believe the trick to getting this to work is to make sure the array size is a multiple of the block size. [tabwrite~] conforms to block boundaries, to if you bang it in the middle of a block, it won't begin writing until the end of the block. That's probably where the clicks are coming from.
.mmb
volker böhm wrote:
thanks for your suggestions, guys. sorry, if i wasn't clear, but i'm not looking for (cross)fades.
i'd like to perform circular recording into an array, constantly overwriting what has been recorded before. so if you put the playhead a little behind (or before - as it's circular it depends on your view) you get a simple delay. as the trigger to start recording with tabwrite~ is not sample accurate, i can't get a constant recording without clicks at the trigger points - at least not with my limited understanding of pd.
but i think i've just found a solution using poke~ (which seems to be the same as in max).
thanks, volker.
On 18.01.2010, at 11:46, João Pais wrote:
how do you read the array? just fast, I'm thinking of adding a fade in + fade out. you can put it either before the recording, or after reading it. just depends where it's easier to detect the array's writing/reading point going from xxx to 0.
I don't know if Grill's xsample library can help you, I don't know it myself - http://puredata.info/Members/thomas (not included in Pd-ext).
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
i'd like to perform circular recording into an array, constantly overwriting what has been recorded before. so if you put the playhead a little behind (or before - as it's circular it depends on your view) you get a simple delay. as the trigger to start recording with tabwrite~ is not sample accurate, i can't get a constant recording without clicks at the trigger points - at least not with my limited understanding of pd.
This may seem a trivial, but you should consider that regardless accuracy if there is a noticeable 'jump' from the last sample in the array and the first (meaning in this case the sample in the loop and the beginning of the loop) you would be hearing a click even with the most perfect set-up and this is likely to happen if you are filling the array live.
Regards, Lorenzo
Hallo, Mike Moser-Booth hat gesagt: // Mike Moser-Booth wrote:
If I'm not mistaken, I believe the trick to getting this to work is to
make sure the array size is a multiple of the block size. [tabwrite~]
conforms to block boundaries, to if you bang it in the middle of a
block, it won't begin writing until the end of the block. That's
probably where the clicks are coming from.
The actual size of the array doesn't matter: If you have for example an array of size 300, you could record and playback only the first 256 samples (4*64) with block-quantized objects. Just ignore the last 44 samples.
Ciao
Frank
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Mike Moser-Booth hat gesagt: // Mike Moser-Booth wrote:
If I'm not mistaken, I believe the trick to getting this to work is to
make sure the array size is a multiple of the block size. [tabwrite~]
conforms to block boundaries, to if you bang it in the middle of a
block, it won't begin writing until the end of the block. That's
probably where the clicks are coming from.The actual size of the array doesn't matter: If you have for example an array of size 300, you could record and playback only the first 256 samples (4*64) with block-quantized objects. Just ignore the last 44 samples.
Anyway, attached is a tabwrite~-based looping recorder. I use a [bang~] based metro to start recording there, and some DSP order forcing to make sure, the table is written before it is read to be able to get a delay time of zero as well.
Ciao
Frank
thanks for all the replies.
and yes, something similar you posted, frank, is what i had in mind. i couldn't remember the block-quantisation, but it makes sense now.
in G05.execution.order it says: "DSP sorting in Pd follows the
hierarchy of subpatches"
hierarchy of subpatches means top to bottom or simply outlet to inlet?
thanks, volker.
On 19.01.2010, at 13:05, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Mike Moser-Booth hat gesagt: // Mike Moser-Booth wrote:
If I'm not mistaken, I believe the trick to getting this to work
is to make sure the array size is a multiple of the block size.
[tabwrite~] conforms to block boundaries, to if you bang it in the middle of a block, it won't begin writing until the end of the block. That's probably where the clicks are coming from.The actual size of the array doesn't matter: If you have for
example an array of size 300, you could record and playback only the first 256
samples (4*64) with block-quantized objects. Just ignore the last 44 samples.Anyway, attached is a tabwrite~-based looping recorder. I use a
[bang~] based metro to start recording there, and some DSP order forcing to make
sure, the table is written before it is read to be able to get a delay time of zero
as well.Ciao
Frank <table-looper.pd>_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, volker böhm hat gesagt: // volker böhm wrote:
thanks for all the replies.
and yes, something similar you posted, frank, is what i had in mind. i couldn't remember the block-quantisation, but it makes sense now.
in G05.execution.order it says: "DSP sorting in Pd follows the hierarchy of subpatches" hierarchy of subpatches means top to bottom or simply outlet to inlet?
It's outlet to inlet following the connections. Pd generally ignores the position of objects in a patch (except for xlets).
Just put stuff you want to happen in some order into subpatches and connect these with dsp cords. The dsp cords don't need to carry actually data, dummies are fine.
Ciao
Frank
On 20.01.2010, at 10:28, Frank Barknecht wrote:
Hallo, volker böhm hat gesagt: // volker böhm wrote:
thanks for all the replies.
and yes, something similar you posted, frank, is what i had in mind. i couldn't remember the block-quantisation, but it makes sense now.
in G05.execution.order it says: "DSP sorting in Pd follows the
hierarchy of subpatches" hierarchy of subpatches means top to bottom or simply outlet to
inlet?It's outlet to inlet following the connections. Pd generally ignores
the position of objects in a patch (except for xlets).Just put stuff you want to happen in some order into subpatches and
connect these with dsp cords. The dsp cords don't need to carry actually
data, dummies are fine.
thanks! v
-
Frank Barknecht -
João Pais -
Kyle Klipowicz -
Lorenzo -
Mike Moser-Booth -
volker böhm -
ypatios