Composers Desktop Project Forum

Re 16/32 bit file outputs:  as it happens, none of the main CDP programs supports command flags to nominate an output format. This is mostly for historical reasons: the CDP system was conceived first for the Atari ST with a custom filing system "(sfsys") with explicit options to read/write either 16bit int samples or 32bit floats. At that time the very concept of a 24bit file barely existed.

Fast forward to Windows media formats, and to begin with, again, only 16bit audio was supported by the API (plus legacy 8-bit formats). In a short while, Microsoft added a new format flag option in the header to define 32bit floats (so-called "type-3" file). CDP always had basic tools to convert between 16/32 bit files. More recently, to give access by users to high-resolution formats, we added the possibility to request a floats output by prefixing the output sound file name with "-f". This is supported in Soundloom, and, I assume, Soundshaper.

As Robert indicated, CDP programs read the input file format (e.g. 24bits, but there are others) and use that to set the output format; thus you can give a 24bit file to a program and it will output in the same format. To create such an input file (from 16bit/floats etc), you will need to use what is now the "workhorse" CDP tool "copysfx" to  generate whichever sample and channel format you want from quite a long list.

It is certainly a reasonable idea these days, with GB of disk space to play with, to work entirely with 32bit floats sound files (CDP programs themselves always use floats for internal processing). So long as the file is in the strictly correct "WAVEFORMATEXTENSIBLE" file format (which CDP programs ensure), native Windows media players (relying on the Windows Media API) will play it on whatever hardware is available, making sample conversions if necessary. Third-party apps are typically more forgiving.  You would then only convert your final master output file to, say, 24bits, for distribution.

So the modern choice is between working with 24bit or 32bit files. In most cases there will be no audible difference, and of course 24bit files will be that much shorter than 32bit files. There is however one rather cool aspect of the 32bit floats file format (as defined by Microsoft), which is supported by CDP programs. Being a floating-point format, the nominal sample range is +- 1.0 (in audio terms, 0dBFS). But there is a lot of headroom available, which matters most with filtering and some mixing operations where that limit can easily be exceeded. With the integer formats the inevitable result is clipping. However with 32bit floats there is no need for that clipping, and the PEAK sample value is also recorded in the file header (these days using a so-called "PEAK Chunk" added to the header, though CDP has always had its own non-portable ways of doing this).

The upshot of all that is that, for example, you can generate a floats output with over-range samples, and the CDP play program "paplay" (I must declare an interest: I wrote it) will automatically apply a scale factor to play the file without clipping.

OK, as you were; the two lines in filters0.c (ca Line 241) needed to be moved up to the end of the previous if block (after the for loop). they are needed for the variable filter banks, but not the fixed options. I have updated git with this change. Trevor is "out of the office" for a week, so any revisions to this solution may be a while.
.

Thanks; but NB only partly. The proper solution will very probably be inside the code for filter itself, rather than in the library (in principle, any change there, even if ostensibly benign, would demand a full recompilation; and the hack I have suggested will also have the possible consequence of hiding other bugs that may be out there). For example, I am now wondering if the offending assignment in filters0.c is in fact spurious and can be deleted, as the index name used is cited in the relevant header file as specifically for time-varying filters, which does not apply here.

Hello,

there is indeed a bug here, a memory error unsurprisingly. The array allocated for internal parameters ("param") is too small, currently 18, needs to be at least 21. When that location is written to, it happens, on this Mac, to corrupt the internal sfsys file ID for the infile, so that calls to write data fail, in this case causing an endless loop.

The short-term fix to make is in the library file tklib3.c (folder "cdp2k"), at and after line 175. Before the malloc call, the value of "storage_cnt" needs to be increased, e.g. "storage_cnt += 8".

Then recompile the library, and relink "filter".

This is a bug that I need to report directly to Trevor Wishart, who can provide the necessary changes to the parameter count. I will only update sources on GitHub once I have that from him.

Well done to all for diving into the code - not as you see, for the faint-hearted. Any time a program fails "sometimes", or not at all in some cases, the culprit is very likely to be a memory error of this kind. Easier to describe than find...

Sorry, that is a common shorthand way of representing a not necessarily fixed path. It was not meant to be entered literally. If Soundloom has been copied to the main Applications folder, the path would be simply:

xattr -rc /Applications/soundloomE.app

or if it has been copied to the main cdpr8/_cdp folder in your home directory:

xattr -rc ~/cdpr8/_cdp/soundloomE.app

(the tilde character ~ is a standard shell shorthand for your home directory. It is very useful in this sort of situation so that we don't have to guess what your account name might be, and add to the general confusion. But to complete the picture by typing the path in full, lets say my account name is Carnamagos:

xattr -rc /Users/Carnamagos/cdpr8/_cdp/soundloomE.app

the other way to complete such a command, especially if the target app is several levels down, is to type the command (plus the space):

xattr -rc

and drag the icon of the app to the open Terminal window: the Mac will then add the full path to the command line. This works for any file or folder. Windows does much the same on a PC.

The challenge in doing such a thing lies in the requirement to "Teach it CDP". LLMs are trained over literally billions of image and text examples trawled from the internet. I doubt if there is anything like enough examples of a working CDP command line on the net to do the job. It could be something a Computer Science department at a university might fancy as a research project. Part of the problem lies in the critical evaluation stage. Given a "correct" command line, one person listens to the output and says "that's it", while another might say "no that's not it at all".

As a side example of the challenge: I am a flute player, and I see from time to time examples of AI-generated images showing a person playing a flute. It is all in photo-realistic full-colour 3D. But in literally all the cases I have seen, none of the flutes matches what a flute actually looks like, and could not possibly work. Some don't even have a mouthpiece. Others assume the player has 20 fingers. But they look, well, plausible as images. Training an AI to "do CDP" may be an even harder task, and generating a sufficient data set for it could, alone, takes thousands or even milions of person-hours.

That said, a few people well versed in Csound have got ChatGPT to generate correct working Csound instruments (albeit simple ones) -  because there is a lot of Csound text available online for ChatGPT to work with, not least in large textbooks such as "The Csound Book". I would say that across the whole extent of the CDP online documentation and tutorials, there is probably less than 0.0001% of the examples an AI would need!

The approach I would suggest might be the most likely to succeed would be to create a script for a single CDP process, that can algorithmically generate variations on a working command line (start simply - no external breakpoint files!). Unix shell scripts have all the language elements one would need for this. Run each one, and score them based on a chosen evaluation criterion (or multiple criteria?). Perhaps if this data set is passed to an AI, it can generate new good command lines for that process based on input criteria. Sounds like an idea for a PhD to me!

That is a very good question! The simplest and quickest solution is to copy all the old preset and other files from your PC setup to the mac. This is the directories _cdpatch and _cdpins. The problem then is that the patch files appear to have hard Windows paths such as "C:\txws", for files that are clearly part of Archer Endrich's "Texture Workshop", which is still part of the full CDP documentation. A further snag is that (from memory just now) "texture" underwent a few changes for Release 8 (not least for multichannel processes), which may possibly make old patches fail to load.

That documentation (look for "htmltuts") is, I think, still the first place to go to for information and tutorials about Texture (etc).  As soon as I have more concrete information (and possibly provided a file to download) I will follow up here. RD.

Copysfx does not handle sample rate changes,just format changes. The main c/l program for that is "housekeep respec" mode 1.

To add a little more to this important investigation:

The reference to "PUA..." in the Sophos instance is explained by them here:

https://support.sophos.com/support/s/article/KBA-000004926?language=en_US

I find it interesting (not least as I used Sophos for all AV checking when I had a free account through Bath University; I now use McAfee) that they refer to their "Deep Learning" system. This is of course the modern AI approach, which is by its nature statistical, rather than the "conventional" AV paradigm of comparing against a database of known threats. On that page "PUA" means "Potentially Unwanted Application" (especially in the context of a "business netowrk") - which looks to me remarkably like the Gatekeeper system on the Mac for checking uncertificated downloads - and for which we document a standard workaround.

We are of course continuing to look at this, and will report here as and when.

Update: the offending line of code has been found. The most unfortunate news is that I can no longer build a new version of Soundloom.app as some of the tcl tools I use are 32bit binaries no longer supported on my machine (Monterey).

I noted there is  no workaround for this bug within Soundloom. However, it is possible to run "maxsamp2" from Terminal. The minimalist syntax is simple:

maxsamp2 cdptest0.wav 1

I am investigating this now - MaxSmp problem confirmed. But it all works as expected on the PC version, while there is no immediate obvious difference in the code (though the Mac did requires many changes to control widget gemetries and behaviour).

The message "KEEP:" is the first field in the text string output from "maxsamp2", followed by the amplitude values. It should be parsed and skipped past, but clearly is not on the Mac.

One of the disadvantages of a scripting language such as tcl is that code is never tested for correctness etc until it is used - unlike a stanbdard compiled language such as C, where most syntax or type errors are caught at compile time. Unfortunately, once Soundloom suffers a tcl error, it usually can't recover, there is no workaround, and it just has to be quit and restarted.

Ah, this is an example of one of the many hearts of the CDP system. In a GUI-based effect or instrument, this would involve controlling a rotary knob or a slider. Here in the command line we use a "breakpoint file". The simplest of these is by far the most common. It is a text file containing one or more lines, each with two numeric entries (separated by a space). The first is the time in seconds, and the second value is the required parameter value. The only rules are that (naturally) the first time value must be zero, and subsequent times must always increase. The file is then saved to a name of your choice. By CDP convention, the file extension is "brk", but "txt" is fine too. On the command line, where you would otherwise type an umber for a given parameter, you use the file name instead. The programs handle this internally, kn owing to lookm for either a single number or a file name.

So, a simple example might be:

0.0 1
0.5 2
2.3 4.5
2.4 3.9
3.0 1.1

From which you can gather that the programs will interpolate linearly from the stated values to generate all required intermediate values. Thus, if you just need a plain linear ramp 1->10 from start to end, for a 5-second sound, all you would need is:

0.0 1
5.0 10

Mode 2 means that the bash config file '.bash_profile' exists, but needs updating with the new PATH information. If this step fails, the usual reason is some problem with write permissions. This is a file that has to be in your home directory, the leading dot in the name makes it hidden (not displayed by the Finder). If - in your home directory - you type the directory listing command 'ls' with the flags '-la', so thus:

ls -la

It will included all the current hidden files and folder in the printed list. '.bash_profile' should be present. The -l flag makes all the current permissions printed along with each file name

You can then print the contents using the 'cat' command:

cat .bash_profile

It would typically show something like:

-rw-r--r--@  ....  .bash_profile

This show the file has write permission for the admin user, but is read-only for everyone else. If you are running as admin (as is the usual case for anyone running a personal machine), this would be fine. If not, the permissions would need to be set by someone with admin privileges.

I can't diagnose further without more information, e.g. the output from those suggested commands.

One final pont - if you are running any of the latest versions of MacOS, your default shell will be zsh, not bash. The install scripts also create an initial CDP config file for zsh, which should also appear in the directory listing (the title bar of the Terminal window will also indicate the zsh shell). I see no indication those file have failed to be created, so it may well be that in the z shell everything will in fact be up and running. Run any CDP program (such as 'dirsf') to verify one way or the other. Best to start a new Terminal session to be sure the new config information has been used.

Finally: I note you have run the xattr -rc command on Soundloom.app. This is fine as far as it goes, but my recommendation now (mentioned in the documentation) is to run it on the whole ~/cdpr8 directory (which will thus cover the app as supplied - the -r flag means 'recursive'), to ensure all the 140+ CDP programs are also covered. This will not in itself change any permissions though. R.

Caveat: sadly I am far from an expert on CMake. Yes, this is a strange problem. I have not been able to reproduce it here (Ubuntu, full portaudio install). I am assuming you are using the latest code set from github.

It does seem that CMake can get in a bit of a muddle, and the time-honoured solution has been to delete the whole CMakeFiles directory (in the 'paplay" directory inside the main 'build' directory set up before running Cmake for the first time). This will force CMake (when you  run 'make' in the build directory) to reconstruct all the internal config files, reading CMakeLists.txt to do so. You can inspect CMake's record of all target include files by checking the file CMakeFiles/paplay.dir/paplay.c.o.d. A quick way to reach this is using 'grep' recursively in, say, the paplay directory:

grep -R pa_ringbuffer .

Alternatively, run this from the build directory itself, which should find the instances for recsf, paplay, pvplay (four source files in all).

It is also useful to remember that you can run 'make' on a single target program to check it (e.g.: 'make paplay'), no need to run through the whole program set each time.

CDP has only a fixed standard or "default" installation, which is in the user's home directory (as provided by the command shell "zsh" each time the Terminal app is launched, or a new shell Window is opened). The all-important PATH configuration assumes this. In the Finder is is shown by the little house icon, with the name chosen when running the machine for the first time -  = your User Name. Putting the whole CDPr8 folder in /Documents means that the PATH for command line users is then wrong, likewise also the file which tells Soundloom where the software is - hence the error messages. This can be fixed by hand editing the required hidden text files (see the document "Manual Install" for details), but we would strongly recommend that for the usual case of a single user on a single machine the software is indeed installed as per the README file etc, in your home directory. Whatever the CDP system might be, it is not "a document", and therefore "Documents" is not an appropriate location for it all.