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.

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!

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!

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.

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.

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 http://www.rawmaterialsoftware.com/juce.php 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.

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 http://fyre.navi.cx/ 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.

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.