Composers Desktop Project Forum

Yes, the .ana extension is required; CDP uses a fixed set of custom file formats for all its frequency domain data, each identified by its extension, e.g. .ana, .env, .pch etc. Internally they are all WAVE format files.

The reported error suggests that this is an earlier version of the program which requires the environment variable CDP_SOUND_EXT to be set (to wav). The recently updated v7.1 sources on Github have removed this requirement. You can test this by setting the environment variable directly at the console ("export CDP_SOUND_EXT=wav") and then running pvoc. If the progam then runs, you know that it is an older version. The variable is effectively obsolete these days now that all Apple machines are Intel-based.

Get it in the usual way by cloning a new repository

https://github.com/ComposersDesktop/CDP7

With thanks to John ffitch for getting it all set up.

The recommended build system uses CMake, which will need to be installed separately if not already available.

Building for Windows requires the Mingw command line environment with gcc etc.

24bit operation is definitely supposed to happen. A bug somehow got into the sound filing system routines some while ago (probably because of general code updates getting crossed in the post), which made all output revert to 16 bit as reported. I have completed a full rebuild of all programs which resolves this, restoring the intended behaviour, and I hope to have these available within the next couple of weeks (I am about to be away for a week) on the CDP website, with revised sources in due course on github.

The intended behaviour is for the output file to match the format of the input file, so that e.g. 24bit input gives 24bit output; with the option to force the output to floats using the -f prefix.

Ah indeed; I will need to check the version, as it is ~supposed~ to write a float file! It was a facility incorporated many years ago; unfortunately a collision of sources at one point resulted in a regression defaulting to 16bit, and it had to be un-regressed, which was done about a year ago (it is a generic facility for all applicable output files). Somehow you have one of the older versions. It is too late to look at that tonight, but I will investigate further tomorrow.

Unfortunately it is not really possible to find the true net amplitude of an analysis frame other than by resynthesising it. Bins are not truly independent (may reinforce/cancel mutually), and in principle the contribution of the analysis and resynthesis windows should also be taken into account. Any computation to find the level would probably take longer than the already efficient resynthesis.

One solution is indeed to pre-normalise the input, best to a level below digital peak, e.g. -3dB or -6dB, process, and hope. The alternative is to resynthesise to a floating point sound file (on the command line, prepend -f to the outfile name), which will preserve over-range samples without clipping, and then rescale as required.

The .cdp files are plain text files (mostly very small) used behind the scenes by Soundloom. There is no need in the normal run of things to open and read them directly. Have you also installed the CDP programs? Soundloom is a "front end" GUI for them, and has no functionality without them - it may appear to fail "silently".

If you used the program "Unarchiver" to unpack things, it is probable that file permissions have got messed up; the standard native Mac tools should be used.

I am pretty sure the answer is No, but I have passed this on to Trevor Wishart, in case he has anything further or different to say. He may be busy and/or away, so a quick reply may not be possible.

Breakpoint files do not have a single format, and are strictly speaking not self-describing - each program determines what they should contain. thus while some programs expect frequencies, or raw amplitudes, others may expect MIDI numbers or dB; a few (e.g. mixfiles for "submix" etc) allow you to use either amplitude or dB. Many years ago Martin Atkins developed an 'extended" breakpoint file format when creating the Windows GUI program "BrkEdit" (which as I recall runs very nicely under Wine on Linux); this includes the ability to specify logarithmic or exponential spans between points, with a parameter for slope. In the event it has not gained wider currency – Soundloom for example does not use it. Soundloom uses a very complex program "cdparse" behind the scenes to scan any breakpoint file and try to work out which programs would use it, so that they can be enabled in the Process panel.

For modifying breakpoint files (which are mostly space-separated columns of numbers; a few require some text as well) the workhorse program is "columns". Again this it not designed to convert a single value and return the result to stdout unix-style, but to take a breakpoint file as input, split it into single column files if necessary, and generate a new file as necessary. It was also designed (as I note elsewhere) very much for SoundLoom, and may need scripts to be written to drive it comfortably from the command line.