Things are getting very busy over here in Perth, Western Australia. The preparations for the linux.conf.au conference next year are really ramping up. Swag is being chosen, Sponsors sought, Speakers invited, Venues organised and a lot more. We’ll be seeking volunteers soon, and opening registrations too. It’s all getting pretty hectic now.
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 focusing 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.
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!
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!
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 sortalgorithm in the C++ STL template libraries. C++ is very fussy about how you write acompare 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 Aand 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 recently acquired a rack mount synth engine. The Kurzweil 1200 Pro 1. This is a late 80′s synth, sold as both a full keyboard and as a rack mount unit. My initial impression was that this unit is a basic sampler engine with a couple of hundred sounds available.
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 80′s synth way).
After reading the manual and doing a bit more research, I have discovered that this is a really deep synth engine and offers a lot of control over the various sound parameters. I’ve trawled the internet, and have located some developer documentation on the MIDI sysex programming interface.
There is a Windows program, Kurlewin that provides limited access to the system, but this is not comprehensive enough, and does not run under Linux, so I’ve set out to develop my own application for this.
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.
Origins of the de Kock coat of arms
The de Kock family arrived in South Africa around 1707. Servaas de Kock was the first to arrive from Middelburg in Zeeland, and in 1713 he married Susan van Boven, and had eight children.
The heraldic term or blazon for the de Kock coat of arms is ” Gules, three pallets vair; upon a chief or a mullet of six points dexter “ which literally translated is:
- Gules is the colour red.
- Three Pallets means three bands down the shield.
- vair is one of the furs, which are forms of patterning in argent (Silver or White) and azure (blue).
- A chief or is an or (gold or yellow) band across the top of the shield.
- A mullet of six points is a six pointed star.
- dexter means align the mullet to the right. The left and right are based on the perspective of the bearer, and so are reversed for the viewer.
The original coat of arms that I had always assumed to be the correct de Kock one was copied from a brass ashtray that had the coat of arms on it. It was from a series depicting the coats of arms of South African families. However after doing some research, and with a lot of wise advice from Mike Oettle, I have subsequently found it to contain a lot of errors.
The main errors on it are as detailed below:
- The proportions are wrong, the Helmet and Shield should be in real life proportion, in this version, the helmet is way to small in relation to the shield. Also, the chief (The yellow bar at the top of the shield) is supposed to be about one fifth of the overall size of the shield.
- The pallets are of the wrong proportion, and are rendered as silver escutcheons (shields) rather than the vair pattern. Also the silver bits around the vair are just plain wrong.
- The Mantling (The cloths draping down the sides of the shield) come down too much and are of the wrong colours. They should be in the same colours as the Torse (The cloth bit between the lion and the helmet). Both the Torse, and the Mantling should be in a contrast of Metal/Tincture (Colour) and should be in the primary metal and tincture. In this case, the primary colour is most likely Gules (Red) as the blazon states that. The Metal can be either the Or (Gold/Yellow) of the chief or the Argent (Silver/White) from the vair pallets. I have opted to use Or.
- Lastly, the mullet (Star) is probably not correct for our particular branch of the family, but I have left it in for now, as this is the one shown in Die Groot Afrikaanse Familienaamboek.
The image shown in Die Groot Afrikaanse Familienaamboek differs quite a bit, but retains the same basic layout. The main discrepancy here is the use of Sable (Black) and Or (Gold/Yellow) for the Torse and mantling.
In the original copy from the ashtray, I have seen, the mullet (star) was depicted as a five pointed argent (silver/white) star. This is incorrect, as the description according to Cor Pama in Die Groot Afrikaanse Familienaamboek clearly states that it is six pointed, and it is illegal in heraldry to have a metal on a metal. Further, the derivation of the coat of arms from the original Chatillon family all use sable (black) for the charges on the chief.
Special thanks to Mike Oettle at the South Africana Armoria Site – de Kock for all the research he has on his web site and for the advice he has offered.
Using GPL open source tools to design and develop a complete hardware/software project.
The PLUG AV Team use a Linux video setup with multiple cameras to record and stream all PLUG organized meetings and talks. When multiple cameras are being used, it is useful for both the recording team, and the people giving a presentation to be aware which camera is currently “live”. This is normally done by activating a red light over the selected camera. This is known as a “Tally Light”.
The software used by the PLUG AV Team to capture the video camera streams is capable of sending a message when a camera is selected or deselected. This is traditionally used to power a red LED using the DTR signal on an RS232 serial interface. As RS232 ports are now obsolete and are becoming increasingly rare it was felt that a better solution could be developed.
Once it was decided to redesign the Tally Light, I defined a few key principals to guide the design.
- It must be developed using GPL open source tools.
- It must work “out of the box”.
- It should be extensible.
- The final product will be GPL licensed.
Based on the above principals, and guided by my own experiences I decided to base the circuit on an Atmel AVR Tiny microcontroller (http://www.atmel.com/ ), and to use a GPL’ed software implementation of the USB protocol (http://www.obdev.at/products/vusb/index.html ).
All circuit design work will be done using gEDA, the GPL Electronic Design Automationsuite. (http://www.geda-project.org/ ) in particular gschem, pcb, and gerbv.
The Atmel range of microcontrollers are all fully supported under Linux using the avr version of gcc – avr-gcc, and can be programmed using the avrdude tool. Additionally, theeclipse IDE has an add on to ease AVR development and firmware uploading.
To support an extensible architecture that could be used “out of the box”, I opted to use MIDI as the underlying protocol. MIDI (Musical Instrument Digital Interface) is a protocol originally designed to allow musical instruments to interact electronically and for computers to generate music that could be shared between different MIDI playing and recording devices. As MIDI has grown in popularity, so too has it’s range of applications, and the MIDI protocol is very well supported in Linux as part of the ALSA sound architecture.
MIDI is now commonly used to provide an abstraction layer between hardware control devices and software applications, and the dvswitch application that the PLUG AV team use is also starting to develop support for MIDI to extend it’s own internal controls so this seems like an obvious fit.
The current Tally Light device only requires a simple light on/light off protocol, so it was decided to use the MIDI Note On/Off message type to control the unit. The first available light on each device will be set to use the note on command for the Middle C musical note. Initially all Tally Light devices will listen to MIDI channel 1.
Update: I now understand that the dvswitch project is implementing OSC (Open Sound Control) in their software. I’ll continue using MIDI until this is stable, and we can be sure the OSC support will translate to our needs, and will still provide an “out of the box” solution.
The circuit design has been done using gschem this is part of the gEDA suite mentioned above. Using gschem allows you to design an electronic circuit by combining electronic components from a library with a network (actually several networks) of interconnections. Additionally, each component has a set of attributes associated with them. Some of these attributes are used to add text descriptions to the diagram, such as the component number, it’s name and optionally it’s value. There is also another important attribute – the footprint – which is a necessary part of the next step – designing the pcb layout. We’ll come back to this at a later stage when we look at the pcb design process.