Am Donnerstag, den 03. Januar 2002 um 17:22:33 Uhr (+0100) schrieb Krzysztof Czaja:

...

Is it possible to run realtime synthesis with csound in pd? (like it is possible now with max)

Not yet (but soon...?)

For linux there exists a solution:

Over the holidays, I wrote an external for pd, which is similar to the print object, but enabling the output of arbitrary symbols or floats to a file rather than to the message window. Csound for linux has an option to take realtime scorefile input from a pipe. Thus you can create a pipe as pseudo file with the command "mkfifo <filename>", specify this filename as pipe input in csound (using the -L flag) and open this file for writing from within pd (using my fileprint external).

That way, any i-statements or f-statements are interpreted as if they were written in the scorefile. The only difference is that p2 is interpreted as time-offset from the time of arrival at the pipe (which actually is quite handy).

In order to control csound at k-time, there is an OSC port in the unofficial version of csound for linux.

The only problem which remains is to redirect the sound output of csound back to pd. (Since csound blocks the audio-ports, you can't do any signal processing in pd if you don't have multiple soundcards.) Maybe someone has an idea, how to get that done. But I guess this issue has to be attacked from within csound.

the pd object, I wrote, is very small (ca. 6 KB) and I could well imagine its functionality can somehow be obtained with standard pd-objects. But if anybody is interested in it, drop me a note.

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, but unfortunately, programming pd-externals is not very well documented and I remember back from the days when I wrote MAX externals that it is a little tricky. If anybody can help me with that it would be great since it doesn't make a lot of sense to send

"foo i1 0 0.3 72 60.3"

when all you want to get printed is

"i1 0 0.3 72 60.3".

Also, extensive error checking isn't implemented.

Yours Orm

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