Composers Desktop Project Forum

Thanks you for reporting this. The fix, it has transpired, is small and simple, and will certainly be included in the next update to the app. I hope to complete the colour-coding of the instrument tree for the Mac as part of that. It has also been added to the source release on Github.

I found that the bug appears only to affect the GUI; all the required myriad text files are written, behind the scenes, such that if you simply Close the session and relaunch Soundloom, the new instrument duly appears as expected.  This is for the normal action of using "conclude". I have yet to test "Abort" separately (I always tend to regard that as a last resort), but since that throws the same error message, I would expect that to be covered by the same fix.

I can't be certain this would fix that unusual problem (which is new to me), but we updated several CDP programs towards the end of last year, including a new build of Soundllom using the much newer 8.6.1 version of tcltk, which plays much better graphically with the newer versions of OS X. All these updates are included in the full R8 downloads, but I have also provided simple zips of the updated files in Github, here:

https://github.com/ComposersDesktop/CDP8/tree/main/BinUpdates/Jan2026/osx-x86
(select the zip, then click on the "Download Raw" icon.)

One of Soundloom's weirder quirks is that sometimes GUI window popups do not appear as they should; they are in effect "hidden" behind the main WorkSpace screen, despite being the 'active' window for mouse actions etc. If in effect the Workspace window become unresponsive, it may be that just moving the window around a bit will reveal the secret window which would need a mouse action to dismiss.

Hello, there is a bit to unpick here. First, since you downloaded the full CDP Release we have made a small number of updates; many are bug fixes, but also including some functionality enhancements requested by the developer of Sound Thread, and, more immediately relevant, an updated build of SoundloomE using the newer 8.6.1 version of tcltk. All these are now in the updated full Download, but to to avaoid such a large download I have, possibly temporarily, also put zips of these updates on GitHub here:

https://github.com/ComposersDesktop/CDP8/tree/main/BinUpdates/Jan2026/osx-x86

(select the zip, and then click on the "Download Raw" button.)

There is no installation procedure for this other than just replacing the older files with the new ones -  in _cdp/_cdprogs for the programs, and /Applications or wherever for SoundloomE.

I see that OSX "Tahoe" (to which I have yet to update) has introduced yet another GUI redesign; it may be that this is the cause of the strange GUI appearance you describe. I hope that the updated build of Soundloom will mitigate the changes. It is set up to launch initally in "Small Screen" mode, intended to ensure everything in the larger windows is visible (with a litle scrolling), and therefore to be viable on 13" laptops. It is nevertheless tight on that size of screen.

The two error messages you see on launch are really just information messages, to the effect that without any MIDI input devices a few MIDI-dependent facilites in Soundloom are not available. the first is similarly an over-eager information message about one of the private config files in Soundlloom - one of Soundloom's many quirks!

I can't immediately resolve the final error, which does appear to arise in looking for a sound file. Is it possible that a file was deleted or moved external to a Soundloom session? I see that the problematic file was expected to be in your 'Downloads' folder. This is not really a folder for active user work. Soundloom offers the option either to copy ("Grab") a selected file to the "Workspace" (which is in fact the top-level _cdp folder), or merely to "use" the file without making a copy. That _cdp folder is of course visible to the user via the Finder, but Soundloom's internal book-keeping is compromised if any external changes are made.

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