Running an e-GPU on Fedora 32

I recently bought a new GPU and external enclosure so I can get a reasonable speed when doing blender stuff. Getting it to run under Fedora 32 is a challenge for a number of reasons.

My first challenge was to actually get the external screen to work. There is an excellent tool for this here: which will allow you configure which GPU you want to use when the e-GPU is connect or disconnected.

Secondly, Fedora 32 comes with GCC 10 as standard. There is no prior version in the repo to revert to. CUDA however will not compile under version 10 and requires GCC 9 or less.

There are a couple of ways to get a GCC <= 9 compiler running under Fedora 32. Firstly there is a scripted build process here:, but I found that I couldn’t get the toolset to compile on my laptop with 16Gb of RAM. Another alternative, and the one that succeeded for me was to download and force install a copy of the Centos devtoolset-9. This installs a standalone GCC 9 version under /opt/rh/devtoolset-9, with a script to set up all your environment variables to make this the working compiler.

You will need to download and install five RPM’s from the Centos repository, and then manually install one other library that is a dependency that is not satisfied by any of the RPM’s.

Download the following RPM files from the Centos 7 repository:


And one additional RPM:


Now we can do an RPM install of the devtoolset-9 files. The “nodeps” parameter tells rpm to ignore any unmet dependencies – in this case the libmpfr libraries that we will manually copy in the next step.

sudo rpm -i --nodeps ./devtoolset-9-gcc-9.3.1-2.el7.x86_64.rpm \
./devtoolset-9-gcc-c++-9.3.1-2.el7.x86_64.rpm \
./devtoolset-9-libstdc++-devel-9.3.1-2.el7.x86_64.rpm \
./devtoolset-9-runtime-9.1-0.el7.x86_64.rpm \

For the mpfr RPM file, we will need to extract it to a local folder and manually copy over the library files.

# extract the contents of the rpm
rpm2cpio ./mpfr-3.1.1-4.el7.x86_64.rpm | cpio -idmv

# now copy the libraries over:
sudo cp usr/lib64/* /opt/rh/devtoolset-9/root/lib64/

This completes the installation. To use this compiler from your bash prompt, you will need to set you PATH and various library paths to point to it. This can be done by calling the /opt/rh/devtoolset-9/enable script.

source /opt/rh/devtoolset-9/enable

You can test this by running gcc –version

$ gcc --version
gcc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

$ source /opt/rh/devtoolset-9/enable

$ gcc --version
gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

In my case, the next step was to run blender from within that shell script, and start a render (F12). Blender will successfully compile the CUDA libraries and you should get a fast render. Make sure you have enabled your GPU in the Preferences and that cycles is set to use the GPU as it’s rendering engine.

Have Fun!


I’ve been trying to avoid using a CAPTCHA authentication on posts to keep posting as simple as possible. In the same vein, I also don’t make the email address mandatory – if people want to post a random anonymous comment they are welcome.

However after dealing with a continual flood of offers for various drugs, loans etc, I’ve reluctantly added a simple mathematical CAPTCHA variant, and shouldn’t be too difficult to complete – much easier than trying to decode a very warped image of a word I think.

Kurzweil Pro 1200 Continuing Development

Still battling away to develop this, keep getting distracted by the rather unfortunate need to work at a real job during the day…

I’m now focussing on getting all the master parameters accessible. The Global Parameter screen is mostly functional now as a display of the current status. I still need to add code to get the parameter values applied back to the underlying objects and to then save this back as a sysex command to the Kurzweil Synth.

Progress update on the Kurzweil 1200 Pro software tool

I’ve been intermittently working on my utility program to manage the Kurzweil 1200 Pro synthesizer rack and finally have a bit more to show off. I’ve been struggling to get the basic navigation between menu items working smoothly.

In C++ there is a condition that sometimes occurs when one class is accessing another class, but that other class already uses the first class – it’s known as a circular reference. Unfortunately, I seem to have a lot of this occurring in my program. This is normally a sign of a bad programming architecture and I have been re-factoring as much as I can to separate my presentation and processing logic. I’ve reduced it a lot, and at least the program can function as I intended without too many “forward declarations”. Now that the overall flow is functional, I can start to build out all the extra features. Watch this space!

The CME UF-8 Keyboard

This weekend I happened across someone selling an old CME UF-8 MIDI Keyboard. The unit was described as functional with a few broken keys, and the guy wanted $100 for it. I decided to take a chance, and bought the keyboard. It’s a heavy beast, weighing in at 30Kg, and is a full 88 key keyboard. It sports a true weighted hammer action, meaning it attempts to emulate a true grand piano keyboards action. The broken keys consisted of one white key that sat well below all the others and appeared truly broken, and many of the black keys did not return correctly. The black key problem seemed related to a shaft that connected them all as the keys all moved up or down together.

After stripping the unit down completely, I found the black key problem was indeed related to a common shaft, with each octave all being connected to a single shaft. For some strange reason, only the black keys seemed affected. There seemed to be two types of problem, both caused by the plastic part of the metal hammers. With some keys, the plastic had expanded width-ways slightly and now the fit into the housing case was too snug causing it to stick. In other cases the expansion had made the hole that the shaft feeds through a bit too small, again causing the hammer to stick. I cleaned each octave, and filed and drilled as appropriate to ensure all the keys swung freely in each octave rack, and reassembled them all. I also managed to fix the one white key that had a small retaining clip broken off – I added a small screw instead.

So after a days work and $100 I now have a good hammer action keyboard to add to my equipment list. All that remains is to learn how to actually play a piano!


The day the music died!

Yesterday while developing my C++ program for the Kurzweil 1200 synth, it stopped responding – in a really bad way, no display, no lights on, nothing. I’d heard it click the relay a few times before and sort of hoped it was nothing and it would just go away if I ignored it.

If I left it for a while it would power backup for a few seconds and then die again. So I took the unit out of my rack, opened it up and had a good poke around. I eventually managed to simulate the problem by wiggling the power cable between the transformer and the power supply circuit. I took the board out to have a closer look and found a really bad set of dry joints on the power header. I resoldered them all back up, and a couple more I found on some capacitors. Thankfully this seems to have done the trick and it is now running really well, with no intermittent clicks or anything.

Kurzweil 1200 – Ongoing efforts

I’m making great progress on my application to control my 1200 Pro 1 unit. I can now send and receive a full list of all items available in the unit – LFO parameters, Sounds, Programs etc.

It took me a whole day just to figure out the chksum formula, once I’d got it working, and reread the explanation it was pretty simple:

for(count = 0; count < len; count++)
chksum = ((chksum << 1) | (chksum >> 15)) + msg[count];

It was the rotation part that I had misunderstood.

Another thing I learned today was “strict weak ordering” this is required for the sort algorithm in the C++ STL template libraries. C++ is very fussy about how you write a compare routine for the sort function. I had taken a shortcut in my code by using a flag for the sort direction (ascending or descending). After I had resolved if A was less than B, I used the direction flag to invert the logic at the end. The problem with this arises when you have comparisons where A < B is not an exact inversion of B < A. This occurs when A and B are the same, in this situation A < B is false, and B < A is also false. By doing the comparison in one way only, and inverting the logic at the end I don’t return the same answer. This has a major effect on the sort routine, causing it to start submitting random memory locations to the compare routine causing a seg fault.

Kurzweil 1200 Pro 1

I just recently acquired an old Kurzweil 1200 Pro 1 synthesizer. I’ve had to replace the LCD screen as the electro-luminescent backlighting on the old one was pretty faded. I put in a new LED backlit one, and had to cut down the screw posts to fit the deeper profile in, and added a small pot inline to set the contrast. It’s now very clear, and the unit sounds pretty sweet – (in a sort of 90’s synth way).

I’m now starting to get to grips with all it’s many features, and am developing a MIDI application to control the unit as I go along, so far I’ve got full front panel control and display working. Next step is to get full control of all the many synth parameters and layer settings.

The application is being developed in Linux using the excellent Juce class library – see for an overview. The beauty of the Juce libraries is that they can be easily recompiled to target Windows and Mac (and iOS/Android too but I’m not familiar with those areas yet). It’s main strength is it’s good support for music devices, both MIDI and audio. This extends to developing VST applications too.

Fiery Graphics!

If anyone is impressed (or even just interested), by the swirly graphic images I use in some of my banners, then I’d recommend you head over to and take a look at the Fyre fractal program. It allows you to generate an almost infinite range of random graphics. This is free software, and I think it’s Linux and Windows capable – I’m running Linux, and it works great here.

Take a look at their banner page and you’ll get a quick idea of what it’s capable of.

Tally Light Update

I’ve been doing some work for the Perth Linux user group – PLUG for their AV project. I’ve added a Tally Light page to document the process of how I designed them – please take a look and let me know what you think. The article is here: Tally Light.

The whole project is going to be run as an open source effort, so I’ll be publishing the circuit design, all the AVR source code, and any supporting scripts we need.