Hello, I am a pd newbie. I just read the manual with great interest. I worked much with reaktor so I am very interested in the differences between pd and reaktor. One difference is the time accuracy of the message processing. In reaktor messages (called events) have a time resolution of one sample instead of 64 in pd.
I read in the manual under 2.4.4: "You may wish to use block sizes smaller than 64 to gain finer resolutions of message/audio interaction, .. "
I tried that without success. I started from the the following audio example: "73.control.blocksize.pd". I added a metro object in the subpatch where the blocksize is reduced to one sample (block~ 1). The output of the metro is triggering an envelope with a short spike. Unlike the delaytime of the feedback delay in the example patch the time gap between two spikes cannot be set below 64 samples. I attached the file. I am using pd 0.36-0 under winxp. Maybe I am doing something wrong? Maybe there is an other solution to that.
thank you and regards,
erik
you can also get sample-accurate triggering with the objects in the t3 library which is part of iemlib (the part that didn't get rolled into pd). this is preferably to changing the block size which will make pd very inefficient.
pix.
On Sun, 10 Aug 2003 19:41:11 +0200 "errorsmith" me@errorsmith.de wrote:
Hello, I am a pd newbie. I just read the manual with great interest. I worked much with reaktor so I am very interested in the differences between pd and reaktor. One difference is the time accuracy of the message processing. In reaktor messages (called events) have a time resolution of one sample instead of 64 in pd.
I read in the manual under 2.4.4: "You may wish to use block sizes smaller than 64 to gain finer resolutions of message/audio interaction, .. "
I tried that without success. I started from the the following audio example: "73.control.blocksize.pd". I added a metro object in the subpatch where the blocksize is reduced to one sample (block~ 1). The output of the metro is triggering an envelope with a short spike. Unlike the delaytime of the feedback delay in the example patch the time gap between two spikes cannot be set below 64 samples. I attached the file. I am using pd 0.36-0 under winxp. Maybe I am doing something wrong? Maybe there is an other solution to that.
thank you and regards,
erik
Hallo, errorsmith hat gesagt: // errorsmith wrote:
I read in the manual under 2.4.4: "You may wish to use block sizes smaller than 64 to gain finer resolutions of message/audio interaction, .. "
I tried that without success. I started from the the following audio example: "73.control.blocksize.pd". I added a metro object in the subpatch where the blocksize is reduced to one sample (block~ 1). The output of the metro is triggering an envelope with a short spike. Unlike the delaytime of the feedback delay in the example patch the time gap between two spikes cannot be set below 64 samples. I attached the file. I am using pd 0.36-0 under winxp. Maybe I am doing something wrong? Maybe there is an other solution to that.
I didn't look to closely into your patch, but I saw that you use the adsr abstraction in it which in turn uses the [del] objects. Those del objects never delay below 64 samples (and thus are acutally a "pain in derriere" for fast, perkussive envelopes)
You might want to try your test patch with a phasor~ instead, whose phase is reset evertime the metro is on.
ciao
Frank Barknecht _ ______footils.org__
See also the "vline~" object (starting in Pd 0.37) shown in doc/3.audio/examples/C04.control.to.signal.pd ... this can give either sample or linearly-interpolated sub-sample accuracy. A description is in chapter 3 of my "book": http://www.crca.ucsd.edu/~msp/techniques.htm
cheers Miller
On Sun, Aug 10, 2003 at 07:41:11PM +0200, errorsmith wrote:
Hello, I am a pd newbie. I just read the manual with great interest. I worked much with reaktor so I am very interested in the differences between pd and reaktor. One difference is the time accuracy of the message processing. In reaktor messages (called events) have a time resolution of one sample instead of 64 in pd.
I read in the manual under 2.4.4: "You may wish to use block sizes smaller than 64 to gain finer resolutions of message/audio interaction, .. "
I tried that without success. I started from the the following audio example: "73.control.blocksize.pd". I added a metro object in the subpatch where the blocksize is reduced to one sample (block~ 1). The output of the metro is triggering an envelope with a short spike. Unlike the delaytime of the feedback delay in the example patch the time gap between two spikes cannot be set below 64 samples. I attached the file. I am using pd 0.36-0 under winxp. Maybe I am doing something wrong? Maybe there is an other solution to that.
thank you and regards,
erik
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
See also the "vline~" object (starting in Pd 0.37) shown in doc/3.audio/examples/C04.control.to.signal.pd ... this can give either sample or linearly-interpolated sub-sample accuracy. A description is in chapter 3 of my "book": http://www.crca.ucsd.edu/~msp/techniques.htm
Ah, wonderful. This is a *really* useful new object. Although I can now restart my still unfinished drum tutorial [1] again... :(
1 http://footils.org/tut/pddrums/pddrums.html
ciao
Frank Barknecht _ ______footils.org__
Hello, thank you for the quick and helpful replies.
Maybe I am wrong but I think something is wrong with vline~. The triangle wave in C04.control.to.signal.pd sounds and looks corrupted. (see attached pd file).
But I think I get the idea of the time tagged messages.
Would vline~ also take more than 1 message per audio block? I mean would it be possible to generate an message stream with a periode smaller than 64 samples and vline~ generates ramps between them? I tried it and it seems only one message per block is taken, I guess the latest one, but maybe vline~ is buggy.
greetings,
erik
----- Original Message ----- From: "Miller Puckette" mpuckett@man104-1.ucsd.edu To: "errorsmith" me@errorsmith.de Cc: pd-list@iem.at Sent: Sunday, August 10, 2003 8:18 PM Subject: Re: [PD] howto gain finer resolutions of message/audio interaction?
See also the "vline~" object (starting in Pd 0.37) shown in doc/3.audio/examples/C04.control.to.signal.pd ... this can give either sample or linearly-interpolated sub-sample
accuracy.
A description is in chapter 3 of my "book": http://www.crca.ucsd.edu/~msp/techniques.htm
cheers Miller
On Sun, Aug 10, 2003 at 07:41:11PM +0200, errorsmith wrote:
Hello, I am a pd newbie. I just read the manual with great interest. I worked
much
with reaktor so I am very interested in the differences between pd and reaktor. One difference is the time accuracy of the message processing. In
reaktor
messages (called events) have a time resolution of one sample instead of
64
in pd.
I read in the manual under 2.4.4: "You may wish to use block sizes
smaller
than 64 to gain finer resolutions of message/audio interaction, .. "
I tried that without success. I started from the the following audio example: "73.control.blocksize.pd". I added a metro object in the
subpatch
where the blocksize is reduced to one sample (block~ 1). The output of
the
metro is triggering an envelope with a short spike. Unlike the delaytime
of
the feedback delay in the example patch the time gap between two spikes cannot be set below 64 samples. I attached the file. I am using pd
0.36-0
under winxp. Maybe I am doing something wrong? Maybe there is an other solution to
that.
thank you and regards,
erik
On Sat, Aug 16, 2003 at 10:55:50PM +0200, errorsmith wrote:
Hello, thank you for the quick and helpful replies.
Maybe I am wrong but I think something is wrong with vline~. The triangle wave in C04.control.to.signal.pd sounds and looks corrupted. (see attached pd file).
Wow, you're right, except that the bug turned out to be in the Pd scheduler!
Thanks for flagging this; it was subtle and potentially ugly.
To fix, m_sched.c, lines 358-359 should read:
sys_time = next_sys_time;
dsp_tick();
(i.e., reverse the order of the two lines). Then just ./configure and make and vline~ should be as good as new... or just wait till Monday when I can get the compiled Mac version out. I'll probably try to get in one more "improvement" too, to reduce audio latency a bit further.
But I think I get the idea of the time tagged messages.
Would vline~ also take more than 1 message per audio block? I mean would it be possible to generate an message stream with a periode smaller than 64 samples and vline~ generates ramps between them? I tried it and it seems only one message per block is taken, I guess the latest one, but maybe vline~ is buggy.
You can update at periods less than a single sample, if you really want to... the thing will (OK, _should_) be able to queue any number of updates you request.
cheers Miller
Hello,
(i.e., reverse the order of the two lines). Then just ./configure and
make
and vline~ should be as good as new... or just wait till Monday when I can get the compiled Mac version out.
It seems not to be only a bug in the Mac version. I found it in the windows version.
I still find it very hard to understand how messages are coverted into audio and the opposite. As I said I am a pd newbie, so maybe I overlooked something. It would be very helpful to understand how the messages are scheduled and in which cases the timetags are interpreted. If all messages in pd are timestamped and more than one message per audioblock are scheduled for a message to audio conversion, it would make sense to use these tags whenever possible. For instance sig~ can allign the messages within an audioblock in dependence of the time tags. I see no reason that it shouldn't do that. Also for the other way round: the snapshot~ object can take all scheduled bangs at its input and sample the audio signal at the times defined by the timetags of the bangs. Generate a number for each bang, while the number messages have the same time tags as the corresponding bangs.
But even if all conversions are using the time tags there is still a problem with messages generated with threshold~. Say you want to generate a random number on each zerocrossing of an audio signal with a treshold~ object and you multiply the random number with the audio signal so that its amplitude is changed with each zerocrossing. The problem is that even with timetags the random number will have a delay of one audiobuffer since they will be used in the next audiobuffer instead in the one where they were generated. A workaround would be to delay the audio signal before it gets multiplied for one audiobuffer. I think this workaround is quite uncomfortable since you maybe need to delay other signals which are in sync to the mentioned signal. Also the latency in live performances will be increased.
It would be nice to be able to set the "update rate" of the message processing. It would make sense to set the wait period with block~. So if you set block~ 1 then you would get sample accurate message processing if you need it. This would be nice since block~ can be different for each subpatch. So If you really need the sample accuracy then you put the corresponding structure in a subpatch while the parent structure still have a cpu friendly update period of one audio buffer.
I hope not to take too much of your time.
thanks and regards,
erik
Yes, it's the same bug on all platforms; I just was imagining you were on a Mac for some reason. On MSW the same fix works, but compiling stuff is more dodgy there so I don't go around suggesting people try to recompile on their Windows systems.
cheers Miller
On Sun, Aug 17, 2003 at 10:41:58PM +0200, errorsmith wrote:
Hello,
(i.e., reverse the order of the two lines). Then just ./configure and
make
and vline~ should be as good as new... or just wait till Monday when I can get the compiled Mac version out.
It seems not to be only a bug in the Mac version. I found it in the windows version.
I still find it very hard to understand how messages are coverted into audio and the opposite. As I said I am a pd newbie, so maybe I overlooked something. It would be very helpful to understand how the messages are scheduled and in which cases the timetags are interpreted. If all messages in pd are timestamped and more than one message per audioblock are scheduled for a message to audio conversion, it would make sense to use these tags whenever possible. For instance sig~ can allign the messages within an audioblock in dependence of the time tags. I see no reason that it shouldn't do that. Also for the other way round: the snapshot~ object can take all scheduled bangs at its input and sample the audio signal at the times defined by the timetags of the bangs. Generate a number for each bang, while the number messages have the same time tags as the corresponding bangs.
But even if all conversions are using the time tags there is still a problem with messages generated with threshold~. Say you want to generate a random number on each zerocrossing of an audio signal with a treshold~ object and you multiply the random number with the audio signal so that its amplitude is changed with each zerocrossing. The problem is that even with timetags the random number will have a delay of one audiobuffer since they will be used in the next audiobuffer instead in the one where they were generated. A workaround would be to delay the audio signal before it gets multiplied for one audiobuffer. I think this workaround is quite uncomfortable since you maybe need to delay other signals which are in sync to the mentioned signal. Also the latency in live performances will be increased.
It would be nice to be able to set the "update rate" of the message processing. It would make sense to set the wait period with block~. So if you set block~ 1 then you would get sample accurate message processing if you need it. This would be nice since block~ can be different for each subpatch. So If you really need the sample accuracy then you put the corresponding structure in a subpatch while the parent structure still have a cpu friendly update period of one audio buffer.
I hope not to take too much of your time.
thanks and regards,
erik
-
errorsmith -
Frank Barknecht -
Miller Puckette -
pix