Composers Desktop Project Forum

It looks like the CDP code base does random number generation in some non-ideal ways :

1) It uses the standard C library rand() function, which has notoriously bad implementations in the wild. Solution : Use a higher quality random generator such as Mersenne Twister.
2) It uses the system time in seconds to seed that rand() generator. Solution : Get the random seed from a higher resolution clock or an actual entropy source on the system.

I am not sure how easy these are to fix in a C codebase, but I could look into what is available...

edit : I was able to pop in a Mersenne Twister generator that is seeded from a higher resolution clock. Of course this needs further testing etc...

edit2 : Here are the changed/added files (within the dev/sfsys directory) :

https://drive.google.com/file/d/0Bwi8r1Zqbjh_cmJ3QUd2OVFBZjg/view?usp=sharing

When opening this forum's URL, Google Chrome shows a red page claiming the forum contains malware with a hidden option to continue browsing into here. I don't know if it is a false alarm or something real, but perhaps the forum moderators could take a look at it.

I got quite frustrated with some aspects of the CDP frontend I have been working on, and decided to look at doing things from scratch. After a few days of work I've progressed quite nicely! I was able to come with a node graph based approach that allows quite cleanly to connect CDP programs together to form complex webs of processing. This will require a bit more work to become usable for the general public but perhaps a first test build might appear before too long. (Notably editing the CDP program parameters is currently very primitive, and no support for time varying parameters exists...)

Maybe someone will be interested in this :

http://xenakios.wordpress.com/2014/07/16/cdp-frontend-reaper-extension-plugin/

I now (re)discovered that prepending "-f" to the output file name of the (time domain(*)) programs, a 32 bit floating point file will be produced. However, it looks to me that the processing internally is not floating point or is handled incorrectly.

A simple test : use the modify loudness program to increase the volume of an already loud 16 bit file that has peaks at the maximum range, using the -f option. The expected result is that when the resulting file's volume is again reduced enough in some program known to do the floating point calculations as expected (such as Cockos's Reaper), there would be no distortion. The files obtained from the CDP modify loudness program however do not behave like that. They are permanently clipped to produce distortion. This leads to me to believe that either the internal processing does not happen as floating point or that the output is clipped into the -1.0...1.0 range, effectively making the floating point output file option nearly useless. The same behavior can be observed with the other CDP programs, but modify loudness is the clearest way to reproduce this behavior.

I don't bring this up due to "golden ears" concerns. The value of having a clean 32/64 bit floating point processing chain to me is almost entirely in the available volume headroom when the processing chain is working correctly. Ie, even if a DSP calculation ends up producing samples beyond the nominal -1.0...1.0 range, the signal can later be brought down in volume to not distort the monitoring output or to make it work better when mixing. If how this is supposed to work is not clear from the description, I can produce a demonstration as a video or a set of audio files.

(*) It seems that the spectral processings now always result in 16 bit PCM files, which seems like an obvious bug. (Unless the pvoc program and the CDP programs that transform the .ana files actually just are 16 bit only...?)

I find it a bit curious the forum can't be read without registering first. That makes this forum somewhat less useful as an information source.

If someone here works with the Cockos Reaper DAW, this might be of some interest :

http://xenakios.wordpress.com/2014/06/03/python-scripts-for-using-cdp-in-reaper/

Reaper's ReaScript scripting system only allows to do a very rudimentary dialog box GUI and I am not sure if anything more advanced could even be made. But at least ReaScript has the benefit it should in principle work on both Windows and OS-X.

Is it a known issue that pvoc.exe ends up producing 16 bit wav files from the resynthesis? This happens even if my initial wav file that is analyzed is for example 32 bit floating point.

Another thing that I am wondering about is that are the spectral processings really only mono? If it's mono-only, what has been the problem in making those work in stereo or more channels? This isn't really clear from the CDP user documentation for PVOC, the words "mono" or "stereo" don't appear on that documentation page at all...Yet the pvoc anal program only seems to work with mono files.

I've been trying to build pvoc.exe from source code to understand these issues better and to potentially fix them, but unfortunately in the end the pvoc.exe that I was able to build with Visual Studio 2013 doesn't run succesfully when done as a release build. (Debug build appears to run, but there certainly is something wrong since the release build crashes.) I would prefer to not use mingw to build, but I guess I will try that too at some point.