Hi,
coming back to my lineseg~ patch from last week, I have found a small problem with very fast line~ segments. Say I want to make a lineseg~ that goes from 0 to 1 in less than 1.5 msec, this is not possible, because there seems to be a minimum ramp duration in line~ of about 1.4 msec, a limit found by computing "blocksize * 1/samplerate":
64 * 1/44100 = 0.0014512472
Now I tried to reduce the blocksize inside my lineseg~ patch with [block~ 1], but I still can't get ramp durations of less than 0.00145 seconds. I checked this with tabwrite~ing the output to an array and giving the lineseg these three value/ramp pairs
0 0, 1 1.4, 0.5 100
That should go from 0 to 1 to 0.5 but it goes from 0 to 0.5 omitting the 1 unless I cange the 1.4 to 1.5.
Is this expected, or how could I get faster ramps? Or are these unnecessary anyway?
kind regards,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
hi Frank,
I do not think changing middle time interval to more then a blocksize would make any difference at all. All three messages are processed at once, and middle one (or any number of them) is simply ignored -- all this is always equivalent to `0, 0.5 100'.
Btw, I may be mistaken, but, anyway: is there any other method to get subblocksize segment length, than to read values from an array?
Krzysztof
Frank Barknecht wrote: ...
0 0, 1 1.4, 0.5 100
That should go from 0 to 1 to 0.5 but it goes from 0 to 0.5 omitting the 1 unless I cange the 1.4 to 1.5.
Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
I do not think changing middle time interval to more then a blocksize would make any difference at all. All three messages are processed at once, and middle one (or any number of them) is simply ignored -- all this is always equivalent to `0, 0.5 100'.
to make this clearer: I'm sending the three (and more) messages one after another from a textfile object, that holds them. So it's not, that I have a message reading [0 0, 1 1.5, ...( and that gets send directly to a line~.
But I do have a [del x] object, that bangs the textfile to put out the next message.
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
hi again,
that seems to be the case, since [del] works by setting a clock, and clocks fire only at DACBLOCK (hardwired to 64) boundaries (whatever that means).
Krzysztof
sme wrote:
i think this is, because the delay-object cannot go below a vectorsize of 64. the block~ 1 does not seem to change this...
Frank Barknecht wrote: ...
But I do have a [del x] object, that bangs the textfile to put out
the next
message.
by the way, i remember there was an object "envelope" in an old iem-release (?), where you could make envelopes in a grafical window. i donŽt know if it still exists (i should have a copy somewhere) and if this could solve the problem. does anyone know what happened to it? marius.
----- Original Message ----- From: "Krzysztof Czaja" czaja@chopin.edu.pl To: "Frank Barknecht" barknech@ph-cip.uni-koeln.de Cc: "pd-list" pd-list@iem.kug.ac.at Sent: Saturday, March 09, 2002 3:47 PM Subject: Re: [PD] Fast line~s
hi again,
that seems to be the case, since [del] works by setting a clock, and clocks fire only at DACBLOCK (hardwired to 64) boundaries (whatever that means).
Krzysztof
sme wrote:
i think this is, because the delay-object cannot go below a vectorsize
of
- the block~ 1 does not seem to change this...
Frank Barknecht wrote: ...
But I do have a [del x] object, that bangs the textfile to put out
the next
message.
hi, i think this is, because the delay-object cannot go below a vectorsize of 64. the block~ 1 does not seem to change this... marius
----- Original Message ----- From: "Frank Barknecht" barknech@ph-cip.uni-koeln.de To: "pd-list" pd-list@iem.kug.ac.at Sent: Saturday, March 09, 2002 1:33 PM Subject: [PD] Fast line~s
Hi,
coming back to my lineseg~ patch from last week, I have found a small problem with very fast line~ segments. Say I want to make a lineseg~ that goes from 0 to 1 in less than 1.5 msec, this is not possible, because there seems to be a minimum ramp duration in line~ of about 1.4 msec, a limit found by computing "blocksize * 1/samplerate":
64 * 1/44100 = 0.0014512472
Now I tried to reduce the blocksize inside my lineseg~ patch with [block~ 1], but I still can't get ramp durations of less than 0.00145 seconds. I checked this with tabwrite~ing the output to an array and giving the lineseg these three value/ramp pairs
0 0, 1 1.4, 0.5 100
That should go from 0 to 1 to 0.5 but it goes from 0 to 0.5 omitting the 1 unless I cange the 1.4 to 1.5.
Is this expected, or how could I get faster ramps? Or are these
unnecessary
anyway?
kind regards,
__ __Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___
/ / / ____/ / / / // ____// /\ \ ___\____
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
sme hat gesagt: // sme wrote:
i think this is, because the delay-object cannot go below a vectorsize of 64. the block~ 1 does not seem to change this...
Yes, you're right. I tested this with attached patch. So I guess I'll have to find another approach for my lineseg~ patch...
[OTOH I think, ggee's envgen~ already works like lineseg~, I'd just rather like a pure abstraction solution.]
bye,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
sme hat gesagt: // sme wrote:
i think this is, because the delay-object cannot go below a vectorsize of 64. the block~ 1 does not seem to change this...
Yes, you're right. I tested this with attached patch. So I guess I'll have to find another approach for my lineseg~ patch...
[OTOH I think, ggee's envgen~ already works like lineseg~, I'd just rather like a pure abstraction solution.]
In my search for the perfect lineseg~ I found, that the 1-block message delay problem can not be solved without special externals. Fortunatley there are "fast line~" externals in IEMLIB, as I found out now. So the next lineseg~ uses the time tagged trigger objects from IEMLIB, that give better time resolution to messages. And with the t3 break point envelope, even the need for a textfile object is gone. I also implemented the promised "release on keyoff-sensor" on inlet value "0" and used iemlib's fade~ for more possible line characteristics.
In researching the t3-objects, I found Gerhard Eckel's description of the MAX granular synthesis toolkit GiST. Does anyone know, if these are available for PD, too? Or where could one find GiST, or the included fog~, to maybe port it to PD? Or are there "license issues"? Except the document "The development of GiST, a Granular Synthesis Toolkit Based on an Extension of the FOF Generator" I could not find anything valuable (esp. source code) about GiST.
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
-
Frank Barknecht -
Krzysztof Czaja -
sme