Guitar FXBOX – Part 1, the software

I haven’t blogged about the guitar before, although this is the conventional instrument I play.  There are enough places on the web to find descriptions of commercially produced effects – of which there are many thousands – and, with possibly one or two exceptions, I won’t be writing about these.

However, I thought it might be worth describing some which I’ve been using which were written using PureData and which together I’ve called the ‘FXBOX’.  Some of the effects I’ve bought have cost £100 – £200, but for no extra expense other than a computer – which I assume you must have, as you’re reading this – and a little know-how, all these effects and more are available.

I have to say, I didn’t write the majority of these effects myself. The know-how has come from examples in tutorials or instructions for PureData, like this one: http://en.flossmanuals.net/PureData/ or this one: http://pd-tutorial.com/ or from the PureData forum at http://puredata.hurleur.com/.

A particular inspiration was Pierre Massat’s ‘Guitar Extended’ blog. Pierre has developed a sophisticated system using an Arduino and a Raspberry Pi to make and control the sound of the guitar, which you can read about in detail here: http://guitarextended.wordpress.com/.

In my case, there were a small number of particular effects I wanted to combine in a single unit, and my good fortune was to find this Spectral Delay patch by Pierre Massat (from an original by Frank Barnecht, based, in turn on work by Johannes Kreidler, whose tutorial is referenced above): http://guitarextended.wordpress.com/2012/02/07/spectral-delay-effect-for-guitar-with-pure-data/

This became the central element of the FXBOX project. What is does is to give different delay times to different harmonics of the input, producing an effect which Pierre likens to ‘hundreds of sparks or stars that fall like raindrops or broken crystal’ – a poetic, but apt description.

More conventional echo effects are also available from this patch.

In the FXBOX I put a couple of conventional effects before the Spectral Delay, namely Chorus and Distortion, and a variable attack patch; at the end of the chain I added patches for panning and stereo imaging.

The two interesting effects which remain are a pitch controller – the normal guitar input can be raised or lowered by up to an octave – and an unusual ‘freeze’ effect, which can produce either a static drone or a very odd series of pitches in response to the input.

This screenshot of the main page shows the various effects and their controls:

I’m very grateful to Pierre and others for making their patches available for everyone to use. One or two people whose patches came from posts on the Pd forum, I know only from their online names: ‘ralf’ for the Freeze function [http://puredata.hurleur.com/sujet-6100-fft-freeze-help], and ‘dack’ for the Pitch Shifter from his ‘Guitar multi-effects rig’ [http://puredata.hurleur.com/sujet-2525-guitar-multi-effects-rig].

The various patches which are required to make the FXBOX work are here:

http://homepage.ntlworld.com/andymurkin/Electronica/FXBOX

All the variable controls are available on the screen, but I decided for practical performance purposes it would be best to have presets which could be selected quickly.

In addition, after starting to use the FXBOX, I rapidly came to the conclusion that it needed a controller which was easier to use than the laptop trackpad. For one thing, you can’t adjust a setting manually and still keep playing.

So I set about designing a controller which would also be compatible with PureData. Some controls might practically be operated by hand, but essentially this would have to be a foot controller with buttons and pedals for the various presets, and for adjusting settings which might need to be changed while playing.

The second part of this post describes the controller.

The Black Widow MkII and more on sample manipulation

I recently came to use the Black Widow sample manipulator again and decided to make some improvements to it.

Initially, I improved some of the existing features: what I had at first perceived as ‘unreliability’ in its responses to button commands was really only a difficulty in making the required number of presses to ‘fix’ volume, filter or pan settings on a sample.  This involves making one, two or three quick presses on the hatswitch button – like making a single, double or triple mouse-click reliably – not perhaps one of my best ideas, and a little difficult to execute, especially without any feedback as to whether the fix had been made or not.  So I added indicators to show if the fixes were on or off.

I then moved the sample arrays onto the same page, so there was no need – as there had been in the original – to move from page to page on screen to see what was happening with the samples being played.  This screen also now has the various indicators for volume, filter, playing position within the sample, etc., visible next to the representation of the waveform in the array:

Above each array are also indicators ‘REVERB ON/REVERB OFF’ and ‘ECHO ON/ECHO OFF’.  I thought simple versions of these two effects would be useful, and added them to each of the output stages.  Having run out of buttons on the Black Widow, these effects are manually turned on and off by using the ‘W’ and ‘E’ keys on the computer keyboard.  (Although ‘E’ makes sense for echo, ‘W’ doesn’t for reverb, but I chose these two letters so as not to conflict with another program I commonly use, where ‘R’ and ‘V’ have particular functions; and ‘W’ happens to be next to ‘E’).

Also, on the right-hand side, indicators for ‘Auto Speed’ and ‘Number of sections done’ refer to the next change I made: a function to allow the Black Widow program to run automatically.  It’s designed to do this in a similar way to the way it’s operated manually: one sample at a time is operated on, and there are built-in delays between stages to allow a particular selected combination of settings to play for a while before being changed.

The particular settings are chosen by random numbers generated by the program.  In normal operation this will allow them to range between minimum and maximum values in each case.  In the event that this wide range is not required (for example, turning the  filter to minimum usually has the effect of turning the sound off, as does turning the playback speed to zero), there is now a page on which minimum and maximum values can be set for each parameter of each sample:

It’s possible here to fix any parameter, so it cannot be changed during ‘auto’ mode; and to fix any sample to play back at normal speed, full volume, average filter setting and centre panned.

Finally, I added a third section in which samples can be recorded into the arrays, rather than loaded from existing sound files.  This could be useful for variety in a ‘live performance’ in which short samples (90 seconds is PureData’s default maximum) could be recorded and almost immediately loaded and manipulated, manually or automatically.

The screen that opens automatically when the app is run has had to be expanded, and now looks like this:

It looks a bit complicated, but I haven’t mastered the method of producing a neat GUI; however, it works fine, and is easy to use if the numbered steps are followed.

The PureData file on which the app is based is here.

It’s perhaps worth mentioning here, as I haven’t done so anywhere else, a very handy little device I used, not wanting to have a full-sized keyboard in the way when I was trying to use the Black Widow controller.  This is the so-called iPazzport, a miniature keyboard and trackpad, which connects to the computer by USB.  It looks like this:

If you imagine that the trackpad is slightly smaller than the trackpad on a laptop, this gives you an idea of just how tiny the keys are – but I was still able to press the correct key when required.  In case of difficulty it comes with a stylus and a small attachment which fits on the end of the finger, with a point underneath it.

Mine was about £10 off eBay, but I don’t know how readily available they are now: the one you see these days is a wireless version which costs a bit more, between £15 and £20.  There are now some similar items – also wireless – styled rather more like TV remote controls, which look as if they might have larger keys.

Also worth mentioning here, if you’re interested in this kind of thing, is the work of Karlheinz Essl.  You can read about him here: http://en.wikipedia.org/wiki/Karlheinz_Essl_junior and on his website at http://www.essl.at/.

Of particular relevance in relation to the Black Widow project is one of the various programs Essl has created for sample manipulation, fLOW, which is described like this: ‘fLOW . . . generates an ever-changing and never repeating soundscape in real time that fills the space with flooding sounds that resemble – metaphorically – the timbres of water, fire, earth, and air. This ambient sound scape generator adjusts itself through various parameters and controllers that are represented in real time on your screen.’  It comes with four samples, which are are loaded and manipulated automatically via a comb filter, ring modulation, frequency shift and a flanger, but you can also load your own samples into it for a more personalised experience.

You can read about fLOW and download it from http://www.essl.at/works/flow/download.html.  I don’t remember how much it costs, but it isn’t very much, and well worth the money.

It’s well worth reading more about Essl, too.  His main preoccupation is one that I’ve become interested in in recent years: ’music that is created at the moment of its sounding (“realtime composition”)’. Improvisation, looping and manipulation of sound and music samples are all part of the same field, and chance can play a significant role.  In a later post I’ll be mentioning another his programs, REplay PLAYer (found at http://www.essl.at/works/replay.html), a multi-featured program for manipulating a single sound sample.

Finally, a very nice freeware program with similar features which I’ve used is Sineqube’s Sapling, which is described here: http://www.sineqube.com/blog/?page_id=157.  Sapling provides an easy means to load 4 samples and vary – manually or automatically – the speed and volume of playback, and the length of a loop created within each sample.  It works well with short samples and allows a very useful combination of automatic and manual adjustments to be made in real time as the samples are played, and a facility for recording the output to disk.

With all of these programs, including the Black Widow in Auto Mode, I enjoy setting up the conditions and listening to the samples play, although for a more permanent record of what was created, I normally edit the recorded results.

[Edit: more modifications have been made to the Black Widow (although not for sample manipulation). See this post].

The Black Widow – Sample Manipulator

I was lucky enough to get a decent joystick for a good price from eBay, a Speedlink ‘Black Widow’:

Obviously, this is a bit more sophisticated than the controller with small joysticks which I used for the StyloSim, and the kind of thing used for semi-realistic flight control programs, having a throttle on the left-hand side and joystick on the right, and a nice feel to it.

As for musical applications, it connects to a computer via USB, as can be seen in the photo, so is very suitable for use with PureData’s ‘hid’ (Human Interface Device) function.

I thought at first of designing an instrument, but felt this would be less easy to operate than the Cybersynth or Theresynth, which used gamepad-type controllers.  An effects device like the StyloSim would be possible, but at the moment would seem like going over old ground: something I might come back to later.

Instead, I decided on a device for manipulating samples.  At the time I thought this was an original idea, but I have subsequently discovered someone who does this – in quite a different way, but using the same kind of device: http://www.youtube.com/watch?v=9wdb6-QLnQ0.

That was Johannes Kreidler, a very interesting contemporary German composer making music with cutting edge electronics.  Check out his website at http://www.kreidler-net.de/english/index.html or type ‘Johannes Kreidler’ into YouTube.  Kreidler is also an expert on PureData, as it happens, and wrote the very good tutorial ‘Programming Electronic Music in Pd’, translated into English at http://www.pd-tutorial.com/english/index.html.

So, I used PureData to create a simple device for manipulating samples with the Black Widow.

There are 4 buttons on the front of the Black Widow:

These are used to control up to 4 separate samples: when the Black Widow Pd app is first opened, the buttons are pressed one by one to load the 4 samples; when in use, the throttle, joystick and other controls operate on the sample whose button was last pressed.

As for the other controls, these are: on the left, the throttle, which includes two buttons on the reverse,left and right:

Pressing the left-hand button on the back of the throttle and moving the throttle forward from the central position increases the sample playback speed; moving the throttle backwards from the central position increases the playback speed, but plays the sample backwards.  When the button is released the speed and direction are fixed.  Pressing the right-hand button on the back of the throttle toggles the playback direction.

Moving the joystick to the left pans the sample to the left; moving it to the right pans it to the right.  Moving the joystick forward from the central position increases the playback volume; moving it backwards from the central position increases the centre frequency of a bandpass filter.

The other buttons on the joystick have the following functions:

The button F3, when pressed as the sample is playing, sets the start point of a section within the sample; F4 sets the end point.

The hatswitch has 4 functions: RIGHT cycles playback from the start point to the end point of a section set with the F3 and F4 buttons; DOWN pauses playback; UP Restarts playback; LEFT fixes a volume or filter setting.

F2 restarts playback at normal speed from the beginning of the sample.

This is the control window, in the process of loading a sample:

There are some problems with it: it doesn’t always seem to respond to instructions, particularly the ‘Fix’ command from the hatswitch, don’t quite know why.  Also, the interface isn’t very practical: if you want to look at what you’re doing as well as listen, there are separate windows for each sample which you have to bring to the front.

However, it mostly works as described, and is quite entertaining to play with!  I’ll post a sound file shortly.

[Edit: the Black Widow has been superseded by the Black Widow, MkII, described here].

Jack and the StyloSim

My next programming project was designed as an experiment to see if Pure Data could deal with QWERTY keyboard input, USB input and audio input all at the same time.

I planned to make an audio effects device, using a Stylophone for the audio input, plugged into the laptop’s 3.5mm (1/8″) stereo mic/line in socket; the laptop keyboard; and a nice twin-joystick device I found on eBay.

The joystick device was called ‘USB Simulator’ (‘For Airplan Heli’) and had the model number FS-SM020.  The two joysticks were quite good to use – not the kind you grip in the hand, but bigger than the thumb-operated joysticks you get on a game controller, plus each of the 4 axes had separate adjusters which you could use to fix the centre of the joystick’s range of control.  There were a couple of buttons on the front, which you can see on the bottom right and left, but these proved to be cosmetic only once I opened the case and looked inside.

I couldn’t find out much about this device on the internet, except that it was, as its name implied, normally used for flight simulation – presumably to simulate a radio-control transmitter – and, in fact, it came with a CD, probably containing the simulation program.

The case was quite large, and there would be ample room inside for further circuitry.  I may look at this possibility later, but for the moment I made no alterations to the device, intending just to use the two joysticks: a bandpass (‘wah wah’-type) filter and volume for the left one, and a binaural panning control for the right one.

The first problem to be overcome was to make sure the audio input from the Stylophone couldn’t be heard, only the output from Pure Data, which would hopefully be the audio input modulated by the joystick effects.  This was achieved by the simple-to-use and very handy audio-routing program Jack.

Jack works by running an app called JackPilot.  When opened this presents a small window like this:

Actually, the top button on the left reads ‘Start’ when opened, but I took this screenshot after clicking it and starting the Jack server.  The normal procedure is to open Jack, start all the programs involved in your routing scheme, then click ‘Start’, and then, when it’s ready, ‘Routing’.  (Just occasionally, you may have to start some audio running through a program before Jack recognises it, but mostly that isn’t necessary).

The Routing window looks like this:

All the inputs are in the left-hand column, all the outputs on the right; it always shows the System audio in and out.  In this instance I was just practising, so I only used Pure Data, but I would frequently have Logic running, too.  To set the route, click on all the inputs and outputs in turn (they are shown in red when being edited), and click on the item(s) you want them to be connected to before moving on to the next one.

At the beginning of the Pure Data program I put the ‘Print’ and ‘Open’ instructions, as I did for the Theresynth and Cybersynth (see previous posts):

This configuration enabled me, once I’d plugged in the Stylophone (audio input) and Simulator (USB input),to check the Device number of the Simulator and open the Device so the ‘hid’ object would receive and deal with the output from the two joysticks.  When I clicked the ‘Print’ message box at the top, the following was printed in the Pure Data window, telling me that the Device Number was ’0′:

(It also gave the Device’s name ‘FS-SM020′, which it hadn’t done with the particular game controller I used for the Theresynth and Cybersynth).

As the Device number was 0, I amended the ‘Open’ box to show this number, and clicked it.  Then I clicked the ‘Print’ message box at the top again, and it showed me the controls it could recognise:

The 4 axes of the joysticks can be seen (‘abs_x’, ‘abs_y’, ‘abs_z’ and abs_rx’, I think, and I can’t remember if any input was recognised from ‘abs_ry) – and also 3 buttons, but the button function hadn’t been implemented in this device.

I clicked the on/off toggle switch, applied the stylus to the Stylophone keyboard, and sounds issued forth – a very good sign!

The Pure Data StyloSim program had three inputs:

On the left is the ‘key’ object, which receives input from the laptop keyboard.  In the end, I added only the box with ‘== 114′ in it: 114 is the ASCII code for the ‘r’ key, so the program only responds to the letter r, turning a reverb effect on or off.

[Edit: I later changed this to 119, the letter 'W', to avoid conflict with another program that used 'R' for a different function]

In the middle is the audio input, ‘adc~’ (analogue-to-digital converter), which leads to the output stage.

On the right is the ‘hid’ object, receiving input from the 4 axes of the joysticks.  The ‘route’ objects separate the 4 inputs and send them in different directions for their various functions (bandpass filter, volume and binaural panning).

All the effects worked – although the panning was less binaural than left-to-right; I’ve heard better.  This is the complete program, showing the objects I used, and the mathematical calculations required to get it right.

This proved that Pure Data could combine information from the keyboard (or an external USB QWERTY keyboard) and HID to work on an audio signal entering simultaneously.   As  can be seen from the following picture of the set-up in action, I used ‘The Alien’, my first Stylophone modification, as the audio source.

This instrument has a ‘drone’ function, so it’s possible to put the stylus down and operate both joysticks on the Simulator at the same time.  Both the joysticks, incidentally, are centre-sprung, meaning that all values return to the central ones, except the y-axis of the left one – the bandpass filter.  This means the centre-frequency of the filter can be set and left while other parameters are adjusted.

Here’s a sound file illustrating the StyloSim:

It’s more of an example than an actual piece, just to show what the StyloSim does.

It’s slightly edited, but only to make it a bit shorter, otherwise it’s exactly as it sounded when played. There’s no post production effects on it, I just hit the ‘r’ button to turn on the StyloSim’s reverb before I started.

There are three parts: the first part is the Stylophone played with the stylus in the conventional manner; the second part uses The Alien’s ‘drone’ feature and variable pitch and vibrato controls; the third part is played with the ‘feedback’ switch on.

[Edit: more modifications have been made to the StyloSim joystick (although not for this particular use).  See this post].

Cybersynth – the Theresynth improved

After finishing the Theresynth (http://andymurkin.wordpress.com/2012/01/11/the-theresynth/) I thought of a way it could be significantly improved.

A little while before, I had experimented with alternative methods of inputting QWERTY keyboard information to the computer, by removing the circuit board and attaching different kinds of switches (See ‘A New Use for USB Keyboards’: http://andymurkin.wordpress.com/2012/01/02/a-new-way-of-usb-input/).  I reasoned that the same might apply to gamepads/game controllers: as long as the USB chip inside was still attached to the USB output, it would still be recognised by Pure Data, no matter what kind of switches were used to control it.

In order to test this theory I bought another game controller of the same type as the Theresynth (A ‘PCLine Rumble Game Pad’), took it to pieces and threw away the buttons it came with, leaving just the joysticks and the USB cable attached to the circuit board.

Just as I had done with the dismantled QWERTY keyboard, I scratched away the surfaces of the tracks where a couple of the switch connections had been, soldered wires to the board and push-button momentary switches to the wires.  I plugged the board into the computer via its USB cable and opened the Theresynth patch in Pure Data.

I followed the steps to set it up, as I described in the Theresynth post, and, sure enough, Pure Data recognised it, just as if it was the game controller, rather than a circuit board hanging off the end of a USB cable; when I pressed the test buttons I had soldered onto the board, the ‘hid’ object recognised them just the same as the buttons on the original gamepad.

Confident that I could operate the Theresynth with any type of enclosure for the circuit board, I considered how I could rehouse it.  An obvious thought struck me: I had recently bought a plastic Cyberman head (if you aren’t a fan of Dr Who, they have their own page in the Wikipedia at http://en.wikipedia.org/wiki/Cyberman) for about 50p from a local charity shop, and it was clear that the eyes were spaced apart almost exactly the same as the distance between the joysticks.  This was a clear sign of what I should do next.

In short, I transplanted the gamepad circuit board into the Cyberman head, with the joysticks in the eye sockets and 12 or 14 buttons round the outside in a vaguely ergonomic layout.  A chance visit to a Poundshop during the course of construction produced a nice USB-powered chain of blue LEDs, and I glued these at stategic points on the inside, producing an eerie glow when the instrument was plugged in.  Another spare USB Type A socket from one of my broken Apple keyboards took the place of the hard-wired output lead, and the Cybersynth was ready for action.

I took the opportunity to make some improvements to the Theresynth patch in Pure Data, adding, amongst other things, a facility to change the starting note from A to any other suitable pitch.  I automated some of the device number/control checks at the beginning, and the switching on of Pure Data’s audio.

The starting window now looked like this:

The Pure Data patch for the Cybersynth is here: http://homepage.ntlworld.com/andymurkin/Electronica/Cyberman5.pd.

This photo guide, which I produced for myself before putting the circuit board inside the head, gives an indication of what the buttons are for, and what functions are included in the patch:

I never figured out quite what to do with the former hatswitch controls.  In the end I stuck the switches on the back of the neck and used them for a sort of trill effect – the top button raises the pitch by a 5th when pressed, the bottom one lowers it by a similar amount.

The Theresynth

I recently blogged about using a gamepad as a drum controller (http://andymurkin.wordpress.com/2012/01/09/drums-with-multicontrol-v0-4/), and this was my next project using a Human Interface Device (HID).

HIDs are the devices we use all the time to interact with computers.  Keyboards, mice, trackpads, trackballs, joysticks, gamepads/joypads/game controllers and graphics tablets are all HIDs, and all can be turned to musical use with the aid of a suitable program to interpret their output.  I chose to start with projects using game controllers because they have a fair number of buttons – and often joysticks – and are designed to fit comfortably in the hand (or hands).

The gamepad I used for the drum controller had just buttons, but the one I used for the Theresynth had two thumb-operated joysticks.  I planned to use one of these for controlling the pitch of an instrument.  In addition, although I had used the pre-made MAX/MSP app ‘MultiControl’ for the drum controller, I planned to use Pure Data and do my own programming.

This was not as reckless at it seems, as programming in Pure Data is done graphically.  Many mathematical and audio functions are pre-programmed for you: all you have to do is draw boxes, write in them what function you want performed, and join the boxes together in sequences.  Easier said than done, as I discovered, but easier, I thought, than writing lines of code.

I have described progamming in Pure Data in my post about creating alternative musical keyboards, using QWERTY keyboards (http://andymurkin.wordpress.com/2012/01/01/alternative-keyboards-4/).  There, ‘key’ was the main Pure Data function used, as this is designed to receive key presses from the QWERTY keyboard; in the application I’m about to describe the special function ‘hid’ was the key to interpreting the output from the game controller.

There are many Pure Data instructional videos on YouTube, and this one in particular: www.youtube.com/watch?v=HB_oVny33wA deals with ‘hid’ and game controllers.

If you’re working on a project like this one, the first thing to do is to allow ‘hid’ to get Pure Data to recognise the game controller.  To do this, plug in the game controller, run Pd-Extended.app, open ‘New’ from the ‘File’ menu and write (or draw, rather) the following into the empty box ‘Untitled-1′.

This is a short program which will show all the connected USB devices which Pure Data can recognise.  The ‘Print’ command is in a ‘message’ box, and is connected to the input of the ‘hid’ object.  Inputs are on the top of object boxes; outputs are on the bottom.  When you click ‘Print’, it sends the message, and gives a reply like this in the Pure Data window:

Each connected device has been given a number.  The first six, ‘Device 0′ to ‘Device 5′ are simply the different elements of my MacBook, keyboard, trackpad, and so on; but the seventh one, Device 6, looks like the important one: ’4-Axis, 12-Button with POV’, ‘device type: joystick’.

Sometimes it will tell you the make and model; in my case, my ‘PC Line Rumble Game Pad’ is identified only by its ‘vendor ID’, 0×0583, and its’ product ID’: 0xa009.

We need to know the Device number, as we’ll use that in the program.  It doesn’t always come up as Device 6, so I always include in my Pure data programs a facility to check this number, and amend it if required.

The next step in writing a Pure Data program based on the ‘hid’ object, is to identify the outputs from the buttons and joysticks  in the controller.  This is done by a couple more additions to the simple program which produced the list of devices:

‘Open 6′ is another message box.  The small square on the left-hand side is an on/off ‘toggle’ switch, which I won’t be using now, but I’ll use it in a minute.

Click ‘Open 6′, and messages from Device 6 are routed to ‘hid’; click the ‘Print’ message box at the top again and the ‘Print’ object at the bottom will produce a list in the Pure Data window of all the buttons and controls in the device:

This shows 12 buttons, (‘btn_0′ to ‘btn_11′), the up-and-down and left-to-right axes of the left-hand joystick (‘abs_x’ and ‘abs_y’), the up-and-down and left-to-right axes of the right-hand joystick (‘abs_rz’ and ‘abs_ry’) and a hatswitch.

Now you know this, you can separate each of the inputs as they come out of ‘hid’ and get them to do various things – make noises (as I did with the gamepad MIDI drum controller), control effects (like filters, for example), and so on.  Other Pure Data objects (boxes like ‘hid’ and ‘print’) can do mathematical transformations along the way.

The way to separate them is in stages.  First of all, look at the left-hand column above.  There are two types of entry here: ‘abs’ and ‘key’.  Using a Pure Data object called ‘route’, we can get the ‘key’ information (from the buttons) to be separated from the ‘abs’ information (from the joysticks and the hatswitch):

Then, looking at the second column, we  can separate out the 4 joystick axes and the 12 buttons:

While I was testing this out just now I did two extra things, which you can see in the screenshot above: firstly I added the small box at the bottom, which is called a ‘bang’.  If everything’s working properly, this will flash on and off when I press the button ‘btn_0′ – which is very likely marked ‘Button 1′ on the game controller – and secondly I clicked the on/off switch (the cross means ‘on’) so that ‘hid’ would recognise and output button presses and joystick movements.

Because the MIDI note number and control system lends itself easily to mathematical manipulation, this  would be a common way to use Pure Data.  In this particular application, however, I decided to use some of its many audio functions.

I’d spent some time modifying stylophones, as you may have read in previous posts.  The thing about stylophones is getting great sounds from them is easy, but getting sinewaves out of them is well-nigh impossible.  In Pure Data, however, it is extremely easy, so I decided to create an instrument which would produce ethereal sinewave sounds, rather like the Theremin.

The Theremin is a wonderful electronic musical instrument, which you play without touching it!  If you don’t know what it is, you can read about it on the Wikipedia at http://en.wikipedia.org/wiki/Theremin.

My plan for the ‘Theresynth’ was less ambitious, but would involve using one of the game controller joysticks (the left one) to control pitch and the other (the right one) to control volume.  In the event, I also added a kind of vibrato (more of a fast auto-pan), controlled by the other axis of the right-hand joystick.  This added a little more depth and interest to the sound.  As well as this, a programming error I made along the way also enabled me to add a second tone to the instrument, which was a kind of frequency modulation/ring modulation – very effective in the lower register.

The exact method by which I achieved this is rather lengthy to explain, and I’ll attach the ‘patch’, as bits of Pure Data programming are called, so you can see, if you want to study it.  In principle, though, it went like this:

The output from the the joysticks is in the form of numbers from 0 to 255.  Divide this in half and you get all the MIDI note numbers (they run from 0 – 127); convert the MIDI numbers to frequencies and use this as the input to an oscillator, feed the oscillator into an output amplifier and you have a simple musical instrument!  All these functions are available in Pure Data.

Using ‘abs_x’ (left-to-right on the left-hand joystick), as I did in the Theresynth, that part of the circuit would look like this:

‘/ 2′ means ‘divide-by-2′; ‘mtof’ means ‘convert MIDI note to frequency’; ‘osc~’ is an oscillator; and ‘dac’, the digital-to-analogue converter sends audio out to the computer’s sound system.  The number 64 is is in a ‘number’ box – it doesn’t do anything, it just tells you what MIDI note is passing from ‘/ 2′ to ‘mtof’.  Useful if you want to check what’s going on.

This program works – I’ve just tested it (but don’t forget to turn ‘audio ON’ from the ‘Media’ menu of Pure Data) – but the problem is that the travel on a gamepad joystick is not that far, and you don’t want to go from the lowest MIDI note possible to the highest in such a short space.  So a lot of what I had to do was to restrict the range of notes available.

In the end, as you’ll be able to see in the finished patch, I did this by dividing again by 10, severely restricting the range of notes available to the joystick at any one time; and then using one of the buttons as a freeze-pitch button, with a very short time-delay to allow the joystick to spring back to the middle.  In this way it’s possible to play a few notes, ending higher or lower than where you started, freeze the pitch there, let the joystick go back to the middle at this new pitch, and gradually move up and down in steps, as required.  After a little practice, this came to seem quite natural.

I never quite got the hang of creating a nice interface for my Pure Data programs, so the window that opens looks like this:

Following these steps gets the Theresynth ready to use.  Steps 1 – 4 just operate the checks I described above: identifying the device number, checking the buttons are all recognised by the program, opening the device and switching on ‘hid’.  Step 5 reminds me to turn the audio on – although in later programs I found out how to do this automatically when the program loads.  Step 6 may or may not be necessary, but clicks some toggle switches on and off to guarantee everything is ready to work, but stays silent.  Step 7 turns up the volume and you hear the initial tone, which is A (440Hz).

The actual programming is visible in two windows, ‘controls’ and ‘oscillators’, which can be opened by clicking the boxes in the bottom right.

In my next post, I’ll describe how I improved this design, but the instrument definitely worked, and seemed to me to be a good use for a second-hand joystick.

Drums with MultiControl v0.4

Here’s a method I used to play a virtual synth drum patch with a cheap (£3 or £4 off eBay) USB game controller and the program MultiControl v0.4.

Here you can see the game controller I used (the type without joysticks), and the MultiControl window.

To set it up, plug in the game controller, open MultiControl and select ‘USB Gamepad’ or similar in the top right of the MultiControl window.  There’s a drop-down list of devices that the program has detected, including the keyboard/mouse/trackpad of your computer, but it should be obvious which one is the game controller you want to use.

MultiControl is a MAX/MSP-based application, and will also open the MAX/MSP Status window.  To start with, this window will probably show you some information relating the keyboard/mouse/trackpad of your computer, but once you’ve selected your game pad at the top, all you need to do is press each button: the program will detect each one and allocate it to a separate line in the MultiControl window.

There’s a video on YouTube explaining how to set up MultiControl, and how to use it.  If you’re intending to do this, it would be good to look at that, here: www.youtube.com/watch?v=I0Z5WpiDQR8

This is the MAX/MSP Status window.  On opening the program, it registered the information in the top half of the window; once I selected ‘USB Gamepad’ it began with ‘hi: focussing on USB Gamepad’ and waited for me to press the buttons; as I did so, it listed them (there are 11 on this device) and allocated them to lines 1-11 in the MultiControl window.

This is a general screen example, not from this Gamepad application, but you can see that the first column, ‘Input’, registers button presses – the shaded bar moves across the box as the button is pressed – and the 7th one, ‘Values’, shows (in the case of this Gamepad application) ’0′ when the button is not pressed (i.e. ‘off’), and ’1′ (i.e. ‘on’) while it’s pressed – except for the hatswitch buttons, which can register 0, 0.5 or 1 at different times.

The 4th column shows each button’s control number, ‘c1′ being line one, ‘c2′ being line 2, and so on.  This information will be useful later on.

The rest of the left-hand side of the MultiControl window is not important for this purpose, but the right-hand side, the MIDI side, is.  To allocate the 11 controls to particular MIDI drums, I had to turn MIDI output on by clicking the small box at the top marked ‘MIDI on’; change the first 11 boxes in the next  column to ‘noteout’ rather than ‘ctlout’; and set the MIDI note number for each in the next column ‘MIDI range’.

You can see this in the instruction video, the range being set by clicking and dragging; but in the video you see a rather vague range being set.  The boxes in the ‘MIDI range’ column are so small that it’s very difficult (well, I found it impossible) to set precise values – it was OK starting from 0 on the left-hand end of the box, actually, but getting the upper value correct was the hard bit.  Unfortunately, this upper value is critical, as it represents the exact MIDI note number of the drum sound you want to make when you press that button.

However, this can easily be got round.  This is because it’s possible, using the ‘Save file’ box at the bottom, to save your settings and then retrieve them later, so you don’t have to input them all again every time you want to use a particular gamepad or other device for a particular purpose.  I used this feature to input the exact values I needed, in the following way:

First of all I worked out which buttons I wanted to operate which drums.  Practising with the virtual synth I intended to use, I noted which drum was which, and which note of the keyboard produced that particular drum sound.  Using my chart of notes and MIDI numbers I listed the 11 buttons and wrote the appropriate MIDI note against each one.

By clicking and dragging from the left hand side to somewhere in the middle of each of the 11 boxes in the ‘MIDI Range’ column, I produced a number in the next column, ‘values’, that was pretty close to the MIDI note number I needed for that particular drum sound when the button was pressed.  In every case I had been able to get it to show 0 when the button was not pressed, which is what was needed.  I then saved the settings file with an appropriate name.  These files have the extension ‘.xml’.

I then opened the .xml file in a text program (e.g. BBEdit).  Apart from some general stuff at the beginning, each button had a long entry between the tags <patcher name => and </patcher>.  They didn’t come out in order from 1-11, but this is the entry for the button described on line one, as you can see from the line near the bottom, which says “text edit” value = “c1″.

You could, I suppose, edit any of the values in here.  I’m not at all certain what they all are, but the one that needs editing in this instance is the 4th line: “X Range” value = “0 51″.  The meaning of this is that pressing the button moves the value output from o (no note) to 51 (D#3 – can’t remember off the top of my head what drum sound that represented in the virtual synth I was using).  If you go through each of the entries and make sure that the first number is 0 and the second one is the MIDI note that button is supposed to output, you can save the file when you’re done, with all the right numbers in it.

Next time you want to use this controller for this application, you can just click ‘Open file’ and ‘Load’, and all your saved settings will appear.

The only remaining thing you need to know is how to set up the inputs and outputs.  MultiController has a window for this, which appears when you choose ‘MIDI Setup . . .’ from the ‘File’ menu.  My notes to myself say to set it up like this:

(Although it seems likely that I meant “to MultiControl 1″ or “to MultiControl 2″  and  “from MultiControl 1″ or “from MultiControl 2″.  If no other MIDI devices are being used at the same time, it almost certainly doesn’t matter).

You might need to use the IAC Driver Bus 1 or 2, depending on the number of MIDI devices you’re using at the same time, but whatever you end up doing, you’ll need to change the ‘MIDI Device’ setting at the bottom of the main MultiControl window, and the input device setting of the synth you’re using, so that they agree.

If you need to change the ‘Audio MIDI Setup’ (on a Mac, at any rate), clicking the ‘System Setup . . .’ button in the bottom left of the MultiControl MIDI Setup window will open that for you, instead of you having to go to ‘System Preferences’.

A new use for USB keyboards

In the course of creating alternative keyboards, and interpreting USB inputs, I had an idea for a project which could prove to be useful.

It occurred to me that the computer was able to recognise the input from QWERTY keyboards because of the chips and circuits inside the body of the keyboard – the actual switches themselves, how they were laid out, what exactly they represented, were irrelevant.  So, if you had access to the circuit board inside the keyboard, and left the USB connection intact, you could do what you liked with the switch connections.

The keys of a QWERTY keyboard are arranged in a matrix – I had no idea how many connections there would be in each axis, and it probably differs from one model of keyboard to another.  But I had an old Apple keyboard I was about to throw out because of sticky keys, and I decided to experiment on this.

Here’s what I did:

First of all, I took it apart, threw away the casing, put the switches to one side, and detached everything from the circuit board, except the USB lead.

As it happens, the circuit board in this keyboard is unusually large – covering the whole width of the keyboard, and with extra USB sockets on each end.  Normally, the mouse would be plugged into one of them – and they aren’t the same: the one with the lead attached is the one that has to be connected to the computer.

The extra USB connectors on the ends of the board would probably be useful later, but more important was the circuit board itself.  Here you could see the two series of tracks for the two different axes of the switch matrix.

In theory, each track in the first series – which I called Series A – would give a different output when connected to each track in the second series – Series B.  There was only one way to find out: I plugged the USB lead in to the computer, opened Word, and got to work with a lead and crocodile clips.

If I remember correctly, I had to scratch off the track surface a little to get a good contact, but starting on the left I clipped the lead to the first track, A1, and progressively touched the other end to B1, B2, and so on, noting in a table what letters or symbols appeared.  When I reached the end of the Series B tracks, I reattached the lead to the second track on the left, A2, and repeated the procedure, touching each of the tracks in Series B and noting the results.

Not all the combinations seemed to work, but eventually I produced the following table:

This list seemed to contain all the letters of the alphabet and all the numbers 0-9, so I considered this a great success!

It seemed to me that tracks 1, 2, 4, 5, 6, 7, 9, 10, 11 and 12 in Series A, and tracks 2, 3, 4 and 11 would be the useful ones – 14 connections giving 40 outputs.  It wouldn’t matter what kind of switches were used to make the connections, their output would be predictable and the ASCII codes they produced could be interpreted reliably by programs such as Pure Data.

All I had at this point was a circuit board with a cable attached to it, so I decided to put it in a permanent box.  I had a suitable one to hand, which it would just fit in, and decided to use this, together with sockets on the rear connected to the 14 tracks.  I gingerly soldered ribbon cables to the two series of tracks, and this photograph of the inside of the box shows how it looks:

You can see the leads from Series A on the left-hand side and the leads from Series B on the right-hand side, leading to a circuit board with PCB connectors.  These are connected to 3 different sockets on the back of the box.

There are 3 sockets because I decided that not every potential application would require the full 40 connections.  There’s a 15 way DB15 HD socket (the type used for VGA) for any application requiring the full 14 connections (10 x 4 matrix covering all the letters A – Z, numbers 0 – 9, and a couple of others); a DB9 socket for applications requiring only 7 or 8 connections (4 x 3 or 4 x 4 matrix, e.g. a numeric keypad); and a 4-pin socket (the type used for S-Video) for an application requiring only 4 connections in a 2 x 2 matrix.

The original circuit board, as described above, had a hard-wired USB out lead and a USB A socket on each end.  As you can see from the above pictures, I took off  the hard-wired output lead and replaced it with one of the sockets from one end of the board.  I know you’re supposed to have USB B, not USB A sockets in this position, but it’s easier to come across USB A to USB A leads, and the functioning is still the same.

The large DB25 socket, and the two 5-pin MIDI sockets on the left are for a future project, not yet finished, for a fully-featured MIDI controller.  I’ll describe this in a later post, when I get round to constructing it.

I also bought a supply of leads, ready for when external switching devices need to be attached.  In some cases this was easier than others.  I chose these formats partly for the availability and inexpensiveness of the leads, but was unaware that the 15-pin HD leads commonly seen are designed for VGA or S-VGA, which don’t have all 15 pins connected one-to-one.  In the end I found the ones I needed, but if you’re doing the same kind of thing, take care.

The final thing to note is the circuit on the left-hand side of this picture:

Although not strictly necessary at this stage, I decided to add this feature while I was working on the box.  The MIDI controller, planned to be in the same enclosure, would need a USB converter in order to be attached to the computer.  The only USB converter I have at the moment might be required in future for another device, so I decided to add a MIDI to USB converter to this box, which the MIDI controller could use if necessary.

I took a chance on a cheap MIDI converter, which was £5 on Amazon.

I had read bad reports of these things, but they’re so cheap compared to the brand name converters, I thought I’d see what they were like.  You can get them for even less than £5, direct from China.  When I got this one, I took the circuit board out of its plastic casing, chopped off the the in/out leads and rewired them to the sockets on the back of the project box.  It was powered via USB, and appeared to work fine with my Sonuus G2M Guitar to MIDI converter, so I took the final step of cutting off the USB lead and attaching the USB output to the spare USB input on the Apple keyboard PCB.  (It was spare because, as mentioned above, I took the socket off to create a new USB output socket instead of the hard-wired lead).

It still worked, so I put the lid back on the box, and called it a day on that project for the time being.  When I get round to creating some alternative switching devices, or start on the MIDI controller, I’ll post something on them.

A brand of keyboard with a smaller PCB would probably be more practical, and any keyboard will do, if you want to try it yourself.  There’s an excellent video on YouTube, here:  www.youtube.com/watch?v=a3NxQ60E72k, which goes through the steps very clearly.

It just so happens that I saw a job lot of broken Apple keyboards for sale like the one I used here and bought them for about £1 each, so I’m stuck with these for future experimentation!  The faults they had were various – sometimes it seemed to be the circuit boards, sometimes it was just the odd key, so all of them looked usable in one way or another.

I may not need the circuit boards – although I could make self-contained instruments if the cases were big enough to hold them – but I have plans for the keying mechanisms, which could be interesting.

Alternative Keyboards 4

After creating the isomorphic alternative keyboard with a Cherry USB QWERTY keyboard and the program MIDI Integrator (see my previous post ‘Alternative Keyboards 3‘), I started to think about the possibility of using two keyboards, like the Jammer.

The Jammer uses MIDI Integrator, but it can do this because it uses two AXiS-49 MIDI keyboards.  It wouldn’t be possible for me do the same with two QWERTY keyboards, for two reasons: a) MIDI Integrator only has the facility for mapping one QWERTY keyboard at a time, and b) MAX/MSP does not recognise alternative key codes with the ‘Shift’ key pressed – i.e. both ‘q’ and ‘Q’ are interpreted the same, even though they have different ASCII codes.  This would mean that however many keyboards you had, they would all output the same notes to the same synthesiser or sound card.

So, I needed to find an alternative program for this application, one that would recognise two QWERTY keyboards, be able to interpret their outputs separately, and potentially route them to two different synths.

A program that will do this is ‘Pure Data’, a relative of MAX/MSP.  Like MIDI Integrator (but unlike MAX/MSP itself) it is free to use, and programming is done graphically.  Full details are on the Pure Data Community site at http://puredata.info/.

A piece of Pure Data programming looks like this:

You create the different types of boxes, write in them the values or functions and sequence them by joining them together with lines.  In the above example, the message box at the top contains the number 60, the MIDI note number for middle C, and a little lower down is a box with the function ‘mtof’, MIDI-to-frequency, which converts the MIDI note number to a frequency measured in Hertz.  There are 4 boxes marked ‘osc~’, which represent sine wave oscillators, mixers (‘*~’) and a graph which will display the complex waveform created by the summing of the 4 sine wave oscillators.

Amongst the many functions available in Pure Data are ‘key’, ‘keyup’ and ‘keyname’, which are designed to accept input from a QWERTY keyboard.  The function ‘key’ accepts and outputs the ASCII key code when a key is pressed, ‘keyup’ does the same when the key is released, and ‘keyname’ tells you the name of the key in use.

Most importantly, Pure Data accepts all ASCII codes, and can therefore distinguish between simple key presses, and key presses + Shift.  This means you can have two whole keyboards-worth of different key numbers, making it worthwhile using two keyboards, with no ASCII code being duplicated in both of them.  As long as the program could be made to understand which numbers belong to which keyboard, it would be possible to treat each keyboard differently, and route their outputs to different MIDI synths.

So what I needed was a) a second Cherry Keyboard, and b) to learn how to program Pure Data to distinguish key presses from one keyboard or the other; divide them into two streams and deal with them separately; and use the ASCII codes received to output appropriate MIDI note numbers.

The second keyboard was easily found on eBay.  It had a PS2 connector, and it was from this experience that I gained the knowledge of PS2 to USB converters which I wrote about in this post: http://andymurkin.wordpress.com/2012/01/01/alternative-keyboards-2/.  It functioned perfectly with the aid of a ‘Blue Cube’.  I also removed the keycaps, cleaned the (second-hand) keyboard, and  painted the keycaps blue.  It wouldn’t matter which keyboard was used for the left hand and which for the right, as they are identical models, but I tend to use the blue one for the left hand and the red one for the right.

They’re set up here for testing purposes only.  Having two separate keyboards for left and right hands means that in practice, they can be placed in a more ergonomically suitable fashion for comfortable playing.

(The eMac they’re connected to is almost worthy of a post of its own.  If you’re a Mac User, and you’ve got room for an old-fashioned CRT-screen desktop, it’s worth considering an eMac: nobody wants them, so they’re very cheap: this one, which was £20 off eBay has the same OS as my laptop – not the latest Mac OS, but a perfectly respectable one; it has firewire as well as USB and Ethernet, and a DVD ROM/CD burner drive.  I’m able to use it as a dedicated MIDI machine, and use the laptop for soft synths and recording.

Upstairs in the Music Room I have 2 iMacs, which are similar in appearance, but slightly smaller.  These aren’t as good as the eMac, and aren’t able to run such a recent OS, but are still able to perform some useful tasks as VST instruments hosts, MIDI control my Behringer V-Amp, and so on – and they were £5 each!)

The USB hub I installed in the Superstylonanphone came in handy at this point: although the eMac has 3 USB connectors, I was beginning to run short, as both of the Cherry keyboards needed to be connected individually, as well as various other devices I was using at the time.

Not shown is a vital piece of equipment required for the blue keyboard, which is a clip to hold the Shift key down.  In order to take advantage of the two keyboards-worth of ASCII numbers recognised by Pure Data, it was necessary to do this – Caps Lock only affects the letter keys, not the others – and I haven’t yet found the best way of doing it.  The next thing I’ll be trying is a drawing board or table cloth clip (it has to be thin and flat on the bottom); but in any event, it’s vital that one of the keyboards outputs the usual numbers and the other one outputs the numbers with the Shift key down.

Turning to the software, the two difficulties would be a) getting the program to distinguish the numbers received by one keyboard from the other, and b) getting it to output the appropriate MIDI note numbers.

The entire program looks like this:

The function called ‘key’ in the top left receives the numbers from the keyboards.  It neither knows nor cares whether these numbers are coming from one keyboard or two.  The function ‘keyname’ is just there for the sake of interest – originally for the sake of testing! – and doesn’t actually contribute to the working of the program (or ‘patch’, as they call it in Pure Data).

The number from the keypress is passed to a very complicated sifting system underneath, the purpose of which is to divide the numbers coming from the red keyboard from the numbers coming from the blue keyboard.

Unfortunately, as I said in the previous post referred to above, there is no simple way of distinguishing the ASCII numbers – they’re pretty random, it seems.  I’ve used a function called ‘moses’.  Like Moses, who parted the Red Sea, this function parts the stream of numbers coming into it: you put a number in the box and it sends this number and any higher numbers out of one output and all the lower numbers out of the other output.  In this way I was able eventually to divide the numbers and send them in the right direction.

In the middle part of the program you can see the two separate streams of note numbers moving from top to bottom; the settings on the right-hand side of the program allocate MIDI channel, velocity, duration and octave information.  At the bottom, the Pure Data functions ‘makenote’ and ‘noteout’ convert all these details to the kind of MIDI signal understood by a synth.  You just need to tell the program where exactly to send these MIDI signals in the program ‘Preferences’.

That just leaves one question: how does the program know how to convert the incoming ASCII numbers to the correct MIDI note numbers?  The answer is in a similar way to MIDI Integrator in the previous post: by means of a pre-written text file.  In the bottom right of the program, there is a list (very incomplete at the moment as it only contains ‘Wicki-Hayden’, ‘Janko’ and ‘System C’, and only ‘Wicki-Hayden’ has so far been implemented!) of layouts which can be used.

When you select the ‘Wicki-Hayden’ option, the instruction at the bottom gets the program to read the text file ‘wicki.txt’ into a table (or array) called ‘notes’; the function ‘tabread notes’ in the middle of the program uses the information in this table to convert the ASCII numbers it receives into the MIDI note numbers you want it to output.

The format of this text file is quite different from the text file in MIDI Integrator.  It looks like this:

On the face of it, pretty meaningless!  The way it works is this: the table is 128 numbers long.  This is because there are 128 possible MIDI note numbers, and why it says in the instructions at the top of the program, in the middle, ‘Open ‘table notes’.  Set array size to 128′.  The button for opening ‘table notes’ is right down near the bottom of the left-hand side of the program window, not right next to this instruction, as you would think it should be.  Don’t ask me why.

So the table is 128 numbers long, and what the program is doing when it receives a number is this: if it receives the number 60, it outputs the number at position 60 in the table; if it receives the number 113, it outputs the number at position 113, and so on.

This is more complicated than the method for MIDI Integrator, but can nevertheless be achieved with a little patience and the correct data to hand.  Here’s what I did:

First of all, as before, I filled out the spreadsheets showing the layout of the keys, the ASCII numbers and the MIDI note numbers (see http://andymurkin.wordpress.com/2012/01/01/alternative-keyboards-3/).  In fact, the sheet for the red keyboard was the same as the one I used in MIDI Integrator, it was the new sheet for the blue keyboard that was different.  To fill this in, I had to change the MIDI note numbers and the ASCII numbers.

In fact, I could have left the MIDI note numbers the same as the red keyboard, but I thought it would be more practical to have them an octave lower, so I entered all the MIDI numbers with 12 deducted from each one – that’s all it takes to lower the notes by one octave.

The ASCII codes had to be changed because the blue keyboard would output the number of the Shifted keys – i.e. ‘Q’ instead of ‘q’, ‘%’ instead of ’5′, etc.  I used this chart to change the numbers on the spreadsheet:

The one obstacle I came up against was the F keys, which don’t have an alternative number when used with the Shift key.  This meant that the blue keyboard was restricted to 4 rows – but as this is more than 40 notes, it wasn’t too much of a limitation.

Here’s how I created the text file:

First of all, the first position in a 128-position table is 0, and the last one is 127.  So I opened a blank text document and wrote a column of numbers down the left-hand side from 0 to 127.  These are the ASCII key numbers.  I then went through the two spreadsheets and for each key I needed to use I wrote down the MIDI number against its ASCII number in the text document.  When I finished, I put ’0′ against every unused ASCII number in the list.

When I had a list of 128 numbers – many of which were now 0 – I removed all the ASCII numbers in the left-hand column, left one space between each remaining MIDI note number, and saved the text file as ‘wicki.txt’.  This file is now read at any time when ‘Wicki-Hayden’ is selected as the layout in the program, and the values don’t need to be entered again.

The patch and the text file are here:

http://homepage.ntlworld.com/andymurkin/Electronica/CherryDouble6.pd
http://homepage.ntlworld.com/andymurkin/Electronica/wicki.txt

Alternative Keyboards 3

In my last post (‘Alternative Keyboards 2‘) I described choosing a suitable QWERTY keyboard as a 2-dimensional ‘isomorphic’ musical keyboard.  In this post I talk about the software I used to interpret the key presses and output MIDI information to the synthesizer (virtual synthesizer, in my case).

The first thing to appreciate is that every key press on a computer keyboard sends a number (its ‘ASCII’ code) to the computer via USB.  Every key has a different number, and the number sent out by the key is different when the Shift key is pressed at the same time.  Knowing this, and knowing which key sends which number means you can tell the computer to do a certain thing with each number it receives – for example to output a MIDI note number.

When you use a MIDI music keyboard the relationship between the number it sends and what you want done with it is very simple: press the note C in the middle of the keyboard, and it will send out the number ‘60’.  MIDI synths recognise 60 as the number for C, and C will be sounded; press C#, the number 61 will be sent, and C# will be sounded; and so on.  Unfortunately, this isn’t the case with the computer keyboard – the numbers sent out by the keys bear no relationship whatsoever to where on the keyboard they are: The ASCII code for Q, expressed as an ordinary decimal number, is 113; W, right next to it, is 119; E is 101, and so on and so forth.

So, in terms of software, if you’re using a QWERTY keyboard, as I was, you’re looking for a program that a) recognises ASCII codes input from a keyboard, and b) has a means of you telling it to do something unique with each different number it receives.  In this application the unique action would simply be to output a specific MIDI note number for every specific key number received.

Having read about Ken Rushton (‘MusicScienceGuy’)’s instrument, the Jammer, at www.altkeyboards.com (and his blog at www.musicscienceguy.com), I decided to use the program MIDI Integrator he had devised to operate it.  MIDI Integrator is described, and can be downloaded here: www.altkeyboards.com/integrator.  It’s free, and works on Macs and Windows PCs.  It’s an application based on MAX/MSP, and I had downloaded and installed the free version of this, ‘Max Runtime’ from http://cycling74.com/downloads/.

MIDI Integrator was designed to be used with the Jammer – and is potentially very useful because of that, as the Jammer has 2 separate MIDI keyboards; but inputs for MIDI keyboards weren’t useful for this application, as the QWERTY keyboard doesn’t output MIDI information.  However, there is another feature of the program that would do the trick.

Setting this up was quite an involved process, but consisted of just a small number of important steps.  Most importantly, when done once, most of these things didn’t have to be done again!

When you open MIDI Integrator, the interface you see looks like this:

All the boxes with a ‘p’ at the beginning are boxes which can be clicked to enter information.  There are lots of boxes here, but I only needed to look at two of them.

What I had to do is ‘map’ the keys of the QWERTY keyboard – i.e. match them to MIDI notes – in the top half of the screen, and route the output to a virtual MIDI instrument in the bottom half – which involved telling the program where to send the MIDI signals to operate a synthesiser or sound module.

So, I began by clicking the box marked ‘p mapPCKeys’.

When I did this, it brought up the window for the QWERTY keyboard, which looks like this:

What this tells you is that the mapping instructions used by MIDI Integrator are in a text file called ‘MidInt PcKeys v1.txt’.  What I had to do is replace the text file ‘MidInt PcKeys v1.txt’ with one of my own, with my choice of notes.

To do this, I clicked on the third button ‘coll MidInt PcKeys v1.txt ‘, under the text ‘Click below to edit mapping table’.  This opened the text file, which looked (in part) like this:

You can see from this example that each line has 5 elements, like this:

56 #8, L N 76.  This is interpreted as follows:

56 is the number (usually ASCII) sent out by the key;
#8 is which key that is (in this case, the number 8 on the second row down of the keyboard);
L is the virtual MIDI instrument in MIDI Integrator to which the information is sent (L, R, Lx and Rx are the choices MIDI Integrator gives us; it doesn’t matter which one you use if there’s only in use at any one time);
N means ‘note’ information is what’s being sent;
76 is the MIDI note number.

So all I had to do was identify the keys on the keyboard I wanted to play notes on, find out the ASCII number of each one, and write a line of code for it like the one above.

The problem is matching the right key number on the left-hand end with the right MIDI note number on the right-hand end, and the MIDI Integrator website made this easy, by providing a chart (an Excel spreadsheet), laid out in the same way as the QWERTY keyboard for me to write this information in.  It already had the key numbers in it, all I had to do was write the MIDI note numbers in next to each key.

Not all of the keys on the keyboard have code numbers that can be used, but it’s only a small number round the edge that won’t work.  I experimented to check exactly which ones could be used, and labelled them or didn’t label them in the spreadsheet, as appropriate.

This chart shows which codes MAX/MSP allocates to which key, mostly based on their ASCII codes:

I made this diagram to show the 5-row note layout for the ‘Wicki-Hayden’ keyboard:

and this one to for the ‘Janko’ keyboard:

I figured that I might as well create several different text files for MIDI Integrator while I was at it, and try out some different layouts.

So I had the keyboard layout spreadsheet and the pattern of notes for my layout (I started with the Wicki-Hayden).  The final piece of information I needed was what MIDI note numbers corresponded to the notes in my layout diagram.

This chart shows the MIDI numbers which correspond with all the notes from C0 (the lowest) to G9 (the highest).  C4 is ‘middle C’.

For mathematical reasons, 128 notes are available in MIDI and for mathematical reasons they are numbered 0 – 127, not 1 – 128.

Once armed with this information, I filled in the spreadsheet, went back to the text file ‘MidInt PcKeys v1.txt’, filled in my own numbers and saved it as ‘MidInt PcKeys AM Wicki.txt’ in the same folder as ‘MidInt PcKeys v1.txt’.

The file began like this:

(Large numbers like -999 are used for comments, and are not interpreted as instructions).

It doesn’t matter what order you put the notes in, so I started in the top left of my spreadsheet, so you can see the line of codes representing the F keys, followed by the line of codes representing the number keys.  The file just continues until the end of the bottom line (the one beginning ` Z X C V . . .).

There are other things you can specify in the file – for example, you can map some keys to MIDI control messages, and MIDI Integrator has some of its own commands.  I ended the list with the following:

-2 space, R C SUS;
-15 Home, R C OCT 2;
-13 Pg Up, R C OCT 1;
-14 Pg Dn, R C OCT 0;
-16 End, R C OCT -1;
-12 >, R C OCT -2;
5 Ins, R C KEY -1;
-6 Del, R C KEY 0;
-11 <, R C KEY 1;

Instead of ‘N’ for note as the 4th character, ‘C’ is for control.  MIDI Integrator’s command ‘OCT’ changes the octave of the keyed note up or down by the amount shown, and the command ‘KEY’ changes the keyed note up or down by one semitone.

Now my note instructions are permanently preserved in the text file and never have to be input again.  Whenever I open MIDI Integrator, I can click on the box ‘p mapPCKeys’,

and in the box that opens up, click on ‘read’ next to the text ‘Click to change mapping table’,

This brings up a typical ‘Open file’ dialogue box in which I can select ‘MidInt PcKeys AM Wicki.txt’, which immediately maps all the keys of the QWERTY keyboard to the Wicki-Hayden layout (or the Janko layout if I choose ‘MidInt PcKeys AM Janko.txt’, or any other layout for which I’ve created a text file).

There are a few other things to do to get MIDI Integrator working – for example, the keyboard volume can be set via the slider on the right-hand side – but these are all explained in the detailed MIDI Integrator Manual, available along with the program, the spreadsheet and other things at www.altkeyboards.com/file-cabinet.

The main thing is to select the instrument routing.  This is done by clicking the box ‘p Instrument_L’, ‘p Instrument_R’ – or whichever one you’ve chosen on the lines of the text file – at the bottom of the main screen:

The boxes on the left-hand side, especially ‘noteout l’ (or ‘noteout r’, etc., for the other instruments) are important.

A QWERTY keyboard isn’t quite as good as the AXiS or the Jammer, of course, but it’s a pretty cheap way of getting to know isomorphic keyboards and alternative keyboard layouts.

Alternative Keyboards 2

My first alternative keyboard project was to create a MIDI controller in the form of an isomorphic keyboard, as described in my previous post.

This project came in in two halves, Hardware on the one hand, and Software on the other.  This was a bit of a chicken-and-egg situation – I needed hardware with the type of output that could be interpreted by one of my software programs; but I needed a software program that could deal adequately with the type of output the hardware – a two-dimensional key layout – would produce.

This post is about the hardware (a QWERTY keyboard).

The hardware requirement was for an input keyboard capable of playing about 40 – 50 notes, like the AXiS pictured in my previous post – the keys would be in 4 or 5 rows and the rows would have to be offset, to make it easy to press keys on more than one row at the same time, and to allow diagonal movements for melodies and arpeggios.

Apart from the physical appearance, I was looking for something simple and inexpensive – i.e. I could construct it without advanced carpentry, metal work and electronic skills, or buy it off eBay.

The third requirement was that it should connect easily to the computer.

I bought and tested some tiny ‘tactile’ switches (cheap in bulk from China), but hadn’t at that time resolved the problem of how to get the computer to understand their output; so I put them away for future use.

In fact, my conclusion was that what I needed would look very much like a computer keyboard, with rows of offset buttons, so I looked around and identified what I thought would be the most suitable.  The model I chose was the Cherry G84-4100.

The reasons I chose it were a) it’s quite small and light (282 x 132mm, and 500g), but the keys are a reasonable size, b) it’s flat, making it easier to play as a music keyboard, c) it has 5 rows of equal-size keys (the top row, the F keys, are a smaller size than the others on the majority of keyboards), and d) there were quite a few available for about £15 new, £5 second-hand, on the internet.  (The full price seems to be about £50, but there’s no need to pay that much, there always seem to be some for sale at a lot less).

There are several different models of G84-4100, but I don’t think the differences between them are significant, except for one thing: seeing the PS2 adapter in the picture reminds me that although most versions are USB, some versions have PS2 conectors.

USB is the ideal connection method: modern computers all use it, and music programs understand it; but if you want to do this and happen to get hold of a keyboard – or any other input device, for that matter – with a PS2 to USB connector, it can be converted.  Not necessarily with a simple adapter like the one in the picture, however, which just physically changes the plug: these can’t be guaranteed to work, and you’ll probably need the kind of converter with some circuitry in it, and some of these work better than others.

I’ll be discussing interfacing ‘HID’s (‘Human Interface Devices’ – i.e. keyboards, mice, joysticks and so on) in more detail in later posts, but if this happens to be an issue for you at the moment, this: http://geekhack.org/showwiki.php?title=PS2-to-USB+adapters is the best discussion on the internet of the alternatives.

I use this one, the so-called ‘Blue Cube’.  It can be found at a reasonable price on eBay, but try and avoid PS2 if your computer doesn’t have a PS2 socket, as a decent converter like this one may cost as much as the keyboard.

So, I got the keyboard.  Any keyboard will do, if you’re doing this, so you could just as well use any type – including the one that came with your computer, obviously.  I wanted a separate one because it would be more convenient than the laptop (and had the full-size 5th row of keys), it would look better, and could be customised, if required.

In my case, I customised it by prising the keys off and painting them red, as I found the letters and numbers distracting.  (I should mention at this point that I didn’t do this until I had sorted out the software set-up, which I’ll describe in my next post: it was helpful to know which key was which during the process of getting the computer program to interpret the keys in the way I wanted!)

The keys on this particular model are Cherry ML (not their more well-known MX type, but more suitable for this application, being flatter in profile).  Replacement keyboard caps are available (from http://uk.rs-online.com/web/p/switch-accessories/0199447/), but I wouldn’t bother with those unless you break or lose a large number of the originals, as they’re pretty expensive!

You can also get a special tool for getting the keycaps off gently, but you don’t need it if you’re careful, or don’t want to get the keycaps off at all – and it’s also unnecessarily expensive.  I wanted to take the caps off not just to paint them, but to clean the keyboard, as it was second-hand.  The can of paint was only £1 from the Poundshop, so wasn’t a major expense.

If you do want to take the keycaps off, the best thing is to use two small screwdrivers or similar tools, one under each side, to lever them off with equal pressure on each side.  They just pop off and press back in place, and unlike many keyboards, nearly all of them are identical.  There are a few that are slightly bigger or smaller, and it’s generally obvious which ones; there are also a few – for example the space bar – which also have a little metal bar which you have to put in place before pressing the keycap back on.

At this point I had the keyboard I needed – not quite as nice as the AXiS, I know, but I was sure it would work in much the same way.  Next I needed to pick the software to use it with.  This will be the subject of my next post.

Alternative Keyboards 1

I’m not sure exactly which department this topic should go in, but I’ve added ‘Software/MIDI’ as the advent of these two things has made the possibility of using alternative keyboard layouts very much a practical proposition. I’ve been experimenting with these and come up with some relatively low-cost ways of trying them out.

The purpose of this post is to explain what ‘alternative keyboard layouts’ are – as opposed to ‘alternative methods of controlling synths’ or ‘alternative methods of generating musical notes’, which I deal with elsewhere in the blog. Although there’s undoubtedly an overlap between these things, I’d like to talk here about some specific proposals that have been made over the years to improve the traditional piano/organ keyboard – certainly appealing to those who are non-players of the instruments, but also with a specific appeal to trained keyboard players and those with a keen interest in music theory.

I’ll get into the music theory aspect, insofar as I understand it myself, later; and follow-up posts here will describe the different ways I’ve tried putting alternative keyboard layout ideas into practice.

To begin at the beginning, the conventional piano keyboard, with its line of large white keys interrupted by thin black keys, although a familiar and iconic design, isn’t necessarily the easiest way to play or learn to play music: you have to hold your arms at an odd, straight-on angle to the keyboard; it’s a long stretch from one note to the next octave up or down; you have to move your hands to different positions to play chords in different keys, and so on. Ultimately we might also consider how difficult it makes things if you want to play music using divisions of the musical scale which are different from the 12-note one we in the West are used to.

It was a long time ago, certainly as early as the 19th century, when people began to think of replacing the one-dimensional line of keys found on pianos and organs with a two-dimensional bank of keys, like the bank of keys on a typewriter (or this computer keyboard I’m using now).

It was quickly realised that there would be more than one advantage to this arrangement: notes could be repeated in several places on different rows, allowing the player to find the easiest way to play a particular passage (players of stringed instruments are used to this and wouldn’t want to be without it!); notes which are far apart on the conventional keyboard could be placed closer together, enabling even those with small hands to play chords or melodic passages with large intervals; and, most importantly of all, the keys could be distributed in such a way that the pattern of a particular chord would be exactly the same, no matter which key it was played in, and the pattern of a melodic passage would be the same, no matter which note it started on.

It is this latter feature which leads to the name often given as a description of this type of keyboard – ‘isomorphic’. Well-known isomorphic keyboard layouts were invented by Paul von Jankó and Kaspar Wicki in the 19th Century, and in the 20th Century, Brian Hayden independently developed a system similar to Wicki’s, which one often sees described as the Wicki-Hayden system.

This is a picture of a piano with a Janko keyboard layout. As you can see, there are still white notes and black notes, but not in the same pattern as on a conventional piano, and there are 6 rows of keys:

[Photograph of piano with Janko keyboard at the Musikinstrumenten-Museum, Berlin by Morn the Gorn (Own work) [CC-BY-SA-3.0 (www.creativecommons.org/licenses/by-sa/3.0) or GFDL (www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons’ http://commons.wikimedia.org/wiki/File%3AMIM_Janko_Piano.jpg]

This diagram of the Wicki-Hayden layout shows how the notes are placed in relation to one another. The keys themselves may be buttons, as they are on a concertina or accordion (Brian Hayden was a concertina player), but the hexagonal pattern used here emphasizes the importance of diagonal relationships between the notes, and relates to the method often used in modern electronic instruments of using hexagonal keys set out in exactly this way.

[Diagram of the Wicki-Hayden note layout used on some button accordions and some isomorphic button-field MIDI instruments by Waltztime (Own work) [Public domain], via Wikimedia Commons http://commons.wikimedia.org/wiki/File%3AWicki-Hayden-Musical-Note-Layout.png‘]

You can read about the Janko, the Wicki-Hayden, and a number of other isomorphic keyboard systems in the Wikipedia at:

http://en.wikipedia.org/wiki/Isomorphic_keyboard
http://en.wikipedia.org/wiki/Generalized_keyboard
http://en.wikipedia.org/wiki/Janko_keyboard
http://en.wikipedia.org/wiki/Wicki-Hayden_note_layout

Each of these pages contains numerous links to external sites, if you’d like to know more. I’ll be dealing with some of the issues that follow on from this, such as microtonality (as mentioned above, these two-dimensional layouts also lend themselves more readily to musical scales of more or less than 12 notes) and dynamic tonality in future posts.

You should also check out this site: www.altkeyboards.com/ which is also the home of the program MIDI Integrator, which I have used, and an interesting modern-day electronic instrument using an isometric keyboard (two, in fact) called the Jammer.

The Jammer, in turn, is a development along similar lines of an instrument called the Thummer – which almost reached the point of commercial production – and uses a keyboard called the AxiS-49, which is commercially available (from C-Thru Music at www.c-thru-music.com/cgi/?page=home). A larger version of this keyboard, the AxiS-64 is also produced:

All of these instruments these days are MIDI controllers, and YouTube is probably the best place to see them in action. This lengthy introduction to the AxiS-64 also serves as an illustration of many of the reasons why isomorphic keyboards were invented: http://www.youtube.com/watch?v=D7OeRkXWTtQ. You can also see the Thummer http://www.youtube.com/watch?v=GtzA2UHOr-A and the Jammer http://www.youtube.com/watch?v=GLN4CAl6p7A.

There are hundreds more videos of these instruments and others, including a nice-looking Japanese synth called the Chromatone, which appears to be completely self-contained: http://www.youtube.com/watch?v=in9_ojEnfO0.

The next post in this department will be on methods of creating simple isomorphic keyboards, and the hardware and software I’ve used to create mine.

The Superstylonanophone

I wasn’t intending to get into MIDI instruments at the time I started on this project, and construction of the Superstylonanophone came about by accident when I acquired an apparently non-working Korg Nanopad.

Essentially, what it is is a cut-down Nanopad attached to a Stylophone, so that the middle 12 keys of the stylophone operate what would, in the Nanopad, have been the 12 pads.  The touch sensitivity of the original pads seems to have all but gone, which is a big loss – but the pads didn’t work at all on the device I acquired, so the present arrangement is an improvement on that.

I have since learned that stuck pads is a common fault in Nanopads, and there is currently an instructional video on YouTube at www.youtube.com/watch?v=BuomrJNd0cM, uploaded by treilaux,  telling you how to fix them.  If you have a Nanopad with stuck pads, you could do that instead of what I did; even if you don’t, you can see from that film how I took the Nanopad apart and detached the pad section from the electronics section.

I continued by sawing off the large right-hand section of the Nanopad with the pads in it, and was left with just the circuit board, ‘Scene’, ‘Hold’, ‘Flam’ and ‘Roll’ buttons and the track pad.  I trimmed down the back as well, to fit the remaining piece of Nanopad front panel.

Everything was removed from inside the Stylophone (it was no longer working), except the PCB with the keyboard on it.

The difficult bit was connecting the Nanopad PCB to the Stylophone PCB.  This was not difficult in principle, but only in practice.  The Nanopad pads were operated by a plastic film connected to the PCB via a 14 way ZIF socket.  The connections on the PCB were too small for me to get at – just 1mm apart – so I was hoping to find a replacement 14 way jumper cable that would be long enough to go from the ZIF socket, out of the new Nanopad enclosure into the body of the Stylophone.

I couldn’t find one: it wasn’t a proper ribbon cable, but another thin plastic thing, and in the end I had to get a short one and solder a proper ribbon cable to another ZIF socket at the other end of it.  I managed to find a type with alternate pins pointing in opposite directions, giving me 2mm space between each one.

The other end of the ribbon cable attached to the backs of the 12 middle keys on the Stylophone PCB.  I chose C – B because these are the defaults for the Nanopad’s Scenes 2 – 4, which resemble a conventional keyboard.  You can change this with the Korg Kontrol Editor program, but there seemed no point.

The 14 lines from the Nanopad PCB to its pads were one connection for each pad, plus 2 control lines, one for the top row of pads and one for the bottom row.  I was gambling that these two control lines were, in fact the same, as the Stylophone’s stylus has only one wire going to it and I obviously wanted to be able to play all 12 notes.

Fortunately, I was right, so in the end only 13 connections were needed.  However, since the Nanopad is polyphonic, it seemed a bit of a waste not to take advantage of this, so I added a socket on the side for a second stylus.  This is connected to the same spot on the circuit board as the integral stylus.  After using the Stylonanophone for a short while, I realised that this is a great asset, especially for playing drums and percussion, even if only one note at a time is sounded.

Because foot controls would be more natural for some applications (e.g. bass drum and hi-hat, or bass pedals) I added an external socket for other input devices to connect to, giving access to all 12 notes.  I’ll be writing in more detail elsewhere about the switching systems I’ve devised, and later on in the blog about any of the input devices I’ve been working on, as and when they get finished.

The Nanopad doesn’t have MIDI in and out connections: instead, it has a built-in MIDI interface, and requires only a USB cable.  To allow for the possibility of future expansion (for example, I also have a Nanokeys I plan to work on), I decided to add a USB hub.  I found a flat square one that fitted into the base, and didn’t interfere with the vast amount of wiring inside the Stylophone body.  I superglued this in place.  The Superstylonanophone connects to this hub with a very short mini-USB to USB A cable, and the hub connects to the computer with a longer one.  The hub has proved very useful when I’ve needed to plug in more USB devices.

The Superstylonanophone logo, by the way, is just printed on a slip of paper tucked into the edging of the Nanopad trackpad.  This is easily removable, but isn’t thick enough to prevent the trackpad operating properly.  This was something I also saw on YouTube, at www.youtube.com/watch?v=xNKFJZX4Na4, uploaded by meltdownband.

Sounds

There are no sound files to go with this instrument, as it’s a MIDI controller, and can be used with any real or virtual MIDI instrument.

Software and MIDI

If you’re interested in using computer software for making musical instruments or sound manipulation, there are several programs you can use, but my favourite is Pure Data.

The reasons I like it are:

1.  You can do a lot of different things with it

2.  You program it graphically, not by writing lines of text

3.  It’s free

4.  There’s a lot of help available, and a lot of people using it who are happy to share their experiences, and applications (or ‘patches’) they’ve written with it.

Another feature of the program, which I have not used myself, but which you might like, is its ability to handle graphics and video, and integrate these with sound.

You can read about PureData at http://puredata.info/, and also in the Wikipedia at http://en.wikipedia.org/wiki/Pure_Data.  This is what Pure Data programming looks like:

This example shows MIDI information and audio information being used together as Pure Data can deal with them both.

From the Pure Data website, you can access manuals and tutorials, and a very helpful series of video lessons.  These are also on YouTube: just search under ‘Pure Data’.

The most practical version to use is ‘Pd-extended’, which you can download from here: http://puredata.info/community/projects/software/pd-extended.  I use a Mac, but the program is also available for Windows and Linux.

Another program for general use is MAX/MSP, which is very similar to Pure Data – in fact, it was invented by the same person, Miller Puckette.  The version you would use to create programs is not free, but the version you would use to run other people’s programming – ‘Max Runtime’  – is free.  It’s described at and can be downloaded from the Cycling 74 website at http://cycling74.com/products/max/.  There are Mac and Windows versions there.

Other programs I’ve used in this series of projects are to do with different methods of note input – in other words, programs which can interpret input from a QWERTY keyboard, a mouse, joystick, gamepad, etc., and allow you to use it for musical purposes.  These devices are collectively known as HIDs or Human Interface Devices, and programs such as Pure Data and MAX/MSP can readily be set up so these HIDs can be used as musical instrument controllers, just like a MIDI keyboard.

I’ve also used:

MIDI Integrator (a MAX/MSP application), which is an easy and efficient way to set your computer up to accept input from keyboard, mouse and so on and use them as MIDI controllers.  The program is described at www.altkeyboards.com/integrator and can be downloaded for free from there.

In fact, that website, ‘altKeyboards’ is a mine of information about alternative keyboard layouts, which I intend to write about separately at some point.  It’s well worth looking at this page www.altkeyboards.com/instruments/isomorphic-keyboards to see what inspired author Ken Rushton (‘MusicScienceGuy’) to create MIDI Integrator.

Another MAX/MSP-based application is Alexander Refsum Jensenius’s ‘MultiControl’, which is able to recognize input from HID and convert the signals to MIDI output.  You can read about it and download it from here: www.arj.no/2008/02/25/multicontrol-v04/.

And finally, a program which is very good, but not free and available for Mac OS only, is ControllerMate.  ControllerMate is a very flexible and detailed program for customising input from of all kinds of HIDs.  It allows you to assign particular functions to all the buttons and controls on a device such as a keyboard, mouse, joystick etc., and to set up different named configurations – including multiple configurations for the same device – to make it quick and easy to use them for different purposes at different times.  ControllerMate is described at www.orderedbytes.com/controllermate/, and can be purchased from there.

These are the programs I’ve found most useful so far.  I’ll describe them in more detail when I report on the projects I used them for.