Composers Desktop Project Forum

For historical reasons (mainly birth on the Atari ST, then the move to Windows) we have not created unix-style programs that do this; rather they provide relatively verbose reports to the console. More recently, the programs are designed very much as tools driven by Soundloom (there is a whole secondary and undocumented command line system invented by Trevor Wishart and only used by Soundloom - the various console messages output by a program have a consistent format which Soundloom reads).

Also historically, we supplied (way back in the Atari days, and also for Windows users) the sfsys library and documentation so users could write (and contribute to the system) new utilities. With the move to open source, and to the creation of this forum, we very much hope this community programming activity can be so to speak rebooted. We still have, somewhere, an extensive document I wrote many years ago detailing the use of sfsys; I would have to check if it was still part of the main distribution.

We felt, indeed, that the usual behaviour of unix tools to report nothing to the console (as stdout was used for the primary output exactly for this type of piping approach) was too obscure for users who in most cases had never used a command line before. We would not want (or now be able to) change the existing programs to reflect this way of working, but certainly new unix-style utilities can be easily written by and for those who need them.

I don't use SuperCollider, but I assume it can shell out to a command line program, in which case the CDP programs can be pretty much used as is. But none of the programs themselves is real-time interactive; that would be a major project for someone to factor out the essential dsp code into a form that could be driven by a real-time engine. One of the many reasons for going to open-source is to encourage just that sort of enterprise.

All of the filter process can in principle run in real-time (always dependent on CPU power of course), and many of the spectral processes can too (as we showed commercially in "Spectral Transformer" for Cakewalk, and more recently in the streaming pvoc framework for Csound). Several of the distortion processes could in principle run in real time (possibly with some latency) where they do not either add or subtract wavecycles, but would need a lot of reengineering to handle wavecycle measurements, latency, and dynamic user interactions.

Many of the programs do multiple passes over either the input or the output., for such things as maximum amplitude computation and normalisation; these will convert either with great difficulty or not at all to a real-time streaming environment. This includes for example the granular synthesis/brassage programs.

The procedure previously documented for Mountain Lion etc has (again) been discarded by Apple for Yosemite. An immediate consequence of this is that pvoc anal and related programs creating frequency domain files will fail with an error message.

We are in the final stages of updating the whole CDP system to default CDP_SOUND_EXT to wav, but in the short term there is a new recommended procedure. Create a standard text file (e.g. using TextEdit.ap) called "environment.plist" with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>my.startup</string>
  <key>ProgramArguments</key>
  <array>
    <string>sh</string>
    <string>-c</string>
    <string>launchctl setenv CDP_SOUND_EXT wav</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>
Copy this file to your Library/LaunchAgents  folder and reboot.

There is every possibility that this will also work for Mountain Lion and Mavericks too, but I am no longer able to confirm that first hand.

Is this the  PC or the Mac version showing the slowdown? 

Yes, at present the environment variable CDP_SOUND_EXT does need to be set. This is documented for OS X and Windows, but I failed to write equivalent install documentation fort linux, partly as it was something of a tentative release anyway.

This is an inheritance dating way back to the first version of the CDP system on PC, where everything including all the frequency domain files was/is based on either WAVE or AIFF, with custom extra header chunks, depending on platform. With this variable set, the software knows which format in which to write pvoc and other frequency domain files (formant, transposition, etc) . With the steady attrition over the years of big-endian architectures (e.g. old Apple machines based on the PowerPC) the only reasonable format is now WAVE, and the next (imminent) release will define this internally by default, so that the variable will not need to be set by the user (but still can should they want to).

A new source release is under final testing, using CMake build files written by John Fitch. One we are confident that it all builds on all platforms, etc, we will indeed look at setting up a site on github. This will also make it easier to post updates and new programs etc; which are already starting to appear from the pen of Trevor Wishart!

But: I am gettting an error page saying "These files have been removed by the owner ". ??

It looks like an old bug has resurfaced - indeed pvoc should resynth to the original sample size/type.  I will make sure this is included in the next release.

Regarding the mono question - this is not so easy to change! For long historical reasons the current .ana file format is actually based on WAVE, and the channel field is currently used to indicate the size of the analysis frame (i.e. channels=  FFt bins), so there is no means of defining a stereo or N-channel analysis file.

My solution-in-progress has been to define a new PVOCEX analysis file format (extension .pvx), which supports N-channel data and is now the standard format in Csound. Integrating this into CDP is unfortunately a "non-trivial" task; not least as the question also arises in regard to all the other frequency domain CDP file types-  transposition, etc. Really. new file formats are needed for these too. And then the code for all the spectral processes would need to be updated (where appropriate) to handle multi-channel data. In the meantime, the current version of "pvplay" will play back a stereo .pvx file.

Current recommended practice (in some cases managed behind the scenes in e.g. SoundShaper) is to split multi-channel files into mono files (use channelx from the Toolkit or "housekeep chans"), process each using pvoc as desired, and then re-interleave the outputs using "submix interleave" or "interlx". The same applies to (for example) the distortion programs, as zero crossings are unlikely to coincide across  channels.

That said, multi-channel pvoc processing presents in any case certain technical problems in that as soon as any frequency transformations are applied (including pitch-=shift or time-scaling), the original stereo image is usually destroyed as the  subtle inter-channel phase relationships get knocked around.  Thus in the majority of cases, pvoc is idiomatically a "mono" sound-design process, with successful (or useable) multi-channel results very much dependent both on the nature of the input and on the trasnformation used.