Composers Desktop Project Forum
General Category => General Board => Topic started by: sciss on March 11, 2017, 07:25:10 PM
-
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.
-
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")
-
I don't think that is going to work.
-
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.
-
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.