[ bang ( ------[ 0 0 0, 1 15 0 ( | | | [ vline~ ] | | ------------[ tabwrite~ t ]
I have this simple patch above with a [bang( which triggers a couple of messages describing a line segment ranging from 0 to 1 in 15 ms, and at the same time the writing of this segment into table t. Suppose a typical setting with sample rate=44100, table size=1024. If block size is small enough (~64 or less) the patch works ok. But with bigger block sizes the segment appears displaced to the right of the table left border as if its starting time was out of sync. Stranger yet, cause it starts in different positions of the table every time I press the [bang(. As I increment block size the average offset increases too. Is this a expected behaviour of [vline~]? Am I making some mistake? I understand that [vline] schedules its segments at "audio time", in other words that it has sample-precision instead of block-precision. Thank you in advance. Regards, Carlos
Selon Carlos Pita carlosjosepita@yahoo.com.ar:
[ bang ( ------[ 0 0 0, 1 15 0 ( | | | [ vline~ ] | | ------------[ tabwrite~ t ]
First thing, here, the order of the two actions (starting the line, starting to record) is important: if you start the recording after the signal starts, the beginning of the signal can't be recorded ... If you connect a bang to several objects, you can't really know in which order these objects will receive the bang (normally, first connected -> first sent, but it's not good to use this for programming)
the [trigger] object should help for example [t b b f] has 3 outlets and sends
1, 2 and 3 are done "at the same time" (I mean, you won't hear / see the delay), but in this specific order
for recording with tabread~, maybe you should start the recording first and then play the signal (vline) you want to record:
[bang(
|
[t b b]
| |
| ------------
| |
[0 0 0, 1 15 0( |
| |
[ vline~ ] |
| |
-----------------|
[tabwrite~ t]
what do you mean by block size ? the pd software block size (default 64, resized by block~ or switch~) or the sound card I/O buffer size ?
writing accurately _very_ short portions of signal is often quite difficult in pd; sometimes, using [tabreceive~]/[tabsend~]/[bang~] is good if your recordings have to be synchronized with the pd dsp scheduler;
don't know if it helps ... try the [t b b] thing first before
cheers, -j
I have this simple patch above with a [bang( which triggers a couple of messages describing a line segment ranging from 0 to 1 in 15 ms, and at the same time the writing of this segment into table t. Suppose a typical setting with sample rate=44100, table size=1024. If block size is small enough (~64 or less) the patch works ok. But with bigger block sizes the segment appears displaced to the right of the table left border as if its starting time was out of sync. Stranger yet, cause it starts in different positions of the table every time I press the [bang(. As I increment block size the average offset increases too. Is this a expected behaviour of [vline~]? Am I making some mistake? I understand that [vline] schedules its segments at "audio time", in other words that it has sample-precision instead of block-precision. Thank you in advance. Regards, Carlos
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[ bang ( ------[ 0 0 0, 1 15 0 ( | | | [ vline~ ] | | ------------[ tabwrite~ t ]
If you connect a bang to several objects, you can't really know in which order these objects will receive the bang
But note that the [vline~]=>[tabwrite~] connection is an audio one. First a control phase will take place which will send the [0,0,0( and [1 15 0( messages to vline~ and the [bang( message to [tabwrite~]. The order is irrelevant cause [tabwrite~] will start writing in the following audio phase "at the same time" that vline~ starts outputing the line segment. So there is no need to trigger the messages in a fixed order, it's enough that control happens before audio.
what do you mean by block size ? the pd software block size (default 64, resized by block~ or switch~) or the sound card I/O buffer size ?
Resized by [switch~].
writing accurately _very_ short portions of signal is often quite difficult in pd;
That's the point for using [vline~] instead of [line~], accurate sync.
After a more detailed testing it seems as if [vline~] only plays nice with the default block size of 64. Perhaps it should be listed among objects that have problems with reblocking.
Thx Regards, Carlos
Hallo, Carlos Pita hat gesagt: // Carlos Pita wrote:
After a more detailed testing it seems as if [vline~] only plays nice with the default block size of 64. Perhaps it should be listed among objects that have problems with reblocking.
Hhm, I think it would be preferable to have vline~ work correctly for all block sizes. ;)
Thank you for pointing at this misbehaviour, I never found out about it. As attached patch shows, vline~ with smaller block sizes can also lead to values going out of border in "y"-direction, that is, with a block size of, say, 16, the ramp to 1 will end at values bigger than 1, which can be very nasty.
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41