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 ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\