Hi David, David Sabine hat gesagt: // David Sabine wrote:
Follow the link below to find some new reference documents for PD.
I couldn't take a look at your work until now and I'm flattened: This is great stuff, you wrote there and even interesting if one thinks one already knows all about the objects from daily use: There's a lot of hidden stuff to explore in your patches.
I have now completed all the MATH objects. To date I have revised all the help documents (usually found in the pd/doc/5.reference/ folder) for the following objects:
TIME objects - [delay] [line] and [metro] etc. etc.
I would like to add an oddity with delay, that might cost someone a lot of time (at least it did cost me): delay always puts out the bang on the start of a signal block. Attached patch shows what I mean. Maybe you can add this info, because it explains, why fast envelopes with line~ and del sometimes produce no output. To my knowledge there's no trivial solution but the t3-objects in IEMLIB.
ciao,
Frank Barknecht _ ______footils.org__
On Mon, 22 Jul 2002, Frank Barknecht wrote:
I would like to add an oddity with delay, that might cost someone a lot of time (at least it did cost me): delay always puts out the bang on the start of a signal block. Attached patch shows what I mean.
Actually this is true not only for del but about message calculations in general. So it is more a "remember" issue than an oddity with delay. All clock times are rounded to a multiple of 64 samples.
Maybe you can add this info, because it explains, why fast envelopes with line~ and del sometimes produce no output. To my knowledge there's no trivial solution but the t3-objects in IEMLIB.
There might be a solution using arrays, ..
Guenter
Hi, günter geiger hat gesagt: // günter geiger wrote:
On Mon, 22 Jul 2002, Frank Barknecht wrote:
I would like to add an oddity with delay, that might cost someone a lot of time (at least it did cost me): delay always puts out the bang on the start of a signal block. Attached patch shows what I mean.
Actually this is true not only for del but about message calculations in general. So it is more a "remember" issue than an oddity with delay. All clock times are rounded to a multiple of 64 samples.
Yes, you're right, but with [del] as used in the ADSR example in the PD example patches this problem becomes significant.
Maybe you can add this info, because it explains, why fast envelopes with line~ and del sometimes produce no output. To my knowledge there's no trivial solution but the t3-objects in IEMLIB.
There might be a solution using arrays, ..
I did several experiments with textfile or qlist and they all fail because of the message speed. I'm working on a PD-tutorial explaining my angriff drummer at the moment, and here's the relevant part from this:
This problem isn't trivial at all and it appears everywhere, one wants to contol messages in PD quicker than the signal blocksize allows, for example in granular synthesis patches. A solution to this are "Time-Tagged Triggers" (T3) as proposed by Gerhard Eckel and Manuel Rocha Iturbide for Max/FTS. In PD T3-objects are made available as externals in IEMLIB. Time-Tagged Triggers are a replacement for the standard "bang" message that is normally used in PD or Max. Eckel writes: "In Max/FTS, a T3 is nothing else than a message containing one floating-point number which specifies the delay in ms after which, counting from the current tick, the trigger should go off." We will now use the T3 break point envelope generator [t3_bpe] to generate faster envelopes.
Now the attached example patch, a variation of the previously posted one with [del] is shown.
ciao,
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
g�nter geiger