Cabbage Logo
Back to Cabbage Site

Linux build of Cabbage 2.0.02 and Projucer for Debian 9.x

Can anyone point me to specific steps for building Cabbage and so Projucer on Linux? I am using Debian. Below is my progress so far.

####Note 2018-05-13:
Message 20 below has complete instructions for how to install and set up Debian, compile Csound, Projucer and Cabbage. It also shows I access Cabbage on a remote (over the LAN) Linux machine, from a Windows machine via XDMCP remote desktop, without the problems I found due to Cabbage’s use of Juce causing several menu and other problems when accessed remotely by conventional SSH S forwarding. (Now, back to my first message.)

I was amazed to find that the easily installed Cabbage for Windows (with Csound) enabled real-time Csound files to be rendered on my 2 core (4 thead) 7 year old laptop with a cheap Behringer UCA222 USB 2+2 interface, doing such things as reverb with a total latency (measured with an oscilloscope) of 22ms. (This is with careful adjustment of the ASIO driver.) I am keen to get this, especially with Cabbage’s real-time GUI controls, on Debian - so I need to build Cabbage. I have not yet compiled the latest Csound. Perhaps the Cabbage build does this.

Building big programs like this is typically non-trivial, and Cabbage is no exception. Here is how I attempted to do it on Debian 9.x 64 bit.

The command “unzip” unzipped the archive.

Looking for README text files found readme.md. What’s “.md”?? stackoverflow /questions/5922882/what-file-uses-md-extension-and-how-should-i-edit-them I tried to find a Windows editor for markdown and installed for Haroopad. It is a PITA since its decoded text is not copyable to any text editor. So I tried (from this list slant.co topics/1852/~markdown-editors-for-windows) QOwnNotes. This was unable to open a .md file. After over an hour of futzing I gave up on the idea of viewing these files as they are intended to be seen, using a local non-browser-based program. README.txt files would have been so much easier.

So I searched for the github directory and read the .md files from there with my browser, such as: https://github.com/rorywalsh/cabbage/blob/master/readme.md

I became concerned that Linux was not a primary platform for Cabbage, since the beta versions are for OsX and Windows only.

The download page states: “For other flavours of Linux you will need to build Cabbage yourself.
There is a README outlining the necessary steps.” However, there is no single README file for this. I found: github rorywalsh/cabbage/blob/master/Builds/readme.md .


To build Cabbage on any platform, you must download the latest release branch of the JUCE framework. You will firstly need to build the Projucer project manager for JUCE. It’s contained in the JUCE/extras/Projucer folder and contains build projects for all major platforms and compilers. You will also need the VST SDK. The best place to put this is in a folder called SDK in your home directory, or C:\ on Windows.

For more details on building Cabbage see the various platform folders in this directory.


So I downloaded JUCE Personal from https://shop.juce.com/get-juce . For Linux this is JUCE and Projucer juce-5.3.1-linux.zip . I found a Makefile at JUCE/extras/Projucer/Builds/LinuxMakefile but no clues on how to build this particular thing. So I looked at: https://docs.juce.com/master/tutorial_new_projucer_project.html “Go into the JUCE folder you just installed. Launch the Projucer, which is located there.”. There is a
10MB executable JUCE/Projucer so I ran that as a mortal (non-root) user. However, this is evidently running the already compiled Projucer. The resulting window informed me that to use it under the GPL I would need to compile it from the source, after changing a flag, which I think is the 0 on line 35 of https://github.com/WeAreROLI/JUCE/blob/5.0.0/extras/Projucer/JuceLibraryCode/AppConfig.h . (It never ceases to frustrate me how a high proportion of steps in any IT project require further preliminary steps which are unforeseen diversions - and if the average of the number of steps per diversion, multiplied by the probability of a diversion occuring at each step exceeds 1.0, then the task could take a very long time indeed.)

Since the Cabbage instructions call for building Projucer, I decided that the above juce.com page was not relevent, so I didn’t explore getting a roli account or reading all its terms and conditions.

The question now is how to build Projucer. I altered the flag to 1, though there is a ReadMe.txt file in that directory there which cautions against changing any of these files. There are no-doubt dependencies for building Juce or Projucer. (I have only the vaguest idea what these things are - my only interest is compiling Cabbage.) Googling lead me to a set of dependencies: https://forum.juce.com/t/list-of-juce-dependencies-under-linux/15121 :

sudo apt-get install clang git ladspa-sdk freeglut3-dev g++ libasound2-dev libcurl4-openssl-dev libfreetype6-dev libjack-jackd2-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev libxrandr-dev mesa-common-dev webkit2gtk-4.0 juce-tools

I use GCC. Do I really need clang?

Just running “make” did not work.

I found guidance on building Projucer: https://forum.juce.com/t/huckleberry-not-compatible-with-modern-linux-platforms/22640

I copied the JUCE directory to my home directory and ran Fabian’s Jun 2017 apt-get command. This failed for two reasons. Firstly, I changed webkit2gtk-4.0 to webkit2gtk-4.0-37 after searching with Synaptic and finding that I already had this package installed, and that the original webkit2gtk-4.0 is not a complete package name. Secondly, I deleted the gtk±x11-3.0 package, since it does not exist. From https://forum.juce.com/t/linux-flags/21807/4 and https://forum.juce.com/t/projucer-requires-webkit2gtk-4-0-pc-on-linux/22436/7 I had already set JUCER_ENABLE_GPL_MODE=1 as noted previously. It was not clear how to make the other change “JUCE_WEB_BROWSER=0”. In JUCE/extras/Projucer/JuceLibraryCode/AppConfig.h there is:

#ifndef JUCE_WEB_BROWSER //#define JUCE_WEB_BROWSER 1 #endif
and for now I left this alone.

So: sudo apt-get install freeglut3-dev g++ libasound2-dev libcurl4-openssl-dev libfreetype6-dev libjack-jackd2-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev libxrandr-dev mesa-common-dev webkit2gtk-4.0

Then:

cd JUCE/extras/Projucer/Builds/LinuxMakefile make -j4 CONFIG=Release
The result was a 10MB executable ~/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer

I will post this now in case someone is answering about JUCE and will continue to try to compile Cabbage with help from Building cabbage on Linux 64 bit and SOLVED - Problems compiling Cabbage (alt: Cabbage deb for Kxstudio/Debian?) .

Hi Robin, sorry for not getting back to you sooner, I was away all weekend. Have you looked at these instructions:

Note that you need to use JUCE 5.2 for now. I will try updating to 5.3 when I get a chance.

Hi Rory,

How can I get a tarball of Juce 5.2? I looked around at https://github.com/WeAreROLI/JUCE Branch Master and could not find any such thing.

The easiest would be to clone the repo yourself and then checkout 5.2, but you can also just grab the archive here

OK - thanks. I thought I had tried the Releases link, but I must have missed it.

I used Juce 5.2 instead in ~/JUCE/ . I changed line 34 in JUCE/extras/Projucer/JuceLibraryCode/AppConfig.h to “#define JUCER_ENABLE_GPL_MODE 1”.

cd ~/JUCE/extras/Projucer/Builds/LinuxMakefile make -j4 CONFIG=Release

The result was a 10MB executable ~/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer

Referring to: https://github.com/rorywalsh/cabbage/tree/master/Builds/LinuxMakefile (file readme.md) “Build Cabbage under Linux” it was clear that I needed to install or compile Csound separately.

I compiled it from http://csound.com/download.html 6.10.0.tar.gz broadly according to https://github.com/csound/csound/blob/develop/BUILD.md#debian . I didn’t use my home directory. The source was untargzipped into xyz/csound/ and the build directory was xyz/cs6make/ . This seemed to work fine.

There are three SDKs at https://www.steinberg.net/en/company/developers.html , two of which have “VST” in their names. I chose the first one VST 3.6.9 Audio Plug-Ins SDK . I unzipped it to ~/SDKs/VST_SDK/ .

Then I tried to install Cabbage’s dependencies: The 1st of the 4 steps (they should be separated rather than all in one paragraph) according to the readme.md file is:

sudo apt-get install libfreetype6-dev libx11-dev libxinerama-dev libxcursor-dev mesa-common-dev libasound2-dev freeglut3-dev libxcomposite-dev csound libcsound64-dev libcsnd-dev libsndfile1 libsndfile1-dev libjack-dev libxrandr-dev msttcorefonts

(I did these steps before building Juce 5.2, but it should not matter.) These were already installed except for:

“Note, selecting ‘ttf-mscorefonts-installer’ instead of ‘msttcorefonts’”

and:

“The following packages have unmet dependencies:
libjack-dev : Depends: libjack0 (= 1:0.125.0-2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.”

So my modified command (including the packages I already have installed) was:

sudo apt-get install libfreetype6-dev libx11-dev libxinerama-dev libxcursor-dev mesa-common-dev libasound2-dev freeglut3-dev libxcomposite-dev csound libcsound64-dev libcsnd-dev libsndfile1 libsndfile1-dev libjack-dev libxrandr-dev ttf-mscorefonts-installer libjack0

This generated some errors. I am not sure why it decided to remove jackd2, which was previously installed and known to work. (It was installed as part of my Ardour installation.)

Removing jackd2-firewire (1.9.10+20150825git1ed50c92~dfsg-5) …
dpkg: jackd2: dependency problems, but removing anyway as you requested:
jackd depends on jackd2 | jackd1; however:
Package jackd2 is to be removed.
Package jackd1 is not installed.

Removing jackd2 (1.9.10+20150825git1ed50c92~dfsg-5) …
Selecting previously unselected package jackd1.
(Reading database … 317924 files and directories currently installed.)
Preparing to unpack …/jackd1_1%3a0.125.0-2_amd64.deb …
Unpacking jackd1 (1:0.125.0-2) …
dpkg: error processing archive /var/cache/apt/archives/jackd1_1%3a0.125.0-2_amd64.deb (–unpack):
trying to overwrite ‘/usr/lib/x86_64-linux-gnu/libjackserver.so.0’, which is also in package libjack-jackd2-0:amd64 1.9.10+20150825git1ed50c92~dfsg-5
Errors were encountered while processing:
/var/cache/apt/archives/jackd1_1%3a0.125.0-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

After trying to apply solved-problems-compiling-cabbage-alt-cabbage-deb-for-kxstudio-debian/684 to my own situation, I removed jackd1 and installed jackd2:

sudo apt-get install jackd2

I already had these installed: libjack-jackd2-0 and libjack-jackd2-dev. lib-jack-dev was not installed. I thought this might be good enough to build Cabbage.

I am not building Cabbage in a subdirectory of my home directory. The actual path is: /audio/csound-cabbage-build/cabbage-2.0.02 , hereafter BB. I edited the script Builds/LinuxMakefile/buildCabbage (no “.sh” as mentioned in readme.md file) so the 5 references to:

“…/…/…/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer” were now to:

“/home/robin/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer”

From BB/Builds/LinuxMakefile/ :

./buildCabbage

I got a bunch of errors and then remembered that there were 2nd, 3rd and 4th steps in readme.md regarding dependencies.

sudo add-apt-repository ppa:webkit-team/ppa

sudo apt-get update

This generated a warning and an errors:

W: The repository ‘http://ppa.launchpad.net/webkit-team/ppa/ubuntu cosmic Release’ does not have a Release file.

E: Failed to fetch http://ppa.launchpad.net/webkit-team/ppa/ubuntu/dists/cosmic/main/binary-amd64/Packages 404 Not Found

From BB/Builds/LinuxMakefile/ :

./buildCabbage

The first error was:

./buildCabbage: line 14: [: ==: unary operator expected

I think the problem is that the script is expecting to be run with an argument. This is inconsequential, and the error does not occur with “./buildCabbage xxx”.

(Now what I did after building Juce 5.2.)

There were 6 errors about not finding “…/JuceLibraryCode/JuceHeader.h”. I guessed this was due to building Cabbage in a location not in my home directory. The problem files were:

Source/Application/FileTab.h
Source/CabbageIds.h
Source/Application/CabbageDocumentWindow.h
Source/Application/CabbageMainComponent.h
Source/Audio/Graph/AudioGraph.h

Evidently there needs to be a file: JuceHeader.h in the currently empty directory /JuceLibraryCode/ . This directory should not be empty. In another unzip of the tarball it has a subdirectory and a bunch of files including JuceHeader.h.

With Beyond Compare I established that this was the only faulty directory and restored its contents from the fresh unzip. Now:

./buildCabbage xxx

produced the same error. Once again, the /JuceLibraryCode/ directory was empty. Stepping through the script it is clear that the deletion of all the directory’s contents results from:

/home/robin/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer --resave …/…/CabbageIDE.jucer

I would appreciate further guidance!

There should be a JUCE header file in cabbage/JuceLibraryCode/ if there is not then it looks like something went wrong with the Projucer step? Can you try to run:

/home/robin/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer --resave ../../CabbageIDE.jucer

And see what the output is in terms of the LinuxMakefile folder, and the JuceLibraryCode folder. Btw, I use the following script to build Cabbage on afresh Linux image for continuous integration. Maybe you can spot a step there that you have missed, although I think it sounds like you have ticked most boxes so far. I should mention in the readme that many of those dependencies might already be present on the host machine. The best thing would be to try building first, and see what error you might get due to dependency failure. Anyhow, let’s see what’s happening with the Projucer first.

I don’t understand how .travisWorkingLinux.yml could be used as a script. Do you feed it to some program to make shell scripts?

I guess that the problems I am having are due to building Cabbage in a directory other than the one you and Travis use. I want to sort this out, since in the future I may build multiple versions of Cabbage, and each needs to be in a different directory - not under my home directory.

In my /audio/csound-cabbage-build/cabbage-2.0.02/Builds/LinuxMakefile I found two directories which were recently created and are not in the tarball: CabbageBuild and build. I moved them elsewhere for reference. The former was empty and the latter had intermediate/Release/ directories, with no files.

From this directory I ran:

/home/robin/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer --resave ../../CabbageIDE.jucer
No new directories were created. After a few seconds Projucer complained:

Re-saving file: /audio/csound-cabbage-build/cabbage-2.0.02/CabbageIDE.jucer
Error when saving: At least one of your JUCE module paths is invalid!
Please go to the Modules settings page and ensure each path points to the correct JUCE modules folder.

This is an obscure error message. After some Googling I guessed that perhaps Projucer is both a program for doing things to files from the command line and an X application, which seems odd, but turns out to be true. None of its menus seem to work. After exiting, I noticed an error message: Xlib: extension “MIT-SHM” missing on display “localhost:13.0”. This lead me to: https://groups.google.com/forum/#!topic/linux.redhat.misc/g8PkAAoEoIU which lead me to believe that Projucer is expecting something of the X server it doesn’t have. I don’t use the physical Linux machine. I am doing everything with PuTTY and the Xming X server on a Windows 7 machine.

Projucer worked correctly from the actual Linux machine. I opened /audio/csound-cabbage-build/cabbage-2.0.02/CabbageIDE.jucer and opened up a “Modules” section of the list of files on the left. Editing one of these it became apparent that in the context of Projucer running with its current directory being /audio/csound-cabbage-build/cabbage-2.0.02/Builds/LinuxMakefile/ that its path was all wrong, as were all the paths of the other Juce modules. This was for “Path for “Linux Makefile””. All 13 module files were set the same way. For each one I ticked the “Use global path for this module” saved the file and closed Projucer.

The changes to the file were:

  1. Line 3 jucerVersion is 5.2.1 instead of 5.2.0. (As mentioned below, it was my mistake to be using Juce 5.2.1.)

  2. In the Modules section near the end, all the lines had "useGlobalPath=“1"” at the end, such as:

  3. In the JUCEOPTIONS line the 4 “enabled” items were replaced by “1”.

I also found that /audio/csound-cabbage-build/cabbage-2.0.02/JuceLibraryCode/ and its modules subdirectory (I guess this had further subdirectories) had been freshly populated. For completeness deleted these and restored this directory to the state it was in in the tarball. Then, as before, from /audio/csound-cabbage-build/cabbage-2.0.02/Builds/LinuxMakefile/ I ran my modified (to have an absolute path for Projucer) buildCabbage.

This proceeded successfully to a point:

===========================================
======== Build Script for Cabbage =========

This scripts assumes that Csound is installed in the default location, i.e, includes files
should be located in /user/local/include/csound while the Csound library itself should be
located in /user/local/lib It is also assumed that the VST SDK is located in ~/SDKs/

./buildCabbage: line 14: [: ==: unary operator expected
Re-saving file: /audio/csound-cabbage-build/cabbage-2.0.02/CabbageIDE.jucer
Finished saving: Linux Makefile
Finished saving: Xcode (MacOSX)
Finished saving: Visual Studio 2015
Finished saving: Visual Studio 2017
Finished saving: CLion (beta)
Cleaning Cabbage
Compiling FileTab.cpp
Compiling CabbageMainComponent.cpp
Compiling CabbageDocumentWindow.cpp
Compiling CabbageGraphComponent.cpp
Compiling CabbagePluginComponent.cpp
Compiling CabbageToolbarFactory.cpp

The next lines were a compiler error:

In file included from …/…/Source/Application/…/Audio/Graph/AudioGraph.h:28:0,
from …/…/Source/Application/CabbageGraphComponent.h:24,
from …/…/Source/Application/CabbageGraphComponent.cpp:12:
…/…/Source/Application/…/Audio/Graph/…/Plugins/CabbagePluginEditor.h:70:30: error: expected class-name before ‘,’ token
public ComboBoxListener,
^
…/…/Source/Application/…/Audio/Graph/…/Plugins/CabbagePluginEditor.h:164:10: error: ‘void CabbagePluginEditor::comboBoxChanged(juce::ComboBox*)’ marked ‘override’, but does not override
void comboBoxChanged (ComboBox* combo) override;
^~~~~~~~~~~~~~~

There were a few dozen other errors, including similar ones to this. However, the fact that some .cpp files compiled without errors indicates progress!

gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

Line 70 of /audio/csound-cabbage-build/cabbage-2.0.02/Source/Audio/Plugins mentions ComboBoxListener: (In the forum text box the code is proplerly indented, but it is not in the preview window.)

class CabbagePluginEditor : public AudioProcessorEditor, public Button::Listener, public ChangeBroadcaster, public ActionBroadcaster, public ComboBoxListener, public Slider::Listener { public:
This is the only mention of “ComboBoxListener” in the Cabbage code. It is not in the Juce code. Googling it finds 4k hits. This particular error was the second of multiple mentioned at: this forum:
installing-on-ubuntu-16-04-solved/973 . From this I see that my mistake is using Juce 5.2.1 rather than 5.2.0. I will try again with 5.2.0.

It shouldn’t matter a jot where you put the cabbage folder, as long as you keep the folder structure in place. I build several different versions from different locations all the time. One thing I usually do is make sure that the JUCE folder is in the same parent folder as my cabbage build folders.

parent folder:

  • cabbage 1
  • cabbage 2
  • JUCE
  • cabbage 3

And yes, we have to use 5.2.0 at this point. There have been issues reported on the JUCE list with people trying to run the Projucer in a headless env, so that might be an issue. I had to add these lines in my travis script to start an x server before running the Projucer:

Regarding the travis script, I merely linked it so you could see the steps taken each time Cabbage is built on a fresh Linux box. More as a reference point than anything else.

Thanks Rory. These instructions cope with Cabbage being built in a directory at a different relative location to the JUCE directory than you have been using. It is probably easiest to maintain the relationships you have been using, but I don’t recall seeing these being documented.

Here is an account of building Juce, Csound and Cabbage on another remotely accessed (via Windows PuTTy and Xming = ssh X tunneling) Debian 64 bit machine than the one I had been working on. So these steps should work for a fresh OS install and do not depend on anything mentioned in previous messages. As noted in message 1 above, I had reasons to replace KDE with Xfce. I had already installed build-essential and other things to build Codelite. I am running gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1).

I was able to compile Cabbage and get it working at least for a reverb demo. However, via X tunneling (using another computer’s keyboard, trackball and display), Cabbage’s menus would not work. This seems to be related to Juce insisting the X server do something regarding shared memory which is impossible with X ssh tunneling, and so there was an error message:

Xlib:  extension "MIT-SHM" missing on display "localhost:12.0".

See message 9 above for a link to a RedHat discussion concerning this problem.

I used http://cabbageaudio.com/download/ to get the source v2.0.02.zip and used unzip to place the source in a directory of my choice: /audio/csound-cabbage-build/cabbage-2.0.02 . This is different from where Rory and Travis put their Linux source, and requires some adjustments to files as noted below.

First, I need to install Juce and Csound. For this version of Cabbage, I must use Juce 5.2.0, which I got as a tar.gz tarball from https://github.com/WeAreROLI/JUCE/releases/ .

The official instructions on how to build Cabbage on Linux are in: /audio/csound-cabbage-build/cabbage-2.0.02/Builds/LinuxMakefile.readme.md . This is actually better to read as a plain text file, rather than by some rendering to HTML, such as we see (for the latest version) at: https://github.com/rorywalsh/cabbage/blob/master/Builds/LinuxMakefile/readme.md. since the 4 dependencies commands in the actual file are on separate lines and the HTML rendering of the markdown format squishes them all into a single paragraph.

The instructions in this read.me (for 2.0.02) include “To build Cabbage on any platform, you must download the latest release branch of the JUCE framework.” which is no longer incorrect. I must use Juce 5.2.0, which is no longer the latest.

My dependency commands, based on the attempt on the first machine, involve not removing jackd2. This is after sudo apt-get update. Many of these packages were already installed:

sudo apt-get install libfreetype6-dev libx11-dev libxinerama-dev libxcursor-dev mesa-common-dev libasound2-dev freeglut3-dev libxcomposite-dev csound libcsound64-dev libcsnd-dev libsndfile1 libsndfile1-dev libjack-jackd2-0 libjack-jackd2-dev libxrandr-dev ttf-mscorefonts-installer

sudo add-apt-repository ppa:webkit-team/ppa

sudo apt-get update

This generated some errors, as noted in message 6 above.

I placed the Juce code, as instructed by the readme.md, in my home directory, precisely: /home/robin/JUCE/ . (Midnight Commander’s F2 “Extract compressed tar file to subdirectory” command places it a directory JUCE-5.2.0 which I renamed.) (I don’t mind having library code in my home directory, but anything I am seriously working on belongs in a part of the file system which resides on a larger hard drive, which persists after I install a later version of Debian.)

I compiled it from http://csound.com/download.html 6.10.0.tar.gz broadly according to https://github.com/csound/csound/blob/develop/BUILD.md#debian, which assumes getting the source with git . I didn’t use my home directory. The location of this build seems to be unimportant. The source was untargzipped into /audio/csound-cabbage-build/Csound-6.10.0/csound/ and the build directory was parallel to this: /audio/csound-cabbage-build/Csound-6.10.0/cs6make/ . This seemed to work fine:

Edit, as root, /etc/apt/sources.list and ensure that each line beginning with deb has another line below it that is identical except that deb is replaced with deb-src. Then:

sudo apt-get update
sudo apt-get build-dep csound
sudo apt-get install cmake
cd /audio/csound-cabbage-build/Csound-6.10.0
mkdir cs6make
cd cs6make
cmake ../csound
make -j6
sudo make install
sudo ldconfig

I can run “csound -h” and get a help message.

There are three SDKs at https://www.steinberg.net/en/company/developers.html , two of which have “VST” in their names. I chose the first one “VST 3.6.9 Audio Plug-Ins SDK”. I unzipped it to /home/robin/SDKs/VST_SDK/ .

In order to build Cabbage, we need an executable Projucer, which functions both as a command line program for altering files and as an X program. However, as noted above, it makes unusual requirements of the X server and so will not run as an X application if the display is on another machine. Above, I used the X mode (using a physically connected monitor) to alter some items in a .juce file which is part of the Cabbage system. Here, I won’t attempt to run Projucer as an X program, and will make the changes to this and other .juce files manually. The changes are necessary, because in Cabbage 2.0.02, the path to some Juce library files is relative. Since my Cabbage build is in a different location, this doesn’t work and we have to tell Projucer to use an absolute location for these files. See the previous message for how I made the changes using Projucer as an X program.

Now to Juce. As mentioned in message 1 above, since I want to use Juce under the GPL, I cannot use the precompiled Projucer executable which comes with the installation. I need to build my own Projucer executable from the source. The first step in doing this is to alter the file /home/robin/JUCE/extras/Projucer/JuceLibraryCode/AppConfig.h (https://github.com/WeAreROLI/JUCE/blob/5.2.0/extras/Projucer/JuceLibraryCode/AppConfig.h) so in line 35: “#define JUCER_ENABLE_GPL_MODE 1”.

Message 2 above describes how I came up with these dependencies.

sudo apt-get install freeglut3-dev g++ libasound2-dev libcurl4-openssl-dev libfreetype6-dev libjack-jackd2-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev libxrandr-dev mesa-common-dev webkit2gtk-4.0

cd ~/JUCE/extras/Projucer/Builds/LinuxMakefile
make -j4 CONFIG=Release

The result was a 10MB executable ~/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer

Now to Cabbage . . . Below, “BB” means the Cabbage base directory, in my case: /audio/csound-cabbage-build/cabbage-2.0.02 .

To the best of my understanding (I knew nothing of these things two days ago) Juce is a multi-OS, highly audio-aware, development framework upon which Cabbage relies. The program Projucer is used by the Cabbage build script several times. As far as I know, it writes a directory full of stuff at BB/JuceLibraryCode/ deleting what was initially there before writing files and directories. The Cabbage tarball contains files and directories in BB/JuceLibraryCode/ but as far as I know, these are overwritten in the build process.

The Cabbage build script for Linux is: BB/Builds/LinuxMakefile/buildCabbage (I don’t know how to point to this file for 2.0.02 on GitHub. Here is the current version: https://github.com/rorywalsh/cabbage/blob/master/Builds/LinuxMakefile/buildCabbage, which is already very different from the version I am working with .). I made a copy so I could easily compare it with the modified copy I am about to make. (I use Beyond Compare for such comparisons, and FileLocator Pro, AKA Agent Ransack, for searching for items in directories full of text files.)

There are 5 instances of using a relative path to specify the location of Projucer:

../../../JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer

I changed these to an absolute path:

~/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer

The first one doesn’t matter, since it only runs if we use an argument “debug” after the Projucer command, which we don’t , but I changed it anyway.

I did not attempt to fix a problem with line 14 which generates an error “./buildCabbage: line 14: [: ==: unary operator expected” if the script is run without any argument. This error can be ignored.

Next I made some changes to five files, for reasons explained in the previous message:

BB/CabbageIDE.jucer
BB/CabbageLite.jucer
BB/CabbagePlugin.jucer
BB/CabbagePluginMIDIEffect.jucer
BB/CabbagePluginSynth.jucer

The MIDIEffect one is not referred to in the build script, but I updated it anyway. In the MODULES section at the end, every line should end with "useGlobalPath=“1"”. Some of them already have such an item, but set to 0. So

<MODULE id="juce_core" showAllCode="1" useLocalCopy="1" useGlobalPath="0"/>  

is changed to:

<MODULE id="juce_core" showAllCode="1" useLocalCopy="1" useGlobalPath="1"/>  

In order to keep the last line of buildCabbage happy, it is also necessary to create a directory, if none existed:

~.local/share/applications

Now, cd to the BB/Builds/LinuxMakefile/ directory, pray to the relevant deities and give the command:

./buildCabbage

This took a few minutes. The only compiler messages were warnings concerned deprecated declarations in CabbageToolbarFactory.cpp.

Apart from the a file ~/.local/share/applications/cabbage.desktop the results are all in /Builds/LinuxMakefile/CabbageBuild/ This will be handy for running different versions of Cabbage.

Cabbage
CabbageLite
CabbagePluginEffect.so
CabbagePluginSynth.so
cabbage.desktop
cabbage.png
opcodes.txt  

The first two are X applications. The next two are libraries for these. opcodes.txt is Csound’s list of opcodes. There’s no installation of executables or libraries. From the above directory I gave the command:

./Cabbage

and the program appeared on my Windows machine. In the SSH session in which I gave this command, some errors appeared, including:

Xlib:  extension "MIT-SHM" missing on display "localhost:12.0".

None of the menus work at all. This is the same problem which made it impossible for me to use Projucer as an X application via my Windows machine, via ssh X tunneling. This is clearly a Juce problem, rather than anything in Cabbage.

After verifying that the audio interface (a very basic USB Behringer UCA222) was working, by using Ardour both directly via ALSA and also via Jack using the ALSA driver, I tried to use Cabbage again. The cog icon brings up Settings and I could hear the test tone from my interface and see that the input signal was reaching Cabbage. This was with the ALSA driver at 44.1kHz with buffer sizes as small as 352. I left it at the default of 512. Jack was not available, but that’s OK for these tests.

The second icon from the left on the toolbar is “Open” and I was able to open an example:
/audio/csound-cabbage-build/cabbage-2.0.02/Builds/LinuxMakefile/CabbageBuild/Examples/Effects/Reverbs/MultiReverb.csd . It took more than a minute for the example to be ready to run. I clicked the Play button and lo and behold I had real-time Csound reverb working, with real-time graphic controls!

Next I will get this going on the first machine, which has an RME sound card.

The problem of inoperative menus remains. Surely, since Juce is such a widely used framework for GUI programs, there must be some way of making it work fully with X-forwarding. I found no other mention of SHM on this forum. The menus work fine when using a display connected to the physical machine.

Sounds like you’re getting there. The only issue I can think of with regards the menus not showing is a font problem. It could be that you don’t have any of the fall-back fonts installed? Check this file for those employed by JUCE:

Yes, this file is part of my Juce installation. Here is what I found with various X servers:

OS         X-server        MIT-SHM     Menus       Notes
                           error       work

Debian 8                   No          Yes
Debian 9                   No          Yes

Windows 7  Xming           Yes         No 
           VcXsrv          Yes         No          Xming derivative
           Cygwin/X        Yes         No   
           MobaXterm       Yes         No
           NetSarang*      Yes         Yes!        USD$249
           Starnet*        Yes         Yes!        USD$???

* Initial command: /usr/bin/X11/xterm -ls -display $DISPLAY

(I tried Cygwin/X derivative FreeXer and it couldn’t even set up the SSH session.)

So the MIT-SHM error appears to be a red herring.

With NetSarang, I guessed that it had some font which the other Windows X servers lacked which was only needed for the drop-down function of the menus. However, when I deleted all its fonts but the two required for the Xterm, Cabbage still displayed and worked perfectly. So I conclude that at least with the NetSarang X server, the Juce system is telling the X server what to display in terms of graphics rather than bytes and fonts. Yet the text editing worked fine with copy and paste, so the X server is getting text, if not requiring fonts.

The NetSerang X server had odd menu behaviour which required a lot of clicking. The Starnet one was odd with black flickering boxes, but with persistent clicking the menus could be made to work.

“Menus work = No” means that when I click on the top word of a menu, no menu drops down - at least not for 5 minutes or so, which is as long as I waited. The tool bar works fine, but there are extreme delays in loading an example. This (via a Linux X server, NetSarang or Starnet) takes a fraction of a second to display the code and be ready to play. With Xming etc. it can take over a minute, with the main Cabbage window frozen showing some incorrect stuff for all that time. Yet the real time display, such as of bubbles or water drops, seems to work fine.

“Menus work = Yes” also means examples are ready to play in a split second.

Something is going badly wrong between Cabbage and some otherwise perfectly reliable X servers. I would be surprised if the Cabbage code is in any way at fault I have been using Xming for 15 or more years and I am currently using the latest donation-powered release. I have never had trouble with things not working like this before . . . except for some lack of menu problems with Synaptic before I got rid of KDE and replaced it with Xfce. So it is not out of the questions that these menu and other problems result from something left behind from the KDE installation. Consequently, I will install a fresh Debian system and build Juce, Csound and Cabbage on it.

If that doesn’t help, then one workaround is to buy one of the two commercial X servers. Another is to use VirtualBox on my Windows machine to run a Linux system from which I can do multiple X sessions to the multiple Cabbage instances I expect to be running. (I have four dual hex-core X5670 Xeon Linux machines for audio, and perhaps there is a way of running more than one instance of Cabbage per machine, once I sort out Jack and multiichannel RME cards.)

Out of curiosity, why not just run it natively rather than through any kind of virtualisation?

The computer I use directly is a Dell E6410 laptop. It is a compact size with a good display, lots of USB ports, eSATA and ExpressCard. With a docking station and two DisplayLink USB adaptors it drives four 1920 x 1200 24" displays. Yet I can unplug it and use it elsewhere, such as on the verandah, with all applications still running, using a fixed IP address and WiFi rather than wired Ethernet, so all the SSH sessions stay up. There are sometimes glitches, but it generally works well, with the applications resizing themselves to the 1440 x 900 14" display. This is with Windows 7 and Classic Start Menu so I retain the Windows 95 style branching set of application menus I have been adapting since about 1995. I run Linux programs via SSH and X and do not interact with the windows managers of the Linux machines.

When I last checked, there was no form of Linux which could dynamically adapt to such varying display arrangements. I may have dozens of things running and I don’t want to reboot the machine every time I take it in or out of the docking station.

There are some Windows programs I need to run directly for my paid work, including Visual Studio. Photoshop 6 from 2000 is perfectly good and has things I don’t find in other image editors. I use MS Word 2013 with updates for later file formats since I find it more reliable than later versions, and because it has a Control Y repeat function missing in later versions. I use on older Windows Microchip MPLab microcontroller IDE. I prefer some Windows-only programs for text editing (Notepad++) and finding text in large numbers of files (FileLocator Pro). I just found that Notepadqq is regarded by some as a Notepad++ equivalent for Linux https://medium.com/brian-besaw/notepadqq-my-search-for-a-linux-notepad-equivalent-has-ended-2b39704ab856 . I guess most of these could be run under Wine, but in practice I need to be able to test some of what I compile on a real Windows machine.

I find Samba mounting of Linux file systems on my Windows 7 machine is more robust than NFS between Linux machines. NFS sometimes fails for reasons unknown (Ethernet glitches?) and then accessing the stale mount point clobbers the thread doing such access. I think this is really a failing of Linux rather than NFS - but I frequently have to close a Midnight Commander session due to a stale NFS mount, and sometimes reboot the machine. (Googling reveals lots of people with the same frustrations, and no solution.) Samba links between Linux machines wouldn’t carry all the finer points of the Linux file system. SSHFS might be OK, but there is no file locking, I think for one user only and people complain about its glitches too, even on a LAN. I can access all my Linux machines via Windows mounts, though for various reasons I normally only access the /audio/ directory, which is on a separate HD. That HD survives OS installations and is one reason I try to avoid putting any valuable work in my home directory, though I suppose I could use a simlink from there, such as ~/JUCE to somewhere in the /audio/ system. All my Linux work is done via this one Windows laptop, usually running with a proper keyboard and 4 monitors. I always use the Logitech M570 wireless trackball - never the touch pad. The Linux sessions are SSH for terminal and X sessions to other machines, or sometimes to a Linux VM under VirtualBox on the Windows machine. I don’t normally use VirtualBox’s native display of the VM.

If all goes well, I will be using one instance of Notepad++, with separate windows for each file, to edit multiple .csd files on multiple Linux machines, rather than directly editing them through Cabbage. If there’s a way Cabbage can easily reload the file, compile and run, that would be great, rather than close file, open file (the same file name) and then compile and run.

I last used Csound about 20 years ago with a 100MHz 486 and a 1024 x 768 CRT monitor which cost $1k, running Red Hat 4. I did not use it in real time. An 8 minute piece took 36 hours to render at 44.1kHz with ksmps = 3 for full quality. I used slower sample rates, higher ksmps and various shortcuts to run in some rougher “draft” modes which would take a few hours. Rather than work with the clunky Csound language - lack of functions and complex data types etc. - I have been planning to write my own synthesis system using C++. This will not be a separate compiler, language etc., just using C++ in particular ways. I still plan to do this, but it is too much work to get running in the foreseeable future.

The same piece renders in about 9 minutes on a single core of my 7 year old 12 core 3GHz X5670 Xeon machines. A brand new 6 core i7-8700 runs at 4.3GHz with all cores running and good cooling. This would probably render the piece in 4 or 5 minutes - twice as fast as real-time. A water-cooled, overclocked i7-8700k running just a single core would be faster still. So, even allowing for real-time overheads, these chips could run a piece about 6 times as complex in real-time IF I could construct it over multiple Jack-linked Csound or Cabbage(Csound) instances, since I assume that these need to run any one set of interdependent instrument instances in a single thread. Splitting a piece over multiple instances of Csound or Cabbage(Csound), I assume via Jack, is tiresome, bug-prone and wasteful of CPU time. Some things can’t be split. So the speed of each core is more significant then the number of cores, to allow the piece to be split into fewer, bigger, chunks.

A few days ago I read about Cabbage and installed it on Windows. The ability to do real-time control and display of a Csound “piece” - now a real-time .csd file - is something I am really looking forward to using! Likewise with Ardour, Jack and netJack, and I guess some kind of way of recording some control changes via Ardour to affect what is happening in Csound or Cabbage(Csound). I have no experience, interest or time to learn GUI programming and there’s no way I would come up with anything resembling Cabbage on my own, so any future C++ system I write will be made to work with a suitably modified version of Cabbage.

My .orc and .sco files are 190 columns wide since some of my ugens have 24 arguments. This will surely grow, so I will need to be able to edit text files which span two 1920 pixel wide monitors. Later I plan to get a reasonably small (for a TV, 43 inch diagonal, which is massive for a computer monitor) 60Hz “4k” KD43X7000E TV and use it as a monitor via a DisplayLink DL-6950 USB adaptor, which can actually drive two of these 3840 x 2160 displays @ 60Hz. Two such 4k TVs are affordable, but there are limits to what my 1955 model eyes can handle. There are Linux drivers for the DL-6950, so it is possible I would use a physically quiet Linux machine for music-only work in the lounge room, or put a physically noisy one nearby and use a USB-3 extension cable to drive the DL-6950 box, which for HDMI cable reasons needs to be close to the TV. The two 8 channel Fostex VC-8 48kHz AD/DA converters will be there, connected by 20 metre TosLink optical cables to the physically noisy Xeon machines in another room, using two old RME PCI cards via external PCIe to PCI adaptors.

I am doing a fresh install of Debian 9.4 with XFCE for a fresh build of Juce, Csound and Cabbage.

Wow, that’s quite some setup! I see now why your persisting with this :wink: Good luck, and let me know if you get it sorted.

On another machine - an old but 64 bit Dell laptop - I did a fresh install of Debian 9.4 with XFCE as the window manager - no trace of KDE as far as I know. I was using 9.3 on the two machines mentioned above. So this is totally different hardware and a fresh OS of a later subversion.

I followed my instructions (not realising that I had downloaded a just-released version of Csound 6.11.0, whereas I had used 6.10.0 in the builds mentioned above) and the Cabbage build failed. None of the tarball’s Makexxx files in BB/cabbage-2.0.02/Builds/LinuxMakefile/ had been overwritten, as they should be, by successive runs of Projucer. Projucer had not been running. I gave the ./buildCabbage command via an SSH session to the new machine, and I noticed some errors about a program, presumably Projucer, being unable to start an X session. So it seems that Projucer really needs to start an X session, even if I never see its screen or interact with it, as part of the build process.

The problem was due to an X-server misconfiguration on my Windows machine. When I fixed this, I was able to run Projucer from the command line and have it appear as an X application on my Windows machine. However, I noticed that the menus of Projucer do not work and that the SSH session included: “Xlib: extension “MIT-SHM” missing on display “localhost:11.0”.”. The old (Debian 9.3) Projucer program was 10,188.696 bytes and the new one was 10,200,984. I attribute this to different versions of some libraries. I checked that the JUCE and Cabbage directories on the two machines had no significant differences.

Running buildCabbage again everything went well except that the line:

g++ ../../Source/testCsoundFile.cpp -o testCsoundFile -I"/usr/local/include/csound" -lcsound64

caused an error. Then I realised that this was Csound 6.11.0. The error was:

 In function `Csound::GetInputName()':
 testCsoundFile.cpp:(.text._ZN6Csound12GetInputNameEv[_ZN6Csound12GetInputNameEv]+0x18): undefined reference to `csoundGetInputName'

The changelog https://github.com/csound/csound/releases mentions internal reorganisation. The new /usr/local/include/csound.hpp has additional lines mentioning a function csoundGetInputName(). I didn’t purse this further.

All the executables were produced OK. I ran Cabbage from the actual machine and it worked like a charm, menus and all, with the UCA222. Running it with ssh X forwarding from my Windows machine, with Xming, the usual MIT-SHM error message appeared and . . .

The menus did not operate when the program was first started - but I only clicked once or twice. I used the “open” toolbox icon (second from left) to open the MultiReverb example and this loaded instantly. It played fine and while it was playing, I was surprised to find that the menus worked, to some degree at least, in that a menu did drop down, though I don’t recall whether it stayed down for long enough for me to select an option. Thereafter, the menu behavior was all over the place. For all I know, the behavior was being controlled by the swimming direction of a particular fish somewhere in the South Pacific.

Sometimes a menu will drop down, most times not. If it drops it will be about 0.2 seconds after I click it, and it will appear and disappear in about 0.2 seconds. The Toolbar icons reliably produced results, but in the Settings, it was impossible to change Audio Device Type, Output or Input, due to the drop-down lists repeatedly appearing and disappearing when I held the left trackball button down. This behaviour is different from the previous build, but actually less useful, since with the previous build, I could use the Settings OK.

On subsequent runs the “open” icon worked fine, but it took more than a minute to load the example.

Everything worked fine with the NetSarang X server.

So there is something profoundly flaky going on between the Cabbage executable and the mature, otherwise reliable, Xming. I think the problem is in Juce, not in the Cabbage code.

I wondered if things would be different if I chose not to set the option for using Juce under the GPL.

With the current release of Juce, the downloaded zip file (from https://shop.juce.com/get-juce/download , which only contains the latest release) contains a Projucer which is ready to run in the root directory of the zip file, but I think it won’t do anything unless I signed up for an account at Roli/Juce, which I didn’t. The zip and tar.gz files of all the releases at https://github.com/WeAreROLI/JUCE/releases do not contain any pre-built Projucer.

As Rory mentioned above, Cabbage 2.0.02 won’t build with the latest Juce (5.3.2 as of 2 days ago) - it needs 5.2.0, and the zip and tarballs for these do not contain an executable Projucer. Since Juce is updated every month or so, unless the Juce changes are immaterial to Cabbage or unless Rory updates Cabbage for each such Juce version, then generally it will be necessary to build Projucer (unless we happen to have already got the zip file of the correct version with the pre-built Projucer AND we have a Juce account).

I don’t have a Projucer-containing 5.2.0 Juce zip file. I wonder if I rebuild Projucer 5.2.0 with the GPL option set to 0, and then try to use it with a Roli/Juce account, whether the build of Cabbage would produce an executable which works better with Xming.

I rebuilt Projucer with the GPL flag set to 0. The resulting Projucer executable was considerably larger. Rebuilding Cabbage with this produced no noticably different results. The executable was the same apart from a few bytes of date and some other things. What I wrote above about Juce accounts is probably all wrong.

I can access Cabbage remotely from my Windows machine using a Linux VM via VirtualBox’s window. This works quite well. With a Debian 8 KDE VM I could adjust VirtualBox’s assignment of display RAM and screens (which I don’t understand) and so was able to get a VM display covering two of my monitors. Cabbage seemed to have a problem moving the left edge of instrument GUIs further right than about 1458 pixels from the left of the Cabbage window. I could run two or perhaps more lightweight VMs for this purpose, but the Windows machine only has 8GB of RAM.

I find the real time patchability amazing. Likewise the real-time display of things and control. Likewise the ability to edit the GUI elements by moving them directly, by editing the code and by using the editor thing on the right, with them all being linked . . .amazing. Then there is the plugin export facility . . .

It will take me a while to relearn Csound and learn Cabbage. Thanks Rory and Team for this extraordinary program!!

Thanks for you kind words of wonder and awe. I feel the same way about how you’re using Cabbage!

For Linux remote hosts, XDMPC (using Xming or some other X-server) is better than Windows Remote Desktop Connection, via VNC or other such protocols

I found two better ways to control Cabbage from my Windows machine. The first involves the built-in (to Windows 7) Start > Programs > Accessories > Remote Desktop Connection using the Xorg protocol (not to be confused with the XDMCP protocol), which I think requires the xrdp and/or xorgxrdp packages to be installed. This works OK, but there is no connection with the Windows clipboard, and the entire desktop size (actually there are four workspaces, any one of which can be seen in the desktop) is fixed as the size of one of my monitors: 1920 x 1200. The window can be made smaller, but this only shows part of the desktop - the desktop itself is not resized.

The second, which I think is better, uses Xming or in principle any other suitable X-server on the Windows machine to directly access the desktop of the Linux machine using the XDMPC protocol. This is not related to SSH, and is suitable for a LAN. I had numerous frustrations getting this going, though in principle it is simple. I couldn’t understand why it worked on some Linux machines and not on others, but I had been mucking around with various packages and settings. So I started afresh and got it working without any fuss.

With Xming and XDMPC, the size of the desktop (and so the four workspaces, which are accessible via the miniatures at the top right) instantly adapts to the Xming window size on the Windows machine. Cabbage works fine with this arrangement, in contrast to the problems I encountered as mentioned above.

The individual application windows are all within the desktop rectangle, however big this is, whereas with ordinary SSH X forwarding, as I was attempting previously, each window produced by Cabbage, including the GUI windows for each .csd file, was a separate Xming window on my Windows machine which I could move anywhere and individually minimise. XDMPC’s arrangement of all the windows being within the one desktop window is something of a limitation. However, I can make the desktop as big as I like - including spanning four 1920 x 1200 monitors. This expansion, unfortunately, creates a high risk of crashing Xming. I am still figuring out how to do it - I think it may be best to do moderate expansions quickly, rather than dragging the edge of the window slowly before Xming and Xfce catch up with the size the window was 50ms earlier. Perhaps it is better to change the size when the desktop is relatively empty.

An advantage of all the Cabbage windows being in a single resizable and minimisable desktop window is that if I have multiple Linux machines, each running an instance of Cabbage (I assume that only one can run), then I won’t be so easily confused by having the various windows of four Cabbage installations all over my Windows desktop.

With the cursor inside a desktop window such as this, Alt-Tab is captured by Xming and sent to Xfce, which steps through the available applications. This is good, since otherwise there would be no quick way of stepping through them, and is probably better than having these remote programs all mixed up with Windows programs. The single desktop window appears as a single item in the Windows alt-tab list. (I use VistaSwitcher to provide 4 rows of 12 icons for Alt-Tab to run through.)

Fresh install of Debian 9.4 with Xming & XDMPC setup

Here is how I did a fresh install of Debian 9.4, set up this XDMPC arrangement with Xming, then then built Csound, Juce and Cabbage. This was on a dual X5670 Xeon machine, but I had previously done something similar on an old 64 bit Core Duo laptop. On the laptop I used a live/install ISO but here, for the Xeon machine, I used a net-install ISO, since it had trouble mounting the live/install one. (In this IBM x3550, with the live/install ISP the “Detect and mount CD-ROM” step failed with “Installation step failed”, which did not occur with the net-install ISO.) This explanation is rather long, but it might help someone get Cabbage running nicely, since it specifies everything from the start of the Debian installation. There are other Linux distributions perhaps better suited to audio, but I need these machines for other purposes too.

I used a net-install ISO file with non-free software and “extra firmware”, since these IBM x3550 Xeon machines have an Ethernet chip which requires a non-open-source driver. These come from http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ . The particular ISO file is /9.4.0+nonfree/amd64/iso-cd/firmware-9.4.0-amd64-netinst.iso . I wrote this 340MB ISO to a USB stick using in32 Disk Imager 1.0 https://sourceforge.net/projects/win32diskimager/ . This creates a suitable file system for booting from USB. I chose “Advanced options > Expert installer” which is a graphic installer which enables me to set a fixed IP address easily. (Other installers use DHCP and then allow me to go back and set the fixed IP address.) I set up both root and robin accounts, rather than just robin as a sudoer. At “Software selection” I chose Debian desktop environment, Xfce, SSH server and Standard system utilities".

I can’t yet log int via SSH as root, though I do this later since it is the only way I have found to run Synaptic via X forwarding via my Windows machine. (“sudo synaptic” works fine via XDMPC, but that is not yet set up.) I SSH to the machine as user robin, which is not a sudoer yet, so I su to root.

su -
apt-get update
apt-get install mc

I log in separately as robin and run Midnight Commander (mc) once, set the configuration: Always, internal edit and safe delete, save the setup and exit. Then with mc as root I set the same options and edit /home/robin/.config/mc/ini to alter a line which specifies better colours than the default of blue and white, with the nearly indistinguishable yellow for highlighting:

base_color=normal=lightgray,black:selected=black,magenta:header=black,magenta

As root, I add a line 25 in /etc/ssh/sshd_config : “PermitRootLogin yes” and restart the SSH server: “service sshd restart” . Now I can SSH to the machine as root. For both root and robin: “update-alternatives --config editor” and choose “2” for mcedit. As root:

apt-get install sudo
visudo

Due to the previous step this will run mcedit, rather than nano or the original vi editor (the inscrutable editor of seriously old-school uber-Unix-geekcom, which is not even mentioned nowadays in update-alternatives). I add a line after the root line: “robin ALL=(ALL) ALL”. Now user robin is a sudoer and I can use sudo for all superuser commands. I update all the currently installed packages, but this produced no changes since I just installed the system:

sudo apt-get dist-upgrade

htop displays process information in real-time, with activity for each “CPU”, which in this Xeon machine means a logical-processor - and there are two logical processors (Intel hyperthreading) per core. I won’t document my NFS (linking Linux file systems) or SAMBA (Windows file access to Linux machines) setup. lm-sensors provides the “sensors” command which can report the temperature of individual cores of the two CPU chips.

sudo apt-get install htop samba nfs-common nfs-kernel-server lm-sensors cpufrequtils

Package cpufrequtils includes a program “cpufreq-info” which reports on the “governor” used by each of the logical processors in the system, though these are referred to as “CPUs” in its report, and as “cores” by Cabbage. The dual Xeon machines have two CPU chips, each with 6 cores (and their physical numbering is not contiguous). Each core has two register sets which it switches between as part of Intel’s hyperthreading. Each such register set’s operation of the core is presented to the operating system as (the best term I know) a “logical-processor”, each of which can run a thread. But the core’s activity is switched rapidly between these two threads, including especially when one thread has to wait for a few dozen clock cycles when it needs data which is not in the L0 cache (a “cache-miss”).

For real-time work, we need to do 3 things which most people don’t worry about. Firstly we need to (1) set the performance governer for the entire machine. (This is reported per logical-processor, but as far as I know the governor works per core - and we want to use the “performance” rather than the “ondemand” governor for all cores.) This means the cores are already running at their maximum clock frequency, so real-time code is not delayed by some microseconds or whatever in which the core speeds up to its maximum clocke rate when it becomes newly active with work. On this system, with the default-installed “ondemand” governor, the cores run at about half their maxium clock rate, and so at about 1.5GHz, when they are not being used very much. The easiest way to set this is by creating a file /etc/default/cpufrequtils and have it contain the following line:

GOVERNOR="performance"

This takes effect after a reboot, and the reasults can be seen by “current CPU frequency” lines in the output of cpufreq-info.

Secondly, we want to disable the second logical processor (or the first, either will do), to (2) disable hyperthreading. This way, each core only uses one register set and cannot switch to the other (the other logical-processor running some other thread) as soon as it hits a cache miss. The Ardour manual mentions disabling hyperthreading, but has no guidance on how to do it: http://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/ I believe the statement there that this is becoming less common is incorrect. All but the weediest of modern Intel x86-64 CPUs use two-way hyperthreading per core. This can be turned off in the BIOS/UEFI, but I want it on for general computing and off for real time music work.

As far as I know there is no official standard for how the logical-processors are mapped to the “CPU” numbers within Linux. By scrutinising the output of cpufreq-info, by observations with htop (which can be set to number the “CPUs” from 0, rather than 1), and by other reading and experiments I determined that in order to shut down the second logical-processor of each of the 12 cores in these dual Xeon machines, it suffices to run a script, as root, with the following commands - hyperthreading-off.sh:

#!/bin/bash

#echo 1 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu2/online
echo 1 > /sys/devices/system/cpu/cpu3/online
echo 1 > /sys/devices/system/cpu/cpu4/online
echo 1 > /sys/devices/system/cpu/cpu5/online

echo 0 > /sys/devices/system/cpu/cpu6/online
echo 0 > /sys/devices/system/cpu/cpu7/online
echo 0 > /sys/devices/system/cpu/cpu8/online
echo 0 > /sys/devices/system/cpu/cpu9/online
echo 0 > /sys/devices/system/cpu/cpu10/online
echo 0 > /sys/devices/system/cpu/cpu11/online

echo 1 > /sys/devices/system/cpu/cpu12/online
echo 1 > /sys/devices/system/cpu/cpu13/online
echo 1 > /sys/devices/system/cpu/cpu14/online
echo 1 > /sys/devices/system/cpu/cpu15/online
echo 1 > /sys/devices/system/cpu/cpu16/online
echo 1 > /sys/devices/system/cpu/cpu17/online

echo 0 > /sys/devices/system/cpu/cpu18/online
echo 0 > /sys/devices/system/cpu/cpu19/online
echo 0 > /sys/devices/system/cpu/cpu20/online
echo 0 > /sys/devices/system/cpu/cpu21/online
echo 0 > /sys/devices/system/cpu/cpu22/online
echo 0 > /sys/devices/system/cpu/cpu23/online

This has a line for each logical-cpu. The first one of each core is left in its 1 = enabled state. The second one is disabled by “0”. Only the “0” lines are needed, but the others are for completeness. We are not allowed to mess with the online status of cpu1. (We might find ourselves in a "Stop . . Dave . . . " scenario if we did.) I have another script with all 1s to turn hyperthreading back on. Be sure to close and restart htop after running either such script. I put these scripts in my home directory and run them with sudo. With hyperthreading off, htop shows only 12 “CPUs”, instead of the usual 24.

The third thing which needs to be set up for real-time work concerns (3) realtime scheduling, as described at: http://jackaudio.org/faq/linux_rt_config.html . I don’t understand this in detail or know how to test its effectiveness. I think the Ardour installer does this, but I haven’t yet installed Ardour. The steps I took were:

1 - As root, create and edit a file called /etc/security/limits.d/99-realtime.conf containing:

@realtime   -  rtprio     99
@realtime   -  memlock    unlimited

2 - As user robin, create the “realtime” group and make this user a member of it:

sudo groupadd realtime
sudo usermod -a -G realtime robin

3 - Log out of whichever session this was an log in again. (For the purposes of running Cabbage without any menu etc. problems, I need the new login to be via a new Xterm session launched from Xfce’s desktop (or from its Applications menu) I am remotely accessing via XDMCP and Xming. However, at this point I don’t have XDMCP set up or Cabbage compiled.)

To enable XDMCP remote desktop access, in the Linux machine we need to tell the display manager to allow this. In this installation, this is lightdm. The display manager orchestrates the initial graphic login process in a way which enables the user to choose between multiple “desktop managers” (or by some other names). In this installation there is only one: Xfce. As root (sudo mc and then use F4 to edit the file) I edit /etc/lightdm/lightdm.conf such that:

[XDMCPServer]
#enabled=false

becomes:

[XDMCPServer]
enabled=true

Then I reboot or restart it:

sudo systemctl restart lightdm.service 

This is all that is required. There are no packages to explicitly install. lightdm was already installed, and I guess that it relies on the libxdmcp6 package, which was also already installed, for this functionality. (I got into all sorts of bother when I was confused between XDMCP and various other remote desktop protocols, such as RDP, as used by the xorgxrpd and xrdp packages, neither of which are needed for XDMCP.)

It is possible to use other X-servers than Xming for XDMCP remote desktop. There is a command, below, by which I start Xming to do this for each particular Linux machine. First I will show the interactive way of testing XDMCP availability and how this leads to running an instance of Xming to access the Xfce desktop. I already have Xming installed in my Windows 7 machine so that it runs at startup. There is a shortcut in my Start > Programs > Startup directory which runs this command (which is the ordinary supplied command for running Xming as part of the version 7.7.0.31 donationware current release):

"C:\Program Files\Xming\Xming.exe" :0 -clipboard -multiwindow -nolisten inet6

This causes an instance of Xming to run continually, creating an icon in the system tray. It can run any number of SSH X forwarding sessions which originate in PuTTY. For the configuration of PuTTY, turn on “Enable X forwarding” in each host’s profile’s Connection > SSH > X11 section. (Don’t enable this for hosts outside the LAN - bad things happened when I did this for hosts in other countries.) This normally-running instance of Xming uses “Display 0”. Each of its sessions gets a separate window, which can be resized and made full screen (within a monitor). The command lines given below fire up an instance of Xming which connects to a particular host, by name or IP address, on the LAN and creates a single resizable window for XDMCP remote desktop. These instances need to be able to run at the same time as each other, including the normally running Xming instance, and all such instances need to have a different “Display” number. So for five such XDMCP commands (each in a separate shortcut in one of my Start menu directories (using the Classic Start Menu program, but you can put them on your desktop) I use “Display” numbers 1 through 5.

Back to the interative method. In Start > Programs > Xming there is a shortcut “Xlaunch” which runs Xlaunch.exe - which may later run Xming with a particular command string. I run Xlaunch, type in “9” or some such number not otherwise used for “Display number” and select the “One Window” option. The “Multiple windows” option can’t be used for XDMCP. This is the mode just described for the continually running Xming instance. “Full screen” and “One window without titlebar” can be used fr XDMCP, but I choose not to. The Fullscreen mode covers the screen of the Windows monitor which has the task bar. It can’t be made any smaller, and it is difficult to figure out how to minimise. The “One window without titlebar” has similar problems. The “One window” mode results in a window which can be resized, or made full screen (single monitor) like any ordinary Windows program, which is what I want. I click “Next”. In the next step I select “Open session via XDMCP” and click “Next”.

For the next step I leave the “Connect to host” option set, rather than “Search for hosts (broadcast)” and I leave the 'Use indirect connect" option unselected. In the XDMCP host chooser section I click the XPing button and wait for 15 seconds or so until it greys out and the Reset button is in black. Above will be a list of the names of hosts (Linux machines) on my LAN which are ready to accept XDMCP connections. This means they are accepting UDP packets on port 177 and responding in particular ways. Assuming more than one is listed, I select the name of the host I am setting up and click “Next”, “Next” and “Finish”. (At the last step I can save a configuration file. The configuration file can be double-clicked to launch Xming, but I choose to do it via shortcuts.) The newly started Xming instance can be found with Alt-Tab or by finding a second Xming icon in the System Tray, with a mouseover indicating the “Display” number just entered into Xlaunch. If all is well, this will be window which nearly fills the primary Windows monitor screen, but is not full-screen. It will show the blue Debian background with lightdm’s login box for username and password.

Using this, (with a few seconds delay, and first time, the option for a default config, which I choose) I get my Xfce desktop for either root or robin. It can be moved, resized and made fullscreen. Cabbage works like a charm within this system. A command line for a shortcut to make this happen for a particular Linux machine, here specified by its IP address, with a particular initial size for the window, is:

"C:\Program Files\Xming\Xming.exe" :1 -screen 0 1920 1170 -keyhook -query 192.168.1.50 -clipboard -nowinkill

This appears in the primary monitor’s screen. Specifying a width wider than this will not produce a wider initial window.

So setting up XDMCP with Xming is actually very easy. My difficulty in recent days was that I didn’t clearly understand what it was and how it was unrelated to VNC and other remote desktop protocols. (I was confused by the “Xorg” option in MS Remote Desktop Connection, which I was able to get working with one, the other or both of the xordxrdp / xrdp packages. Whatever that is, MS Remote Desktop Connection does not work with the XDMCP arrangments just described.)

One more thing which I think is worth doing: From the Xfce desktop: Applications > Settings > Power Manager > Display: Turn off “Handle display power management” and set the Blank slider to the left for “Never”. I think this is needed to prevent the remote XDMCP representation of the desktop being black, and not woken up by keyboard or mouse/trackball action on the Windows machine.

So now I have a basic Linux setup. I reboot it and check that XDMCP still works. I installed a bunch of packages for C, C++ etc. compilation:

sudo apt-get install build-essential

Building Csound

It doesn’t matter to Cabbage or anything else where Csound is built. I compiled it from http://csound.com/download.html 6.11.0.tar.gz broadly according to https://github.com/csound/csound/blob/develop/BUILD.md#debian, which assumes getting the source with git . I untargzipped it into /audio/csound-cabbage-build/Csound-6.11.0/csound/ and the build directory was parallel to this: /audio/csound-cabbage-build/Csound-6.11.0/cs6make/ . This seemed to work fine:

Edit, as root, /etc/apt/sources.list and ensure that each line beginning with “deb” has another line below it that is identical except that “deb” is replaced with “deb-src” (which was the case). Then (cmake was already installed, but its installation is mentioned here for completeness):

sudo apt-get update
sudo apt-get build-dep csound
sudo apt-get install cmake
cd /audio/csound-cabbage-build/Csound-6.11.0
mkdir cs6make
cd cs6make
cmake ../csound
make -j6
sudo make install
sudo ldconfig

I can run “csound -h” and get a help message.

Building Projucer and Cabbage

I downloaded Cabbage 2.0.02 as a tarball rather than getting it from git. The link from http://cabbageaudio.com/download/ was to a zip file, but I looked in https://github.com/rorywalsh/cabbage/releases and chose the tarball (tar.gz) version of the source code. From messages above I understand that Rory usually has particular locations for building Cabbage and Juce and that they are normally in the same relative locations to each other. Here I have Juce (the audio-aware multi-OS framework) in its normal location in my home directory, but the Cabbage build somehere else, since I will want to compile several versions of it, including perhaps with my own tweaks. I untargzipped (Midnight Commander F2) the source into /audio/csound-cabbage-build/cabbage-2.0.02, hereafter referred to as “BB”.

The readme files are in markdown format and are more easily read as plain text. See message 1 above about how I found it hard to get a good free Windows markdown reader. Also, note that the git rendering of the Linux instructions is actually less readable than the original readme.md text, since it shoves multiple, separate line, shell commands all into one paragraph. I couldn’t find a git rendering of the actual 2.0.02 readme.md file for Linux, but the current version is at: https://github.com/rorywalsh/cabbage/tree/master/Builds/LinuxMakefile . In my source directories, it is at BB:/Builds/LinuxMakefile/readme.md .

readme.rd states, in part: “The VST SDK can be downloed from https://www.steinberg.net/en/company/developers.htm Make sure that the VST SDK resides in a folder called SDKs in your home directory, i.e, ~/SDKs”. There are three SDKs at https://www.steinberg.net/en/company/developers.html , two of which have “VST” in their names. I chose the first one “VST 3.6.9 Audio Plug-Ins SDK”. I unzipped it (“unzip”) to /home/robin/SDKs/VST_SDK/ .

readme.sd also states: "You will also need to download the latest version of JUCE (master branch, 5.2)

  • Build the Projucer". As I learned from the above, Cabbage needs precisely Juce 5.2.0, from October 2017. I got the tarball from https://github.com/WeAreROLI/JUCE/releases and placed its contents in /home/robin/JUCE, hereafter ~/JUCE .

My dependency packages for Cabbage, based on readme.md and builds in recent days involve not removing jackd2. This is after sudo apt-get update. Many of these packages were already installed:

sudo apt-get install libfreetype6-dev libx11-dev libxinerama-dev libxcursor-dev mesa-common-dev libasound2-dev freeglut3-dev libxcomposite-dev csound libcsound64-dev libcsnd-dev libsndfile1 libsndfile1-dev libjack-jackd2-0 libjack-jackd2-dev libxrandr-dev ttf-mscorefonts-installer software-properties-common     

sudo add-apt-repository ppa:webkit-team/ppa
sudo apt-get update`

The last two steps generated some errors, as noted in message 6 above.

In order to build Cabbage, we need an executable Projucer, which functions both as a command line program for altering files and as an X program. (I think that when running from an SSH shell, it also needs to be able to display itself as an X program, even though I don’t see it. Earlier, when I tried to build Cabbage via SSH when my Windows machine was not properly configured for X forwarding, so Projucer could not run as an X application via Xming, it actually did none of the work it was required to do, and the build failed with all sorts of errors due to it proceeding on the basis of the files from the tarball which Projucer was supposed to overwrite.)

I want to use Juce under the GPL so I need to build Projucer from source. I also need to build Projucer from source because there is no already compiled executable in the zip or tar.gz files in the Releases page as mentioned above. (There is such an executable in the very latest release’s zip file from the juce.com downloads page.) The first step in doing this is to alter the file /home/robin/JUCE/extras/Projucer/JuceLibraryCode/AppConfig.h (https://github.com/WeAreROLI/JUCE/blob/5.2.0/extras/Projucer/JuceLibraryCode/AppConfig.h) so line 35 is: “#define JUCER_ENABLE_GPL_MODE 1”.

Message 2 above describes how I came up with these dependencies.

sudo apt-get install freeglut3-dev g++ libasound2-dev libcurl4-openssl-dev libfreetype6-dev libjack-jackd2-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev libxrandr-dev mesa-common-dev webkit2gtk-4.0

cd ~/JUCE/extras/Projucer/Builds/LinuxMakefile
make -j4 CONFIG=Release

The result was a 10MB executable ~/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer .

Now to Cabbage . . . The program Projucer is used by the Cabbage build script several times. As far as I know, it writes a directory full of stuff at BB/JuceLibraryCode/ deleting what was initially there before writing files and directories. The Cabbage tarball contains files and directories in BB/JuceLibraryCode/ but as far as I know, these are overwritten in the build process.

The Cabbage build script for Linux is: BB/Builds/LinuxMakefile/buildCabbage. (I don’t know how to point to this file for 2.0.02 on GitHub. Here is the current version: https://github.com/rorywalsh/cabbage/blob/master/Builds/LinuxMakefile/buildCabbage, which is already very different from the version I am working with.) I made a copy so I could easily compare it with the modified copy I am about to make. (I use Beyond Compare for such comparisons, and FileLocator Pro, AKA Agent Ransack, for searching for items in directories full of text files.)

There are 5 instances of using a relative path to specify the location of Projucer:

../../../JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer

I changed these to an absolute path:

~/JUCE/extras/Projucer/Builds/LinuxMakefile/build/Projucer

The first one doesn’t matter, since it only runs if we use an argument “debug” after the Projucer command, which we don’t , but I changed it anyway.

I did not attempt to fix a problem with line 14 which generates an error “./buildCabbage: line 14: [: ==: unary operator expected” if the script is run without any argument. This error can be ignored.

Next I made some changes to these 5 files, for reasons explained in the message 9 above, point 2:

BB/CabbageIDE.jucer
BB/CabbageLite.jucer
BB/CabbagePlugin.jucer
BB/CabbagePluginMIDIEffect.jucer
BB/CabbagePluginSynth.jucer

The MIDIEffect one is not referred to in the build script, but I updated it anyway. In the MODULES section at the end, every line should end with "useGlobalPath=“1"”. Some of them already have such an item, but set to 0. So

<MODULE id="juce_core" showAllCode="1" useLocalCopy="1" useGlobalPath="0"/>  

is changed to:

<MODULE id="juce_core" showAllCode="1" useLocalCopy="1" useGlobalPath="1"/>  

In order to keep the last line of buildCabbage happy, it is also necessary to create a directory, if none existed:

~.local/share/applications

Now, cd to the BB/Builds/LinuxMakefile/ directory, pray to the relevant deities and give the command:

./buildCabbage

This took a few minutes. The only compiler messages were warnings concerned deprecated declarations in CabbageToolbarFactory.cpp.

There was an error resulting from the last part of buildCabbage which normally (at least it worked for me with Csound 6.10.0) resulted in the creation of a little executable BB/Builds/LinuxMakefile/testCsoundFile. The problem "undefined reference to csoundGetInputName" results from something NQR around line 911 in the 6.11.0 /include/csound.hpp which was not in the 6.10.0 version. Cabbage does not rely on this executable.

Testing Cabbage

Apart from the a file ~/.local/share/applications/cabbage.desktop the results are all in /Builds/LinuxMakefile/CabbageBuild/ :

Cabbage
CabbageLite
CabbagePluginEffect.so
CabbagePluginSynth.so
cabbage.desktop
cabbage.png
opcodes.txt  

The first two are X applications. The next two are libraries for these. opcodes.txt is Csound’s list of opcodes. There’s no installation of executables or libraries. From an xterm I was running via the Xfce desktop. via XDMCP on my Windows machine, and from the CabbageBuild directory I gave the command:

./Cabbage

and the program appeared and ran correctly. In the xterm session in which I gave this command, some errors appeared, including:

Xlib:  extension "MIT-SHM" missing on display "localhost:12.0".

as was the case when I ran it from an SSH session and X forwarding (messages above). However, unlike those situation, now there is no trouble at all with the menus not operating, or with any other apparently faulty behavior or delays.

With hyperthreading turned off, and the new governor arrangement, when a .csd file is loaded, Cabbage reports correctly a clock speed of 3059MHz. (Actually, in general, clock speeds can vary between cores, and vary from one time to another - but will all be at the same speed with the new governor arrangement, unless perhaps the cores get too hot.) Cabbage also reports “18 cores”. This should be “logical-processors” on a Xeon or i7. The number is incorrect. The active logical-processors can be found by scrutinising the output of cpufreq-info. This reports on “CPUs” 0 to 17, but those numbered 6 to 11 have no line such as: “CPUs which run at the same hardware frequency: 12”. So this is a difficult way of seeing how many are active. htop shows the number of active logical-processors clearly, an numbers them 1 to 12 or 0 to 11. A script, here with its middle cut out to save space:

#!/bin/bash
cat /sys/devices/system/cpu/cpu0/online
cat /sys/devices/system/cpu/cpu1/online
. . .
cat /sys/devices/system/cpu/cpu22/online
cat /sys/devices/system/cpu/cpu23/online

shows the active ones as “1”:

1
1
1
1
1
0
0
0
0
0
0
1
1
1
1
1
1
0
0
0
0
0
0

I was able to run MultiReverb.csd at 48kHz with a UCA222 interface, but needed a very long buffer of 1920 samples to avoid glitches. This was true both before and after I did the above realtime scheduling steps, so perhaps I didn’t get them right. I have not yet installed Ardour, and in previous tests in which I could run the UCA222 with much lower buffer sizes, I had already installed Ardour. Next I will try a PCI RME sound card and Ardour.