Hi Krzysztov (what a nice name!),
Am Samstag, den 05. Januar 2002 um 10:44:52 Uhr (+0100) schrieb Krzysztof Czaja:
it is a very nice idea. Based on the results you get while testing your external, could you somehow assess the jitter you get? Is timing much better than if you would have simply run
<pd-command> 2>&1 | awk '/csound/{print substr($0,9)}' | <csound-command>
and sent score line-events to [print csound] object?
I didn't try this yet, but I could imagine, piping the pd output to awk adds some unnecessary overhead (regexpr scanning etc.). No extensive testing was made with my object so far, but sending noteevents triggered by a metro object didn't create any noticeable jitter.
In general I think, redirection of the pd error stream is not the most elegant way to control csound as other systemrelated notifications and messages end up in awk's nirvana.
The object has one drawback, though: pd strips the first element in a list which is sent to the object, as I used class_addanything in the setup function of the object. There must be a way to get around that,
Is your implementation based on print class implementation (x_interface.c) and the family of post() routines (s_print.c)?
No. Thanks for the hint. I will look into that. I'm just delving into the whole issue of writing externals for pd and got some documentation (like Johannes Zmoelnigs text and Zicarellis text on MSP). The fileprint object actually was only a test as I'm actually planing to port my ancient code resource implementing realtime manageable markov chains in Max (from 1993) to pd and make it available to the public (is anybody interested?). Since this object contains some 4.500 lines I thought, I'd start small...
Yours, Orm