Embedding CDP - possible to "pipe" input and output files?

[sciss]

Hi there,

I'm looking at ways of embedding the CDP programs in an existing system (FScape 2) where they would appear as sort of UGens.
I'm trying to figure out if there is a way to avoid having to write and read temporary audio files for I/O, for example by "piping" the audio input file into the process
and the audio output file from the process. This should work at least on Linux.

Something like this

./modify speed 2 special_in_pipe special_out_pipe 12

I'm pretty optimistic there is some way to get this working in Linux with the existing unmodified shell commands.

For example, I tried to use a named pipe (via mkfifo) as input and write to it from another process, but cdp terminates with

ERROR: INVALID DATA
ERROR: File /data/audio_work/my_pipe.aif either has unredable header, or is a textfile with a CDP reserved extension.

(I double checked that the contents written to the pipe is actually a valid AIFF file).

But then perhaps my idea can't work because certain process will need random access instead of serial stream?

Best, .h.h.

[sciss]

This is some first simple attempt (process with 1-in-1-out)

    val sr    = 44100.0
    val lenIn = sr * 10
    val ln    = Line(0, 1, length = lenIn)
    val freq  = ln.linexp(0, 1, 200, 4000)
    val sig   = SinOsc(freq/sr).take(lenIn) * 0.5
    val rvs   = cdp.Modify.Radical.Reverse(sig)   // inject CDP here
    val fOut  = file("/data") / "audio_work" / "reverse.aif"
    val aOut  = AudioFileOut(file = fOut, spec = AudioFileSpec(sampleRate = sr, numChannels = 1), in = rvs)
    aOut.last.poll(0, "frames-written")

[Xenakios]

I don't think that is going to work.

[sciss]

It's an interesting question that I have been asking myself while redesigning FScape. Eventually my conclusion was that one can distinguish types of processes

- those that require random access or repeated access to some input data
- those that can use a linear input stream but require stream information such as total input length
- those that can use a linear input stream blindly (typical of DSP processes that otherwise run in real-time)
- and the same for the output ports

So, yes, in the general case the assumption would have to be that input and output must be fully buffered. That's how I implemented the PoC right now.

[rwdobson]

This will not be possible sadly. Unix pipes work on "stdio streams", e.g. when a program outputs text to the console or receives text input from a keyboard. In those cases the running output of one program ("stdout") can be piped to the input ("stdin") of the second. CDP programs on the other had work strictly with soundfiles - nominally an "offline" musique-concrete approach. An output soundfile is not in any way a "temporary" file, it is just that, the output soundfile.

Thus any third-party program or application that spawns a CDP program must both provide all the required command line arguments and wait for and check for the program to finish, before making use of the output.