Archive for the 'Software/MIDI' Category

18
Nov
19

Making music with the BBC Micro:bit, Pt 1

Recently I was lucky enough to be given a BBC Micro:bit as a present.

What is a Micro:bit? – It’s a micro-sized computer, half the size of a credit card, with a row of input and output pins along one edge, Bluetooth capability, a display consisting of 25 LEDs in a a 5×5 pattern, and able to be powered and programmed via USB.  For ultimate simplicity, it can be programmed directly from the website www.microbit.org, via WebUSB using the Chrome web browser.

When it was introduced, its purpose was to ‘encourage children to get actively involved in writing software for computers and building new things‘, rather than being merely consumers of media, and around a million of them were given away to schoolchildren by the BBC.

Once I found out that it was considered suitable for primary school children, I was greatly encouraged that I would be able to write programs for it; and, in fact, there is a particularly straightforward way of doing this (as well as Javascript and a version of the Python programming language): that is, the Microsoft MakeCode system, which involves arranging and sequencing interlocking ‘blocks’.  You still have to have the programmer’s mentality, but without having to remember the precise wording and syntax.

As shown in the pictures above, The Micro:bit has a row of about 20 pins on its bottom edge, which have different digital or analog functions, and 5 of them, in particular, are easily accessed with crocodile clips or 4mm banana plugs.  These are +3v (actually 3.3v) and Ground, and analog pins P0, P1 and P2.  As a matter of fact, these last 3 pins can be operated simply by touching them!  You may have to touch Ground with your other hand to make sure they work, though.

Two tactile switch buttons are also available for incorporation into simple programs, and there is a tactile ‘Reset’ button on the back, which causes the Micro:bit to reboot.

For more complex applications – which can even include operating external devices such as servos – a range of edge connectors is available, which can aid permanent connections or take advantage of the smaller input/output pins.

There seemed to be several different ways in which I could make use of the Micro:bit’s capabilities.  First of all, it can, with a speaker attached directly to one of its analogue pins (typically pin P0), make monophonic square-wave sounds of its own, including playing a number of tunes stored in its own memory; secondly, it can be programmed to output MIDI messages; and thirdly, it can utilise and output data from its onboard detectors, which include light and temperature sensing, a three-dimensional accelerometer, and a compass/magnetic sensor.

I decided to start by using the Micro:bit’s internal sound-generating capabilities.

For this, I decided to make a module into which the Micro:bit could be inserted, and which would contain a power supply, speaker and various input and output sockets – all the hardware needed for a free-standing Micro:bit-controlled musical instrument.  That is the subject of this post.

*

I began with an empty Stylophone case, left over from an earlier project.  I left the speaker in, and the two slide switches on the front left.

In order to incorporate the Micro:bit, I bought a ‘proto-board’ – an edge connector into which the Micro:bit slots at a right-angle, with a section of stripboard attached for ancillary circuits to be built on.  I chose the right-angle one because I needed the Micro:bit to be visible when in use, and to have access to the front and back of the Micro:bit where its sensors are located.

I used this board for a couple of things: a simple op-amp based buffer/voltage follower, and an audio output transformer to be used with an alternative to the speaker, a piezo element.

I also bought a sturdy protective cover for the Micro:bit to ensure that it suffered no damage while being plugged in and out.  This particular type of cover leaves the edge with the pins exposed for just this sort of application.

This picture shows the board in situ, kept in place with matchsticks used as locating pins.  The transformer and op amp are on the right-hand side; on the left are a 4-pin i.c. socket and capacitor left over from an experiment with an audio amplifier, which I decided not to keep.

The voltage follower is the simplest possible op-amp circuit:

I used one half of an NE5532, as that’s what I happened to have available, but any op-amp can perform this task of ensuring the output has a suitably low impedence level.

I’m not sure how useful the transformer is in this exact context, but I learned of its use with piezos from this Nic Collins video on YouTube and had bought a handful of them for this kind of use.

These pictures show how the piezo was fixed into the former Stylophone case, from the inside (L) and outside (R) in the place previously occupied by the tuning knob, which protruded from the bottom of the case.

The Micro:bit can also be powered through thie proto board: mine had a terminal block already installed in it for +3v and Ground; I powered the unit with a PP3 battery, as I am wont to do, so added a small adjustable voltage regulator before the terminal block, set at 3.3v.  This meant that the Micro:bit was receiving its correct voltage, but more volts (up to 9v) would be available for any additional circuitry required.  Two LEDs show whether the 9v and 3.3v parts of the circuit are powered up.

While working on the inputs and outputs, I added the following: an external 9v power in socket; send and return sockets so that external tone controls (such as these) could be used; sockets for an external speaker or headphones and an external piezo; a line out socket for easier mixing or recording; and two sockets connected to analog input pins P1 and P2.

Pin P1 was connected to a 10k lin potentiometer, one end of which was connected to 3.3v, the supply voltage for this part of the circuit, the other to 0v; in this way a continuously variable voltage could be available at pin P1 for control purposes: the Micro:bit would interpret this as a number between 0 and 1023.  If something was plugged into the P1 socket, the potentiometer would be disconnected and the external signal read by the pin instead.

Pin P2 was not connected, unless something was plugged into the P2 socket.  A second 10k lin potentiometer, set up exactly like the one for P1, was added, terminating in a 3.5mm mono plug.  This was available to be plugged into the socket and used for the same purpose if a program were to require it.

In use, I found I had problems with the circuit if the PP3 battery wasn’t new or, if rechargeable, well charged; fortunately, with the external socket it would be possible to use a mains adapter.

*

I set the mIcro:bit up to make some trial tones, but the sound was rather quiet, through both speakers and piezo, so I added a small amplifier.  This was a very economical (99p) module from a UK eBay seller, based on the PAM8403 chip.  This is a 3W stereo amplifier chip, but I would only be needing one of the channels.

It required a 5v supply, so I powered it from the 9v source and added a small 7805 5v regulator.

7805

I put a 10k log volume control before the amplifier input, with the line out socket between the volume control and the amplifier input.  If a plug is inserted in the line out socket, the signal to the amplifier is cut.

After the amplifier there is a 3-way switch to choose between internal speaker, external speaker or headphones, and piezo element.

The following picture shows the majority of the interior at the end of phase 1 of construction (but before I added the two LEDs):

Features marked: 1 = the original Stylophone switch PCB, repurposed for 9v on/off and 3v on/off; 2 = volume control; 3 = the original Stylophone speaker; 4 = the 5v voltage regulator and amplifier PCB; 5 = the 3.3v voltage regulator PCB; and 6 = the 3-way audio output switch (internal speaker/external speaker or headphones/piezo element).

On the exterior I added three tactile switches to replace the two switches A and B on the front of the Micro:bit.  The first two switches simply duplicate the effect of the two switches on the Micro:bit; with the aid of a couple of diodes and a 4066 digital switch i.c., the third tactile duplicates the effect of pressing A and B at the same time, an action recognised by the Micro:bit.

I didn’t add any pull-up resistors on the outputs of the 4066 as the Micro:bit already has these internally.

*

After this I had a working module, so it was time for some programming!

*

I started with a couple of simple programs to make use of the light sensitivity and magnetometer functions.

While experimenting, I connected the Micro:bit to my Macbook with a USB cable, opened the Chrome web browser and wrote the programs using MakeCode on the microbit.org website.

The following picture shows the main features of the coding page:

1 = the simulator.  Most – but not always all – of the coding you write is automatically simulated here.  As you can see, the first instruction of my program, to display the number 1, is shown, as is the indication that I have chosen instructions which require the speaker to be attached;

2 = the button you press to load the program into your USB-connected Micro:bit.  WebUSB has not yet been implemented in most web browsers, which is why I use Chrome to do this.  Incidentally, if you’ve made any syntactical errors in the program, you will be told when you click this button;

3 = the area to name and save your program as a hex file.  The alternative way to program the Micro:bit is to open its window and drag and drop a hex file onto it;

4 = where you choose to program using the blocks, as I have done, or to write the code in Javascript;

5 = the area where the program is written.

*

As for my first program: the light control on the Micro:bit takes advantage of the fact that if the current to an LED is inverted, it becomes (slightly) sensitive to light.   The Micro:bit has an array of 25 LEDs on it, and it’s possible to use 9 of these together to record light levels on and around the device.

I found that the most useful way to use this feature was to set the Micro:bit up to sense the ambient light level, and then react to brighter lights being shone onto the LEDs, rather than the other way round (i.e. reacting to being shaded from the ambient light).

In this case, the reaction I programmed was to sound a note, then increase the pitch of that note as the light level increased.  Initially I just used the torch in my mobile phone, but I had already made 2 devices which could be used to control the Micro:bit in Light Reactive mode, the UFO and the Shuttlecraft.

As I said, the Micro:bit was programmed to start up in a waiting state and display the number ‘1’:

Then, when its Button ‘B’ was pressed – or the Button ‘B’ on the top of my module – it would run the part of the program related to the Light Reactive Instrument and display the number ‘3’:

The Micro:bit outputs a number between 0 and 255 to represent how bright the light level is.  0=dark and 255=bright.  The variable lightlevel in the program is set to be 20 times this number, i.e. between 0 and about 5,000.  The opening pitch chosen, 220Hz (the note A below middle C) and the range of values represented by lightlevel is designed to allow the Micro:bit to output pitches between 220Hz – a low to medium note – and about 5kHz – a very high note.

The variable lightambient is used to sample and remember the normal light level around the instrument on startup.  If the light level is no greater than this, the instrument makes no sound, the idea being that it should remain silent until a light is deliberately shone on it.

*

The second simple instrument I programmed was, in essence, the same thing, but reacting in this case to the presence of a magnet.

The Micro:bit measures magnetic force, as it says above, in microteslas (µT).  It turned out that the range of readings it gave did not need scaling or multiplying like the light level readings did, but produced a useful range of pitches without any changes.  So in this case the variable magforce was equal to the microtesla reading and gave rise to an output at the same Hz as the reading.

In this case, a magnet in the vicinity of the Micro:bit caused a pleasing arpeggiated effect, increasing in pitch the closer the magnet came to the Micro:bit, and decreasing as it was moved further away.

Again, the variable magambient was inserted in order to stop the instrument from sounding until the activating magnet was intentionally brought close to it.

I bought a neodymium (NdFeB) magnet especially for this purpose, as these are particularly powerful – up to 20 times as powerful as conventional ferrite (iron) magnets, in fact.

Neodymium magnets are graded from 28-52 according to their strength.  This one was an N52 (highest power) type.  It works very effectively, but has to be kept well away from any metal parts of the instrument – indeed metal parts of anything – as it will stick very easily and very strongly to them.  I wasn’t sure, but it even seemed to be affecting the speaker in some instances – a speaker, of couse, being driven by a magnet.

The only negative thing about this second instrument is that every time you reboot the Micro:bit, the compass/magnetometer has to be reset if you come to use it.  This is not, unfortunately, a simple matter, as you have to turn the Micro:bit every which way, with your progress shown by the LEDs lighting up one by one.  Only when all 25 of them are lit can you proceed.  This is obviously critical, if you genuinely want an accurate compass direction, but not so critical if all you want to do is make entertaining noises . . .

*

As I mentioned earlier, I had added two potentiometers connected to analog input pins P1 and P2.   I didn’t have an immediate use for these, but I thought it would be handy to have two variable inputs – for tuning or transposition, for example.

In preparation for Phase 2 of the instrument, I made use of the input to pin P1, and programmed it in the following way:

At the beginning of the program the potential input from pin 1, 0 – 1023, is divided into 21 equal sections, and scaled down to 0 – 20.  Each of the 21 divisions is numbered. ‘notenumber 0’, ‘notenumber’ 1′, ‘notenumber 2’, etc.

There are 20 notes on the former Stylophone keyboard, so there is one number for ‘off’, and one number for each note on the keyboard, ranging from 220Hz (‘Low A’) up to 659Hz (‘High E’).  When the potentiometer connected to pin 1 is turned fully anti-clockwise, the instrument is silent; as it is slowly turned clockwise, each note is stepped through in turn, until the highest note, ‘High E’ is reached.

This experiment proved that it should be possible to connect the keyboard to pin 1 and use the Micro:bit like a Stylophone.  This what I intend to do in Part 2 of this series.

Meanwhile, here are some recordings of these two instruments.  There are 8 short recordings, following this pattern: first the Light Reactive instrument through the internal speaker, external speaker, internal piezo element amd external piezo element; then the Magnet Reactive instrument through the same four media.

The recordings with the external piezo, glued to the bottom of the tin, are particularly interesting.  My experiments with piezos (beginning here), have so far only been in using them as microphonic elements, in particular as contact microphones, and as part of custom-made percussion instruments, and although the introductory article refers to their use as speakers, this is the first time I had actually used one that way.  Hopefully, there will be an opportunity to complete my survey of piezos by looking into this in more detail.

The tin, in fact, had been prepared for use as a kind of drum – and could easily function that way if attached to a suitable preamp.  It is quite large in size – 22cm (about 8.5″) in diameter and 14cm (about 5.5″) deep – and would make a very effective drum.  In this instance, using it as a speaker adds a noticeable reverb effect to the sound of the Micro:bit instrument.

 

 

09
Oct
17

The MIDI CPU Project – 3. Bass Pedals

After building the MIDI CPU box and programming it to accept input from keys, switches and potentiometers, it was necessary to build MIDI instruments to use its features.

As the MIDI CPU accepted input via a 25-way DIN socket, it would just be necessary to equip each instrument with such a socket and link it to the MIDI CPU with a suitable cable.

The first instrument I’d planned was a set of 13-note bass pedals, and the initial SysEx file with which I’d programmed the MIDI CPU was suitable for this application, with the first 13 control terminals, 0 – 12, configured as a complete octave from C0 to C1.

I got the pedals from a local seller on eBay who dismantled and repaired Hammond organs.

They were in excellent condition, and the switches on each of the pedals seemed to be still wired.  They looked like this:

and the actual connections were like this:

Pedal switches

The two tabs on the front linked one side of all the switches together; when a pedal was pressed, this bus would be connected to the other side of that individual switch, the tab on the top.  This was perfect for this application, in which an individual switch connected to 0v would be interpreted by the MIDI CPU as a note command.

My main task, then, was to connect each of the 13 switches to a 25-way socket, in order to pass the switch presses to the MIDI CPU box.

In addition to this, I wanted to have Octave Up and Down and Hold commands available, so there would be 3 further connections to the 25-way socket.

Finally, I would have to construct a housing in which the pedal unit would sit.

*

There were no circuits as such involved in this project – it was just a case of wiring up the switches and connecting them to the socket.  At the same time I decided to add a couple of extra sockets that would enable the pedals to be used in a different way if necessary.

The additional sockets added were a 15-way socket, which would be compatible with the Superstylonanophone (another MIDI device, with  a built-in MIDI-USB interface):

and a 9-way socket compatible with the Apple IR remote:

*

I connected the switches to the sockets and, because the enclosure I had planned was designed to have another instrument on top of it (another MIDI foot controller, a Digikick Footar) I connected the Hold and Octave Up and Down connections to 1/4″ sockets so these switches could be external, rather than on the top of the pedals.  All the sockets were housed in a small panel, which would be attached to the rear of the enclosure.

*

After connecting the switches to the sockets, I found a D25 cable and attached the Bass pedal unit to the MIDI CPU box.  At the moment the MIDI CPU box is connected to a laptop via a Midisport 2×2 MIDI-USB interface – along with the Digikick Footar – and controls software instruments in Apple Logic.

I added 2 or 3 different bass instruments to the Logic set-up and tested the pedals.  All notes worked as they should.

With an external switch I tested the ‘HOLD’, ‘OCTAVE UP’ and ‘OCTAVE DOWN’ functions, which seemed to be working OK, so deemed it safe to screw down the top of the case in which the pedals were housed and fix the panel to the back of the case.

04
Aug
17

The MIDI CPU Project – 2. The Software

At the end of my previous post on the MIDI CPU Project, I had completed the wiring and construction of the MIDI CPU box – apart from solving the small problem of the box not being big enough for its contents, that is! – and it was time to test it to see if it worked.

The additional feature of the MIDI CPU is that it depends on being suitably programmed in order to function the way you want it to.  I don’t necessarily want to go into great detail about the exact programming I did, but I thought it would be useful to describe generally how it’s done, if only to reassure anyone thinking of embarking on such a project that it isn’t all that difficult, and shouldn’t be an aspect of using a device such as the MIDI CPU that would put you off.

First of all, the method of programming is via the MIDI connectors, so here’s what you need:

  1. a MIDI/USB interface (mine is a very cheap M-Audio Midisport 2×2, quite old now, but works perfectly, drivers for mac and PC readily available on the internet, cost less than £10 on eBay).
  2. 2 MIDI cables, for ‘in’ and ‘out’ (remember – which I don’t always do! – that the ‘out’ from the MIDI CPU goes to the ‘in’ on the MIDI/USB interface, and the ‘in’ from the MIDI CPU goes to the ‘out’ on the MIDI/USB interface!).
  3. a USB A to B type cable if your MIDI/USB link is like the Midisport and doesn’t have one built in.
  4.  a suitable program for sending and receiving SysEx messages.  The one to use for the mac is SysEx Librarian, and for PC, it’s SendSX.  These programs are free and come with documentation, so are pretty simple to set up and use.  Being a mac user, I also used a companion program of SysEx Librarian called MIDI Monitor, which would allow me to see what messages were being sent back and forth from my laptop to the MIDI CPU, and a small PureData patch of my own to see a little more detail of what was in the messages.

Not only does the MIDI CPU come with a fully detailed description of the board and ways of wiring it up, it also has a comprehensive guide to programming.  In addition, there is plenty more advice on the Forum, which I referred to in my previous post.  Even though, as I said, the forum is due to close at the end of 2017, I believe there are plans to preserve it in some way, which would be a very good thing, as it’s a mine of information which would be useful in all kinds of projects of this type.

Essentially, the programming is done in SysEx, and SysEx messages have the following format: a Header, consisting of SysEx header (F0), Manufacturer (e.g. 00 01 5D), Device ID (e.g. 04) and Command (e.g. 01), then some message information, and a footer (F7).  All numbers are in hexadecimal format (i.e. 01, 02, 03, 04, 05, 06, 07, 08, 09, 0A, 0B, 0C, 0D, 0E, 0F, 10, 11, 12, etc.) – which caught me out once or twice, but I soon got the hang of  it.

If you’re writing your own SysEx messages, you may find this chart useful, with all the MIDI numbers in it together with their hex equivalents:

MIDI Note numbers in hex

*

The MIDI CPU programming guide gave a couple of examples of useful SysEx messages.  This one asks the MIDI CPU to send back a message with the current firmware version:

F0 00 01 5D 04 00 7D
00
F7

(it can be written on one line, but I’ve separated the sections so you can see the header, the message and the footer).

You can write your own SysEx messages using a text program like TextEdit, Wordpad, BBEdit, etc., but what SendSX and SysEx Librarian prefer is to use SysEx messages in a file format with the suffix ‘.syx’.

To help you with this the Highly Liquid site kindly provided an online tool for you – this is now on the Code and Copper site at http://support.codeandcopper.com/txt-to-syx/ – so all you have to is write your SysEx message in a text program, copy and paste it into the online tool, press ‘Convert!’, and you get your message back in .syx format, ready to send to the MIDI CPU.

txt to syx

So, first of all, this is what I did.  I wrote the firmware enquiry message F0 00 01 5D 04 00 7D 00 F7, as above, in a text file, which I was able to copy and paste into the online tool.  I got back a file which I downloaded and renamed something like ‘firmware_request.syx’, so I’d remember what it was for.

I added this to SysEx Librarian’s library, made sure to select the port on the Midisport 2×2 I was using, Port B, at the top of the SysEx Librarian window, and pressed ‘Send’.

This is what SysEx Librarian’s window looks like.  The arrow in the top left is the ‘Send’ button:

SysEx Librarian window

The list of files in SysEx format which have been added to the Library are shown in this box.  Highlighting one and clicking the ‘Show File’ button at the bottom opens the folder in which the file is stored; clicking ‘Contents’ enables you to see what’s in the file:

SysEx Lib Bass Pedals.syx

After pressing ‘Send’ in SysEx Librarian, I could see with MIDI Monitor that a message had been sent, and a message had been received.

MIDI Monitor Firmware retrieval

You can double click on these messages to see what’s inside them.  The received message was very similar to the sent message, but with one extra piece of information.  It was all on one line, but I’ve separated the header, message and footer to show the new information in the middle:

F0 00 01 5D 04 7D
01
F7

The ’01’ meant that the current firmware version in the MIDI CPU I had bought back in 2010 was 1.1.  There haven’t been many updates since then but there was an important update between 1.1 and 1.2 which would affect my plans for octave up and down buttons, so I knew from this that I would first need to update the firmware – but the most important result of the message transfer was that I knew the device was working!

I’d downloaded the SysEx file from Highly Liquid for updating to firmware version 1.2a – and, in fact, it’s still available somewhere, as are later firmware versions – so the next thing was to send that message to the MIDI CPU.  This was a slightly more complex procedure, but the steps are laid out in the documentation.  I sent the (much longer) message, and when it was completed, sent the firmware enquiry message again.  This time it returned the information ’04’ in the middle, meaning firmware version 1.2a was now installed:

MIDI Monitor Firmware message

Following the guidance in the manual provided by Highly Liquid, I then wrote the most complex SysEx message, configuring each of the 24 control terminals.  Between the header line F0 00 01 5D 04 01 and the footer line F7, there had to be approximately 48 lines: one line for each terminal to tell it what to do on receipt of an ‘on’ message (a 0v pulse), and what to do on receipt of an ‘off’ message (a return to +v).  It was a little fewer than 48 as the terminals configured as potentiometers, modulation or pitch wheels just needed to be told to look out for a value beween 0 (0v) and 127 (+5v).

In this, my first scheme, the 24 terminals (0-23) were configured as follows:

0-12 were configured as on/off switches, producing a MIDI note on receipt of an ‘on’ message, and going silent on receipt of an ‘off’ message. (This scheme was created with the aim of producing a set of bass pedals.  These will operate the MIDI CPU via the 25-way connector, but the keypad buttons C, D, E, F, 9, A, O and B are also designed to produce notes for testing, tuning, etc.).

13 was configured as doing nothing.  (Its use will be seen in later schemes with more notes than a set of bass pedals).

14-16 were configured as latching on/off switches, for Hold, Sustenuto and Portamento.

17-19 were configured as momentary switches for octave down, octave restore and octave up.

20-21 were configured as potentiometers to control velocity and the amount of portamento.

22 is a ‘spare’ control, which can be routed by the ‘Select’ switch either to a spare latching switch (7 on the keypad), a spare momentary switch (8 on the keypad), a spare potentiometer, or the modulation wheel.  The programming will decide which of these is to be used; in this scheme I decided initially to configure it as a modulation wheel.  What exactly is modulated by this wheel always depends on the individual synth patch.

23 was configured as a pitch wheel control.

I originally wrote the text file like this, to remind myself  of some of the important details in it:

SysEx Text file

Afterwards, before I could use it, I had to remove all the comments on the right-hand side.  So then it looked like this:

Bass Pedals SysEx text file

which I copied and pasted into the online SysEx file creator.  I downloaded the .syx file, renamed it something like ‘Bass_Pedals.syx’, and sent it to the MIDI CPU.

The moment of truth came when I pressed some of the letter buttons on the lower keypad.  MIDI Monitor showed that the right notes were coming out:

MIDI Monitor Note on_off

(Note that a ‘Note off’ message is actually a ‘Note on’ message, but with a velocity of zero.  I had the velocity control turned down rather low, at 27 – it would normally be much higher than this).

I used my PureData patch, ‘MIDI Tester’, to check a bit more closely what was going on:

MIDI Monitor NotesIt’s possible to see from the set of figures on the left that the MIDI channel in use was set to 3 by the MIDI channel control knob.  The velocity is 0 as this is always shown when you let go of the key (or keypad button, in this case), but I was able to check as I pressed down that moving the velocity control altered the velocity all the way from 0 at the left-hand end through to 127 at the right hand end.

The figures in the middle show that the first latching switching, ‘Hold’, had been turned on.  127 is on, 0 is off.

There was something wrong with the octave buttons, though – according to MIDI Monitor, which showed me the note names, they were clearly raising and lowering the pitch by more than 12 semitones . . . it took me a while to work out that I had written ’12’ in the SysEx message, but the hexadecimal number ’12’ means 19, so the buttons were raising and lowering the pitch of the notes by an octave and a half, not just an octave.  I quickly rewrote the text message with ‘0C’ in place of 12, got a new .syx file online and resent it to the MIDI CPU, and all was well.

I tried using the internal MIDI/USB interface instead of the Midisport, but although it basically worked, it seemed, according to MIDI Monitor, to be outputting some spurious messages as well as the intended ones.  Consequently, I’m not sure if this can be reliably used – only further testing can confirm this.  It wouldn’t be much of a loss if it didn’t work – the commercial device the board came from was very cheap, just a couple of pounds, it didn’t take much effort to wire it into the box, and the Midisport isn’t currently being used for anything else.  It would just be more convenient if a board within the MIDI CPU box could be used, rather than an additional external one.

Just before I finished, and while the PureData MIDI Tester was still open, I connected the MIDI CPU box directly to the laptop with a USB cable and pressed all the buttons on the upper keypad.  These produced the numbers 1, 2, 3, 4, 5, 6, 7, 8 and 9, and the letters i, o and p, as intended, so that part of the project had worked, too.  I envisaged that some applications of the MIDI CPU would be connected with PureData patches, so having these 12 input symbols available, in addition to the MIDI data, could be useful.

There are also 3 sockets on the rear of the box connected to the Apple keyboard PCB, so an external device connected via the 25 way socket could also be connected one of these if the numbers and letters were also required in addition to the MIDI.

The next post in the series describes the construction of the bass pedals.

04
Aug
17

The MIDI CPU Project – 1. The Hardware

I should have done this project 5 years or more ago!  However, illness, retirement and moving house all conspired to delay my progress.

When I finally came to put into action the plans I had drawn up in 2010, when I bought the module I’m about to describe, I found the device had been discontinued and support was about to cease – a great shame, because Highly Liquid, the company that made the MIDI CPU, were second to none in their support of every type of hobbyist and constructor who used their products (they made some other great devices, too), and their forum was – well, still is, until the end of this year (2017) – a mine of information.

So, my description of my endeavours is unlikely to help anyone embarking on the same project, but it might, on the other hand, be of interest to someone attempting something similar.

[Edit: also, see below for further information on the possible continued existence of the MIDI CPU and other Highly Liquid products (including the MIDI widget, which is the opposite of the MIDI CPU, i.e. a MIDI decoder).  There is a connection with codeandcopper.com, which is run by the same guy, John Staskevitch, and which is home to his current projects].

First of all, then, the MIDI CPU – what is it?

This is what it looks like:

midi-cpu-large_zyevag

It’s a small board, about  7 or 8cm long by 3 or 4cm wide with sufficient components to function as a MIDI controller.  Exactly what kind of MIDI controller depends on you: each of the 24 control terminals along the top edge of the board in the picture above can be programmed via SysEx to perform various logic or analog functions – i.e. they can be configured as switches for notes, switches for MIDI control messages, inputs from potentiometers, pitch and mod wheels, and so forth, whatever your application requires.

The 8 connections on the right-hand side are jumpers to set the MIDI channel, if you don’t want to have to set this as part of the programming.  The 4 pairs of connections are marked 1, 2, 4,and 8, so connecting them to +v or 0v like a binary number will set the channel.  Leaving them disconnected is effectively 0000, binary zero, or channel 1; connecting all of them is 1111, binary 15 (8+4+2+1), or channel 16, and so on.

The 5 connections at the bottom right are MIDI in and out, so the MIDI CPU can be connected to a computer and other MIDI equipment via conventional 5-pin MIDI sockets.

As I say, it’s sadly not being marketed any longer by Highly Liquid, although I see the boards, firmware and detailed information do now appear on circuithub.com and github.com, so it might be possible to obtain one after all, even if you have to solder it together yourself.  It seemed to me at the time an ideal purchase, due to its simplicity and versatility.  The cost was reasonable, around £40, as I recall.  I elected to make it a little more complicated than it needed to be, but you could, with minimal external wiring, create quite a complex MIDI instrument with it – 24 control terminals is plenty for a switch matrix, mod wheels and various other controls.

*

So, what did I do with it?  Well, I had alluded before, in my post on ‘A new use for USB keyboards‘, to a MIDI project which was going to fill up the rest of the enclosure which then included – amongst other things – the PCB out of an old Apple keyboard, and the MIDI CPU was this project.

Some buttons and modulation wheels would be built into the box, but essentially the MIDI CPU board would be accessed via a 25-way socket on the back of the enclosure, so any one of a number of different devices could be attached, and the MIDI CPU could when necessary be reprogrammed to allow for different uses of its control terminals.

*

MIDI CPU inside

This is what the enclosure looked like when I left it, and I now set about filling the top half with the MIDI CPU board and associated circuitry.

The first thing I wanted to do was to add pitch and mod wheels, buttons and potentiometers.

For the potentiometers I used the type with an integral press switch – if the external unit plugged into the 25-way socket had its own, I wanted these to be able to be taken out of the circuit.

For the pitch and mod wheels I bought a set off eBay which originally came from a DX7 or some such.  These were pre-wired and ideal for the purpose – the pitch wheel was properly sprung to return to centre – and were only about £10.

pitch & mod wheels

Conscious of the space problem, I decided on an unusual solution for the buttons: a 16-button keypad.  Although this looked like any keypad, internally it was rather untypical.

Keypads are normally arranged in a matrix pattern, so the output leads are ‘Column 1’, ‘Row 1’,  ‘Column 2’, ‘Row 2’ etc., and each button is in a unique position at the junction of a particular row and column; but this was a special design where each of the 16 buttons, when pressed, was simply connected to a common input.  I connected the common input to 0v, so that a button, when pressed, would be able to ground one of the MIDI CPU’s control terminals.  This is the signal the terminals need to be activated.

As far as momentary button presses were concerned, this was ideal, but to create latching switches – switches that stayed on until pressed again – extra circuitry was necessary.  What I used was a system with 4 ‘flip-flops’, plus a few signal inverters to make sure the flip-flop would be activated by a positive pulse, but the MIDI CPU control terminal would be activated by a negative pulse.  There were to be 4 latching switches, so 4 circuits like this were needed:

Latching switch circuit

Each of the circuits uses half a 4013 flip-flop chip, and half a 40106, which has 6 inverting gates altogether.  The input to the inverter on the left is kept high, so the output of the 4013 is kept low; the inverter in the middle keeps the MIDI CPU control terminal high, and the inverter on the right keeps the anode of the LED low.  In this way the MIDI CPU control terminal and the LED are both off until the switch on the left is pressed; when the switch is pressed the 4013 output changes state, the MIDI CPU control terminal and the LED are both switched on, and stay on until the switch is pressed again and the 4013 changes state again.

I added a 4-way switch so that all the latching buttons could be taken out of circuit if the external unit plugged into the 25-way socket had its own, or didn’t need them.

Finally, I wanted to add a MIDI channel selector switch, rather than rely on  programming to provide the channel, or hard-wire the jumpers on the MIDI CPU board (described above) to fix the channel permanently.

I got this idea from the Highly Liquid Forum.  The selector switch I used was a type of rotary encoder – specifically a hex encoder, which had 16 positions, and 4 outputs, which could output a binary number in each of these 16 positions, going from zero (0000) to 15 (1111).  (I had used one of these before, in creating the Bigfoot automatic stylophone controller).

The beauty of using this particular type of encoder – and they aren’t all the same, by any means – is that each of the 4 outputs is connected to a common terminal when it’s set at 1, but not connected when it’s at 0.  At the beginning (0000), none of the 4 outputs are connected to the common terminal; at the end (1111), all of them are; and in between (e.g. 0101) some of them are and some of them aren’t.  If the common terminal is connected to +v, then the 4 outputs can all be inputs to electronic switches, turning on when set at 1, turning off when set at 0.

A suitable electronic switch is the 4066, which has 4 switches in one chip, just right for the 4 connections which need to be made on the MIDI CPU board to change the MIDI Channel anywhere from 0 to 15, which represents the full number of MIDI Channels 1 to 16.

I also wanted to add an indicator of what MIDI channel was currently set.  To do this I used a chip which you’ve seen me use before, the 4067.  As luck would have it, this chip also requires a binary number from 0000 to 1111 as its input, and for each of these 16 different inputs it connects one of its 16 different outputs to a common terminal.  So, in this case I made the common terminal +v – via a small resistor – and connected 16 LEDS from the outputs to 0v.  In this way, as the MIDI channel changes, a different LED is lit up – no need for them all to have their own resistor, as only one of them will ever be lit at one time.

The simple, but effective circuit, looked like this:

MIDI Channel Selector

*

I then needed to connect everything together, and the quantity of components and wires in the  enclosure – as so often with my projects – began to increase rapidly.

IMG_0387 IMG_0388 IMG_0390

The keypad with the white buttons is the keypad I was describing above; in the first configuration I made of the MIDI CPU’s control terminals, the keys with letters play the appropriate notes of the scale: A, B, C, D, E and F; O plays A#/Bb, and 9 plays G; the other 8 numbered keys are divided between latching and momentary switches.

The keypad with the black buttons is not part of the MIDI CPU project: it’s connected to the USB keyboard PCB shown in the first picture of the inside of the enclosure above.  The numbers and letters it produces are useful in applications created with, for example, PureData, where the input can be interpreted in many different ways, as required.

The pitch and mod wheels can be seen on the left and the 16 MIDI channel indicator LEDs on the right.

*

In this view of the partially complete project, you can see 1. the MIDI channel circuit; 2. the MIDI CPU board; 3. the pitch  and mod wheels; and 4. the latching switch circuit.

Interior

The MIDI CPU board needs at this point to be connected to the MIDI in and out sockets and the 25-way socket for the control terminals, and the two keypads need to be connected to the USB keyboard PCB (upper keypad) and the MIDI CPU board (lower keypad).

*

I finished all the remaining interior connections, and the inside now looked like this:

Inside

I removed the excess wiring from the MIDI to USB board (removed from a commercial product, as described in the earlier post linked to above), which is now tucked under the long Apple keyboard PCB on the left-hand side; but the extra wiring from the MIDI CPU board to the internal switches and potentiometers and the external 25-way socket had still over-filled the enclosure!  This view from the outside makes it even more apparent that the box wasn’t going to close:

Back

So I was going to have to do something to make the interior larger before the unit could be used!

Nevertheless, every part of the circuit was now connected up, and it was going to be possible to test it.  I gingerly connected power and switched on.  Lights appeared – a blue light for power, indicator lights where potentiometers were pressed down for on; very bright lights in the centre where latching switches were on; the ‘MOD’ light, to indicate that the ‘Select’ switch for the ‘spare’ control terminal was turned to the modulation wheel position; a light in the MIDI Channel indicator column on the right, and – most crucially – the ‘Activity’ light (not yet labelled, but above the ‘power’ LED), connected directly to the MIDI CPU board, flickered on power up to indicate that it was ready for action.

Front

There was no instrument connected to the 25-way socket – I haven’t yet made any! – but there were enough controls on the box to test a good deal of functionality, including note on and off information from some of the keypad buttons.

Part 2 of this series describes the software, programming and testing of the MIDI CPU box.

16
Jun
17

Sample Manipulation 4 – Databending

I started talking about manipulation of samples by describing The Black Widow, a PureData patch for controlling up to 4 samples using a flight simulator-type joystick control, and the Black Widow II, with improved features and an automatic mode.  I also described two other applications by Karlheinz Essl and Kevin Holland (Sineqube) which work similarly, manipulating 4 samples in real time.  The third post in the series described two applications which work in real time to manipulate a single, longer sample.

This post covers some non-real time methods of working on samples, often known as ‘Databending’.

The basic idea of databending is very simple: open a sound file with an application it’s not meant to be opened with, change the file in a semi-random way, then save it.  When you play it again as a sound file, it will sound different from the way it sounded originally.  Often quite a lot different.  Some good advice on how to do this can be found at http://www.intelligentmachinery.net/?page_id=29.

*

First of all, what sort of files does it work on?  I’d say you should always start by trying different formats of the same sound file – certainly an uncompressed format like aiff or wav, and a compressed format like mp3 or flac.  There can be a big difference in the results.  Once you’ve tried a particular technique on two or more formats, you might decide it generally works better on one of them, and then concentrate on that one; the next technique you try might work more effectively on another type.

*

Secondly, try some files with different musical content: one file with, say, fast percussive content, another with slow, sustained passages.  A particular technique might suit one style, but not another.

*

Next, what ‘other’ applications could you try?

Text applications are always good.  All files can be displayed as text, as you will have noticed if you’ve ever had occasion to read one – trying to open a pdf in Word by mistake, for example.  It generally looks like gobbledygook most of the the way through, although there’s occasionally a ‘header’ at the beginning with some readable stuff in it.

Sometimes, even the mere act of opening a sound file in a text program and immediately saving it can make significant changes to the way it sounds when you play it back again.  Notepad in Windows or Text Edit on a Mac can be used in this way.  Provided you save the file as ‘text’ and keep the extension (e.g. ‘.wav’ or ‘.mp3’) the same, you’ll be able to play it back.

The first example shows this.  The first extract is from the original sound file I used; the second extract is the file opened and saved in Notepad on a PC; the third extract is the file opened and saved in Wordpad.

Once you’ve got the file in a text editing application, however, there are many things you can do with it.  I’ve tried the following and got some interesting results: changing all lower case letters to uppercase; changing all zeroes to 1’s; changing 1’s to zeroes; cutting and pasting text from other places into the middle of the file; and swapping bits of the file around.  Occasionally you’ll end up with a file that won’t play at all, occasionally a file that sounds exactly the same as it did before – which is particularly disappointing – but usually you’ll have changed something about it in a hopefully interesting way.

Incidentally, I normally use ‘Save As . . .’ rather than ‘Save’, and give the new file a name which reminds me what I’ve done to it.  This has the double advantage of helping me to achieve the same effect again by working out what I did to the file, and ensuring that I don’t lose an original which I might need again – either in its original form, or as the source for more experimentation.

*

Some of these files that you end up with can be rather unstable and may sound different depending on which application you choose to play them back in.  So my next piece of advice would be to try some different applications to audition the results of your work – Windows Media Player, Audacity, VLC, Quicktime, and so on.

If you have a way of re-recording them as you play them, this would be good, as you can then save a stable file which will sound the same whenever you use it.

The second example illustrates this.  The first extract is the original sound file I used; the second extract is this file after processing in BBEdit Lite, played back using Videolan VLC; the third extract is exactly the same BBEdit Lite file played back using Apple Quicktime, producing a significantly different result.

Both files were re-recorded to preserve these differences permanently, as described above.  I use an excellent application called Wiretap Studio for this, but it isn’t freeware.  There are ways to do it without having to buy extra software – free applications like Soundflower (which I think only exists for Mac) or Jack will enable you to route the output of one application, which plays the sound file, to the input of another (like Audacity, for example), which records it.

*

Another, less obvious, way to ‘bend’ sound file data is to open the file in a picture editor like Photoshop, apply an effect and save the file.

This is slightly more complicated; I don’t know about other applications, but Photoshop won’t recognise sound files as pictures, so you have to do a couple of things to persuade the application to try opening it.

First of all, make sure to choose ‘All Documents’ (as opposed to ‘All Readable Documents’) from the ‘Enable’ list.  This makes all files, even sound files, potentially openable.

1 photoshop open

In my experience the ‘Format’ option was greyed out, but make sure it shows ‘Raw’ to enable a dialogue box like this to open up:

2a photoshop raw options

Clicking ‘OK’ should enable Photoshop to open the sound file, and give you a visual representation of it.  It’ll look something like this:

5a DI Loops

If it doesn’t open and you get the dialogue box at the top of the following picture – which happened to me a lot – reduce the numbers indicated until you get the dialogue box at the bottom, then it will open.

3a larger than file

After that, you can apply some effects to the file, then save it.  As mentioned above, I would keep the suffix – usually .aif or .mp3 – the same, but change the file name to reflect the process it had been subjected to.  I had some success with Gaussian Blur, Noise and Despeckle, but any one of the many effects could do something to the sound.

The first example here shows the original sound file; this file with a Gaussian Blur filter applied; then this file with a Despeckle filter applied.

The second example shows an original .aif file with a Noise filter applied; and an original .mp3 file with a Noise filter applied, to show the different effect an identical filter may have on a sample which was identical in every way except the file format.

*

If you have problems opening a sound file saved by a graphics application such as Photoshop, the free Audacity can probably help.  Even if you get the dialogue box shown at the top of the following picture, you can still use ‘Import’/’Raw Data…’ to open the file, and then save it in the format of your choice.

4 Audacity Import

Using the above methods you should be able to make some random, unpredictable and interesting changes to your sound files.

16
Nov
15

The Superstylonanophone 2 – Foot Controller

[Note: this post was originally a comment on the post ‘The Superstylonanophone‘, but it was hard to find there and the images disappeared when I changed my website. where they were stored.  So I’ve trashed the comment and transferred the text and images here].

I mentioned in the above post that a foot controller would be useful for playing drums via the Superstylonanphone, and that I had added a 15-pin socket to the back of the device for this purpose.

This is the controller I made for it:
Footswitches1

Yes, it looks like a length of plastic guttering – but I did say somewhere on the blog that I was looking for low-cost ways of achieving things . . . I found this in my garden shed: it was an offcut left over from a length I bought some time ago at a car boot sale.

The player side is to the left, and the 4 single-pole momentary switches are inclined slightly this way, for ease of use. The two on the left are for hi-hat sounds, the two on the right for bass drum sounds. The 15-pin cable is plugged in on the right hand-side, away from the player’s feet.

Inside you can see the simple connections from the switches to the socket – no electronics required, the Superstylonanophone recognises the switch presses and outputs MIDI instructions accordingly.

Footswitches2

(When I connected wires inside the Superstylonanophone, I made a diagram to show which notes or which drums were connected to which of the 15 pins, so I knew which pin to connect to which switch in the foot controller).

This, together with the two styluses, has made playing MIDI drums a little more natural on the Superstylonanophone.

[Edit: this foot controller has had further modifications, albeit for a different purpose.  See here.]

06
Nov
13

Notes on game controllers

I decided to write this post just to tie together some of my experiences of using game controllers of various sorts to make music.

Generic USB controllers like these are generally pretty easy to use:

Game Controller 3

StyloSim6sm

Since computers come with USB ports on them, it’s usually just a case of plug them in and get going.  There are lots of them about and they can be picked up cheaply on eBay and Gumtree or from local charity shops.

The main consideration is what program to use which can interpret the signals the controller is sending out and allow you to use those signals for your own purposes.  There are many of these, ranging from simple apps to tweak the operation of a particular device, to large and complex  programs designed to customise a device’s every action to the user’s requirements.

This is made possible by the existence of the ‘HID’ standard for USB devices.  HID = ‘Human Interface Device’, a description which can be used to cover devices such as computer keyboards, mice, game controllers, joysticks, and the like – all the things which humans use to interact with computers.  As long as the device is made to conform to the standard – and manufacturers have readily got used to the idea of doing so – these programs can interpret the input and make it available to be changed to a different input; to perform an action completely unrelated to the device’s original purpose; or send data to another program which can use it creatively.

I’ve used several of these for different purposes.  There’s Multicontrol, which I used for this MIDI Drum controller:

MultiControlDrums1

Multicontrol has the ability to interpret the game controller’s signals and pass them on in the form of MIDI messages, or OSC (Open Sound Control).  Designed by Alexander Refsum Jensenius, it’s distributed free for Mac OS.  There is a source file downloadable from the site referenced above, although I have no idea if this can be compiled for Windows PC’s.

I’ve also used a commercial program, ControllerMate, which enables very sophisticated interpretation of controller signals.  This allows not only for simple button ‘mapping’, where you specify, for example, keystrokes for each controller button, but also, with this window you can build up complicated series of events, initiated by a button press.:

ControllerMate window

The small drop-down list to the right indicates the wide variety of actions that can be incorporated into the instructions for each button or other control.

The list in the left-hand column indicates a couple of devices which I’ve made customised groups of special controls for: once you’ve set the controls up, you can save them and call them up by name.  It’s possible in this way to have several different set-ups for the same device, depending on what you want to use it for at different times.

*

My favourite program is PureData, or Pd for short.  Using Pd means you have to write the programs yourself – but this is done graphically, rather in the manner of flow-charts, rather than by writing lines of code, and the program is specifically designed for making music, so it has typical audio and MIDI functions (Pd calls them ‘objects’) ready to use.

I’ve used Pd both for creating instruments, like the Theresynth, which uses the PCLine Rumble Pad pictured above, and for sound and sample manipulation.  The blog post for the Theresynth (which uses one of the joysticks on the controller for changing pitch in a way reminiscent of a theremin), also has quite a detailed description of the Pd programming.  I’ve also blogged about various sound manipulation apps (or ‘patches’) in the past, including the StyloSim, which uses the joystick controller pictured above, and the Black Widow.

The StyloSim patch isn’t very extensive, and looks like this:

StyloSim2

The small box with ‘hid’ in it, near the top right-hand corner, is the Pd object which recognises input in the HID standard; the ‘route’ objects below split up the different inputs, and then you can send them off to do whatever you need them to do – control oscillators or filters, perform mathematical functions, create MIDI messages, and so on.

While on the subject of software, a handy piece of freeware which I often use is Joystick and Gamepad Tester from AlphaOmega Software.  AlphaOmega produce a number of simple but ingenious apps which help you with your Mac, including an app which cuts out that annoying ‘chime’ when the computer opens (my car doesn’t sing at me when I turn the ignition, my hi-fi stays silent until I put in a CD, my TV remains mute until I select a channel – why on earth do computer manufacturers think we want to hear the machine start up!  One of life’s unexplained mysteries . . .), but also some apps which can have a value in computer music.  I may well have blogged about some others elsewhere.

The purpose of Joystick and Gamepad Tester is to tell you what controls your USB device has, and if they are devices like joysticks, what are the minimum and maximum readings you can get from them: 0 – 127, 127 – 255, etc.

I recently bought a game controller like this from a charity shop:

Logitech Buzz

It looked as if it was originally part of a quiz game, and had a USB connector, so it looked as if it would be easy to use with the computer.

I took it home, plugged it in and started up Joystick and Gamepad Tester.

JAGT 1

The instructions say to press all the buttons and move joysticks and other controls so they’re recognised. but when I clicked ‘OK’ on the screen above, I saw this:

JAGT 2

I found out first of all what the device was – a ‘Logitech Buzz Controller V1’ – and was able to select it from the drop down list.  Note by the way that all the normal USB-connected devices are also listed: in my case, there’s the laptop keyboard, the infrared receiver on the front and the trackpad.

The Apple IR Remote – listed in the screenshot above as ‘IR Receiver’ – isn’t exactly a game controller, and isn’t exactly an HID device like the others discussed here, but it’s worth a brief digression as its uses are very much the same.

As far as  Joystick and Gamepad Tester is concerned, nothing was listed when I selected ‘IR Receiver’ or registered when I pressed buttons on any of my Apple remotes – only when I selected one of the two entries ‘IOSPIRIT IR Receiver Emulation’.  I don’t know why there are two entries, but they’re identical and are the result of installing either the app Remote Buddy, or its free driver Candelair – or very probably both – as I’ve been working on using Apple Remotes recently (see blogposts, starting here).

A useful feature of  Joystick and Gamepad Tester in this respect was that it showed the remote’s individual ID No. in the ‘Now’ column.  (The ID numbers in the ‘Min’ and ‘Max’ columns are irrelevant, as they will just show the highest and lowest Remote ID numbers used in the past).  Just picking up a remote and pressing a button will change the now column to verify the number.

When I selected ‘Logitech Buzz Controller V1’, all the controls were already listed:

JAGT 3

There are 5 buttons on each of the controls, and the list suggests that they are unique – that’s quite a decent number of buttons for a game controller, so that could be handy in some situations.  Buttons usually show up with a minimum and maximum of ‘0’, so it was quite interesting see that 4 of them with a different reading in ‘Max’: perhaps these were the big red buttons, one on each handset?

Actually, there weren’t: as you go round the buttons pressing them, you can see exactly which is which – the value appears in the ‘Now’ column: ‘1’ for pressed, ‘0’ for not pressed, which is typical for buttons, so by the time you’ve finished, they all have ‘0’ in the ‘Min’ column and ‘1’ in the ‘Max’ column.  If you’re intending to modify the controller you’re testing by taking it out of its case and fixing new buttons to it, this is very useful because you can make a note at this point of which one is which.

Better still, if you click the ‘Save’ button – indicated by the arrow on the screenshot above – you can save the list as a text file, print it out and make your notes on that.

First you’re given the usual ‘Save’ options:

JAGT 4

Then  Joystick and Gamepad Tester confirms that the text file has been saved and it’s safe to quit or begin testing another device.

JAGT 5

I was impatient and clicked ‘Save’ before testing all the buttons, so the text file shows an incomplete test – I haven’t verified yet that each of the buttons gives a maximum ‘1’ when pressed and goes back to a minimum ‘0’ when released.

JAGT 6

I was intrigued by the two entries at the bottom for ‘X-Axis’ and ‘Y-Axis’.  I studied the device carefully, and could find no control on it which resembled a joystick, which is what an entry like this would be for: data from these sources wouldn’t just be a ‘0’ or ‘1’, but a number moving from perhaps as low as -255 to +255.  I’m assuming this indicated that the chip used in the device is capable of supporting a joystick, but this hasn’t been implemented.  Perhaps, if one knew how, one could hack the PCB which controls the buttons and add this capability.

*

There are two things worth mentioning about HID devices at this point.  The first is that, provided you leave the USB output leads intact, you can remove the circuit board from the original case, solder your own buttons and potentiometers to it and it will still be recognised as the same device by the computer.  This was the theory tested by the Cybersynth, which is basically a Theresynth, as described above, with the PCB removed from the Rumble Pad and put into a completely different case.  It doesn’t look like it any more, but the computer still thinks it’s a game controller.

Cybersynthsm

In fact, you can also do this with an old computer keyboard.  It’s possible to remove the PCB from these, work out which connections make which letters and wire these connections to your own buttons or switches.  I did this with the board from inside an old Apple keyboard (as described here):

Blueberry keyboardsm

It was very cheap, having been scrapped as being broken, but what was wrong with it was nothing to do with the electronics.  I took the board out, rewired it, and use it for controlling a looping program.

MIDI CPU insidesm

You may be able to tell from this picture – although the scale isn’t particularly evident – that the PCB inside this particular brand of keyboard is ridiculously large.  You could undoubtedly find a make with a much smaller board which would be more practical.

As it happens, I’m using this particular board for an application which requires letters as an input, and no remapping – i.e. ‘A’ is ‘A’, ‘B’ is ‘B’ and so on.  However, since the keyboard is an HID device, using one of the programs above, you could change the functions of the buttons and have a very large number of different control buttons available: the equivalent of 26 letters, 10 numbers, numerous punctuation keys; and programs will normally distinguish between lower and upper case letters, increasing the total number of controls even further.

The second thing to mention is that there are many PCBs on the market with circuitry on them to output HID standard signals, and allowing you to attach your own combinations of buttons, switches, knobs and joysticks.  People who make their own arcade games like them, so this is where you’re likely to come across them (on sites like this, for example).

Some of these are relatively inexpensive.  I got this one, which can encode 12 buttons and 2 joysticks for £8.00, complete with connecting leads for the buttons, joysticks and USB:

Zero Delay Encoder Board Rev2 -2

You have a free choice of what kind of buttons to attach, and using a board like this is easier than extracting and rewiring an existing game controller board

*

As for other types of controller: there are many.  This one by Nyko for Playstation – which I have in the collection, but haven’t worked on yet – combines the traditional game controller with a QWERTY keyboard:

Nyko IMG_1668

This one, the Airpad, is interesting because it contains a tilt mechanism which enables control by tipping the device up:

Airpad IMG_1667

You may notice something odd about the above two controllers – the funny connectors on the end.  Your computer probably doesn’t have sockets that shape.  This is no problem, though, as Playstation to USB adapters are easy to come by and not expensive.  This one cost less than £2:

PS Adapter IMG_1669

It’s also possible to find extenders and hubs for Playstation devices, and these don’t usually cost much second-hand on eBay:

Extension IMG_1255

Hub IMG_1561

Using PS3 (wireless) controllers is also perfectly possible.  There are drivers for Windows; later versions of Mac OS (from 10.6 upwards, I believe: see here for further details) have drivers built in, using Bluetooth.  Earlier versions of the Mac OS can work with a driver from Tattiebogle.

USB adapters also exist for XBox controllers, although replacing the proprietory connector with a USB plug doesn’t seem difficult,  according to this illustrated article.

[Edit: unfortunately, both the sites I used for this information are unavailable now.  I’ve left the link in case that site’s unavailability is temporary, and I have an image from the other one:

xboxcablemodpaintThis implies that the Xbox cables have wires using the standard USB colour-coding, so if the wire attached to your USB plug uses these standard colours, they can simply be attached like-for-like].

Once again, Tattiebogle provides a driver for wireless XBox controllers – although you’ll also need one of these wireless receivers:

wireless receiver2

Third-party receivers can cost as little as £5.

At the time of writing, the most advanced consumer-oriented controllers are the Nintendo wii and Microsoft’s Kinect.  The wiimote controller is a hand-held device which uses accelerometers and infrared to detect position and motion in addition to control by button-presses; Kinect uses infrared, cameras and microphone to detect spoken commands as well as hand and body positions from a distance.  I’ll be looking at musical uses of these two systems in the next post in this series.




andymurkin

December 2019
M T W T F S S
« Nov    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to follow this blog and receive notifications of new posts by email.