Composers Desktop Project Forum

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.

It looks like the assumed procedure (by Trevor Wishart) is to obtain the pitch breakpoint file from the (or a) source soundfile, using "Repitch getpitch 2..." (or Repitch->extract etc in Soundloom). Perhaps editied or modified using any number of tools to process breakpoint files. It is a plain time/freq format file. Of course, "repitch" requires an analysis file, which will requires running pvoc on the source soundfile first. If you are on a PC, you always have the GUI option of using BrkEdit, but I think there is a basic GUI draw/edit facility in Soundloom as well. I think a core idea is to start with repitch getpitch, and then apply changes to the breakpoint data (e.g. data reduction, shifts etc) according to the compositional goal.

How practical it is to apply such changes manually of course depends on the length of the source and the density of pitch movements - the generated breakpoint file may easily contain 100s of points. There is however no serious technical reason not to use short hand-written data files - the spirit of the software is very much that of experiment, trial and error - but the duration of the breakpoint file (final data line) should normally match or exceed that of the source file.

The FOFS tool in Soundloom uses the commandline program "psow" behind the scenes, and it may be useful to run that directly to see the usage messages, in conjunction with the general CDP documentation.

In Soundloom, the somewhat convoluted process starts with running pvoc on a source soundfile, and then selecting the analysis file as the input for "Repitch" - save the text output to some name, to ensure it appears in the Workspace (may need to click "Refresh"). Select the original soundfile, to make FOFS available in the Process window, and in the relevant parameter page use "Get File" to select the required breakpoint file.

And so on.

This is the usual Gatekeeper response to a non-signed app downloaded from the bet. The solution is described in the README file: run the Terminal command:

xattr -rc /path/to/soundloomE.app

The best and recommended approach is to run xattr on the whole cdpr8 directory inside the Disk image. This will process everything, including soundloomE.app.
 

The messages here have all pointed to the correct place in the code, sffuncs.h. This issue in fact raises an interesting "strategic" question which I have been pondering: are big-endian platforms now effectively dead? if so, all that code can be eliminated (including a lot of dependent code in sfsys) and let it assume the host machine will always be little-endian. This would be an problem however if anyone hopes to build for a cherished PowerPC machine such as an old G5.

In the meantime, the solution needs to use a symbol that is also used in the relevant CMakeLists.txt file. On the Mac the simplest solution would be to add || defined(MAC) in the sffuncs.h line, as that is used in all the CMakeLists.txt files throughout CDP. If supporting big-endian platforms remains important, some new symbol can be defined such as __ARM64, to be used in both places.

Those building CDP8 from source from Github may like to consider posting questions such as this (which are not about "installation" issues as such) directly via the Github message system. I will receive these immediately through email, and can respond accordingly. This  doesn't require anyone to be "registered" as a developer. I have already answered quite a few queries this way.

We are proud to announce CDP's 8th software release, with over 80 new processes written by composer Trevor Wishart. 

Release 8 adds to the CDP's toolset especially in the manipulation of formants, wavecycle distortion, segmentation and repetition, plus new multichannel processes and synthesis functions.

The CDP system is a comprehensive sound design toolkit of over 450 processes. Developed over 35 years, it covers almost every aspect of sound transformation, including many that may be unfamiliar or are presented from an original or compositional viewpoint.

CDP is not a real-time system or a suite of plugins, but transforms sound-files (or their spectral equivalents) to create new sonic material.

CDP is released under a Creative Commons/LGPL licence as free software for MacOS, Windows and Linux, with sources available on GitHub.

Further details,downloads,workshops,tutorials and more can be found at the CDP website:

https://composersdesktop.com/

Richard Dobson