Monday, 15 May 2017

Light up guitar demonstration

So the light-up guitar is complete and ready to try out.


The chords and scales mode works really well.
And playing blues licks (with the blues scale selected) is great fun. As many guitarists already know, when playing a 12-bar pattern, it's quite common to play a major pentatonic melody over the one (I) chord, and a minor pentatonic melody over the four (IV) and five (V) chords. This is what gives the blues its distinctive "blues-y" sound (for you music theorists, it's the clash of a minor third over a major triad with an added flat 7th that really makes the blues sound like the blues, but the principle is the same).


By just noodling around playing notes from a scale you can get a nice blues-y guitar sound; coupled with a bit of rhythm, there's a very real danger of it actually sounding melodic!


Flicking the major/minor switch makes playing/finding chord tones really easy. Root notes are always in red. Thirds are in pale blue. When in "major" mode, the fourth degree of the scale is bright purple. So find a purple note, and the major third is immediately behind it. Slide into (or hammer on to) that note and you instantly get that blues sound.

My own personal arsenal of blues licks is limited to about three licks. But even then, playing those couple of licks with the fretboard lit up makes understanding how and why they work much easier. You can actually see when you're bouncing around the major/minor third, you can see as well as hear the effect of sliding or bending to a flat seventh, you can see why a particular lick sounds good over the four chord (because it has a fourth of the scale in it) and doesn't always fit well over the five chord.

From a learning point of view, it's a real success.
From a guitar point of view.... well, not so much.

For a start, I didn't do a very good job of clamping the fingerboard absolutely flat when gluing it to the neck. In fact, there's a tiny bit of a back-bow in the neck once it's on the guitar.
Which means I've had to really jack up the bridge and put on some super-heavy gauge strings, to try to get the neck to bow "forwards" a little bit.


with the straight edge sitting on the neck, you can see a slight gap between the ruler edge and the frets on the left, furthest away from the body. Unfortunately, this means the neck has a slight back-bow at around the fifth fret, causing lower notes to "fret out" and buzz really badly.

So although the backbow can (just about) be compensated for, it's at the cost of really heavy strings (13s on the highest E). Which, as you can imagine, makes playing blues-y licks, with lots of vibrato and string bending really tricky.

There's also a dodgy earth problem that needs finding and addressing.
It's barely noticeable when using a clean-tone amp. But add in a bit of crunch (I use the overdrive switch on my amp but the same effect happens with any high-gain effect pedal with any  kind of treble boost) and suddenly you can hear the additional electronics in the guitar signal.


When using the menu, there are audible clicks in the audio signal. But the best is when the LEDs light up. The PWM signal driving the LEDs sounds like someone blowing into an open-ended piece of drainpipe. Very peculiar!

So there we have it - a working light-up guitar. Of sorts.
It lights up. It makes finding and playing scales easy.
But it's an absolute pain to actually play.

Keith will just have to hang on a little bit longer - I'm already started on a new guitar neck which I'll make sure is created flat and not bowed. And maybe we'll try moving the electronics out of the guitar body and hooking up to a separate, dedicated box of tricks, well away from the pickups and anything else that might affect the audio signal....



Monday, 8 May 2017

Thwarted at the last!

After swapping out a couple of dodgy Nokia LCDs and some last-minute rewiring (to enable a 2000mAh lipo battery to power the whole thing as well as be charged from a regular phone charger) the back of our guitar scratchplate was looking a bit of a mess (ok, Keith, your guitar scratchplate)

We went from this....

....to this!


There's a lot to cram in there.
And even after doing some extra routing on the body


and tidying up the wiring (a little bit)


it finally came to assembling everything for the final dry fit.
Sadly, it didn't quite fit!


And it's a little bit late in the day to be running the router and hacking out lumps of wood from the body. So that'll have to wait 'til the morning. In the meantime, here's a final test, to make sure that the new wiring still works properly:


Everything works well;
The phone jack acts as a data connection for both midi and bluetooth data (not demonstrated in this video) as well as a charging point. The power switch allows you to flip between mains powered (the battery charges while connected) or battery powered. The second tone control has sneakily been replaced with a rotary encoder to navigate the menu. The major/minor flip switch lets you quickly and easily change between major and minor scales, while keeping the root notes highlighted in the same colour (red). All in all, it's pretty exciting.

Just a shame there was no time to get the router out and finish it off fully!

Thursday, 4 May 2017

Unity and TextMeshPro

I guess, since Unity "bought up" TextMeshPro and made it available for free with version 5.5 of Unity back in February, I'm probably one of the last to jump on board and give it a go.

Between messing about with Arduino, guitars and hall sensors, I've been playing about with Unity a bit too. I tried getting away from the whole "create the next awesome 3d blockbuster" and am looking to create simple, mobile-friendly games that should provide 10-30 minutes playtime. A bit like the old ZX Spectrum games of yesteryear (though I shudder to think how many hours I spent trying to get Mr Head and Mr Heels to work together properly in 1986).

Anyway, a simple 2D turn-based strategy game is currently in development (although it'll probably never be anything more than a vehicle for trying out different coding techniques,so don't expect a release date any time soon) and - like most game framework prototypes - is filled with coder art, empty graphics placeholders and lots of console debug messages.

As anyone who has worked with Steve will know, it's the graphics and look-and-feel that can elevate something pretty mediocre into something amazing. And that's what happened last night, when I swapped out my simple Unity GUI Text for some TextMeshPro glyphs.

Here's an example. It's dynamic text.
At certain points in the turn-based game, your turn can be interrupted by your opponent (a classic example of this is when a player leaves a character on "overwatch" - meaning "if anything crosses your field of view, shoot at it immediately").

Whenever a player is interrupted, we wanted a nice big on-screen display to inform them of what was going on. A simple 72-point dynamic text box just didn't seem to cut it. But swap out the text object for a TextMeshPro mesh and suddenly things look a lot prettier, very quickly


Just simple stuff like putting a gradient on some text can make it look so much better than a simple flat font. And TextMeshPro lets you define up to four gradient points (to get that shiny metallic look on each letter if you like).

Also, when you scale a text object up in Unity (for example, to create a "bounce-up" effect) even TTF fonts become pixellated at larger sizes. No such problem with TextMeshPro!

It's such a massive improvement on the original UI Text, it's no wonder Unity bought it up and now offer it for free as a Unity Essential. It's a great asset and a quick and simple way of making even boring stuff look pretty onscreen!

Wednesday, 3 May 2017

Assembling the light-up guitar

Things have slowed down a little bit, as assembling the guitar has proved to be a little more difficult than designing the electronics and writing the firmware!


The first thing to  do was make a note of the existing connections - just in case anything accidentally gets snipped or un-soldered. Then we whipped the scratch plate off and set about it with a Dremel and a small routing bit to make a window for our LCD display.


That triple-layered plastic made a right mess! Copious amounts of hot glue ensures our screen shouldn't be going anywhere, any time soon.


We took out the second tone knob (the one that's almost always left fully dialled to ten) and replaced with a fixed-value resistor. After all, the tone knob on these cheap Strat copies doesn't boost any frequencies, it can only choke them. And what's a Strat if it's not got that bright, jangly sound? Why would you want to dial that down anyway? So off came the pot, to be replaced with a fixed 220k resistor. In it's place we fitted a rotary encoder.


After cutting down the shaft and putting the tone cap back on, you'd never even know it had been modified if you weren't looking closely! Also added a stereo jack socket which we'll use to connect to the power/ground/RX pins of the microcontroller to allow data to be pushed into it at a later date.


Now for a really important part - lining up the neck and bridge. On a previous build, we missed this step out; fixed the neck, drilled the holes for the bridge, installed the tremolo system and found that the bass strings were almost in the middle of the neck and the high treble strings were fretting out, as the high E string was barely on the neck!

No chance of that happening this time around - some lengths of cotton allowed us to see where the strings would end up, to ensure we got the bridge in the right position this time.


You can see where, under the scratchplate, we had to do some extra routing to create a cavity for the LCD screen and 3000mAh lipo battery. A quick test fit made sure that everything was going to fit inside the cavities when assembled.


The firmware isn't quite finished yet (need to add in a couple more fancy patterns and recreate our earlier volume meter effect) so we're not quite ready to close it up and fit the strings. But that time is coming. It's coming real soon......

Saturday, 29 April 2017

A quick thanks to Jason for the MIDI-in schematic (and opto-isolators)

If you're having trouble with your MIDI (as we were, trying to get our input working through an opto-isolator) there's only one person with the wealth of experience worth asking and that's Jason. He quickly identified that the random spare-part left-over opto-isolator we were trying to use for our MIDI-In simply wasn't up to the job.

Apparently there isn't a great range of opto-isolators to work from for handling MIDI. Most are simply used as switches. And while its' true that serial data is just flipping a switch really quickly, we need an opto-isolator that can switch on and off quickly enough to keep up with the data rate.

Jason kindly gave us a couple of 6N138 isolators and an updated schematic to work from.


The isolator neatly inverts the MIDI logic (in MIDI a zero is a high signal and a one is low) as well as holding the RX line high when idling - just how all good UART peripherals like it.

With this slight alteration we got our MIDI In working reliably - with the added bonus that we can now hook up and MIDI source, powered from anywhere; the isolator means there's no need for a common ground or similar reference. Which is just as well - to date we've tested our light-up guitar fretboard by loading MIDI files on the laptop and playing them through a usb-to-midi interface conntect to a second usb port. This means the serial port and the MIDI signal have both been generated from the same source.

But the ultimate test of our MIDI capabilities will be when we plug the guitar into a portable keyboard, press a key and see which of our frets lights up!

Friday, 28 April 2017

Displaying MIDI notes as fret positions

To convert scales and patterns into LED combinations we've made quite extensive use of spreadsheets. Boring old boxes of numbers have made displaying patterns of dots much easier.

The guitar fingerboard LEDs have been wired starting at fret 15, low string E, passing through each string of the 15th fret (E, A, G, D, B, E) then continuing with LED number six representing 14th fret low E, LED seven is the 14th fret A string and so on.

So we first drew up our patterns in a spreadsheet, coloured the boxes (to make them easier to identify) then transferred these patterns into byte arrays.


Anyone familiar with guitar scales might see the pentatonic minor box one starting with the A root note on the fifth fret in the image above.

After giving each note of the scale a "colour palette index", we stored each pair of strings in a single byte. So the low E string is the upper nibble of the first byte, the A string the lower nibble of the first byte, the D string is the upper nibble of the second byte and G is the lower nibble. The B string is the third byte upper nibble and lastly the high E string is represented by the lower nibble of the third byte.

So reading the scale chart from the bottom right corner, reading upwards, then from right to left, our fifteenth fret LED colour index values are 7(E), 2(A), 0(D), 0(G), 4(B), 7(e) (zero represents no dot to be displayed). The fourteenth colour index values are 0, 0, 5, 1, 0, 0.


You can see that by splitting each fret/string position into a single half-byte 0-F, when storing the values in hexadecimal, we can actually "see" the dots in the code. The first three byte values, for the six strings on the fifteenth fret are 0x72, 0x00, 0x47. The correlates directly with the dot patterns in the spreadsheet 7(E), 2(A), 0(D), 0(G), 4(B), 7(e)

Using a similar technique, we listed the note values of every fret position for every string.


Then after a quick Google look-up, recorded the MIDI note value for each note at each fret position, for each string. Recording the MIDI values in the same order we've wired the LEDs, our array of values begins 31, 36, 41, 46, 50, 55

These are the midi note values for G2, C3, F3, Bb3, D4, G4 which happen to be the notes on the guitar at the fifteenth fret.


Since the seven LED is at the low E string position on the 14th fret, our array of MID note positions continues 30, 35, 40, 45, 49, 54. We continue recording each note value in our MIDI array, all the way up from fret 15 to fret zero (open strings).

const byte midi_notes[] PROGMEM = {
  31,36,41,46,50,55,
  30,35,40,45,49,54,
  29,34,39,44,48,53,
  28,33,38,43,47,52,
  27,32,37,42,46,51,
  26,31,36,41,45,50,
  25,30,35,40,44,49,
  24,29,34,39,43,48,
  23,28,33,38,42,47,
  22,27,32,37,41,46,
  21,26,31,36,40,45,
  20,25,30,35,39,44,
  19,24,29,34,38,43,
  18,23,28,33,37,42,
  17,22,27,32,36,41,
  16,21,26,31,35,40
};

Now when we receive a MIDI note value, we can loop through this array to work out which LED corresponds to that note and light it up (or, if it's a note off message, turn it off).

void addNoteToFretboard(byte note, int col_index){
  // loop through all the midi note values in the array
  // and wherever there's a match, light up that LED with
  // the appropriate colour index
  byte p;
  CRGB c = RGBColour(col_index);

  for(int i=0; i<96; i++){
    p = pgm_read_byte(&midi_notes[i]);  
    if(p==note){
      led[i] = c;
    }
  }
  FastLED.show();
}

(in the example above, we have a function into which we pass an index number and it returns a CRGB value for a specific colour)

When hooked up to a MIDI source, the result looks something like this:



That's the opening sequence to Metallica's Enter Sandman. If you already know how to play the song, you'll recognise the familiar patterns around the 5th, 6th and 7th frets. For some notes, more than one dot appears. That's because there's more than one place where you can fret the note. Matching colours mean "it's the same note" so you'll see a red dot appear at both the 6th fret low E string and 1st fret A string at the same time. You can choose whether to play the riff on the 6th/7th fret, or on the 1st and second - it's up to you!

At the minute there's no differentiation between channels - you need to turn channels on and off using your MIDI sequencer - so when we wound the song on a bit and played it complete with distorted guitar, bass notes and drums/hi-hat, it looked a little bit crazy!




However, as a performance piece, we think it looks pretty cool too!

Thursday, 27 April 2017

Messing about with MIDI and RealTerm vs Putty

While our guitar neck glue is going off, and since we've pretty much got most of the LED goodness working (that'll probably have to be demonstrated in a later post, once everything has been stuck together) we thought the intervening time could be spent adding some extra cool functionality to our light-up guitar.

To date it allows you to select pentatonic or diatonic scales in any key, include extra notes (such as the "blue note" and flatted/major thirds in the minor pentatonic, major fourths in the major pentatonic and so on). You can also have it display all the major C.A.G.E.D chord shapes in any key too (we really should have made a demo video before this post!)

EDIT: made a quick demo video. Here you go -



In "offline mode" you can display different scales and CAGED chord shapes in any key. A simple flick switch will allow you to quickly change between major and minor (for those pesky I-to-IV and IV chord changes in a 12-bar song!) And, of course, there are some fancy patterns just for show as well!

Now most guitarists who know how to play guitar recognise that it's not just a Guitar Hero clone - where frets light up and if you match them with your fingers, you'll play a tune. By lighting up a particular scale (and different target notes from that scale) you can improvise blues-based solos more easily just by wandering between the dots. But for anyone wanting to play along to their favourite song, we figured it'd be a massive amount of work creating some software that allows you to input tab in such a format that you can then send to the guitar to get the frets to light up.

So when MIDI was suggested, we figured.... hmmmm.
It's always tricky knowing which of a possible five places you should place a dot for a specific note on a guitar. But if we could take the incoming MIDI signal and simply light up all possible alternatives, it would leave the player to decide which fret they found most comfortable to reach for (instead of some crazy algorithm going rogue and forcing you to whizz up and down the guitar neck at lightning speed!)

So we needed to get to grips with handling MIDI in signals (not the infinitely easier generating MIDI out messages). The first thing was to hook up a usb-to-MIDI device so we had an independent way of generating MIDI messages.
Now MIDI uses inverted logic (zero is represented by a HIGH signal, a one is a LOW signal) but other than that, it's simply serial data sent at a funny baud rate. 31250 bps to be precise.

So we downloaded a free MIDI sequencer (Anvil Studio looks gnarly and draws slowly, but it can create, edit and play MIDI files to a MIDI device, so it was good enough for this test) and grabbed something a bit more sophisticated than our usual serial favourite Putty - a little program called RealTerm.

Putty is fine for sniffing data, but RealTerm makes playing with serial data a doddle. Not only can it display the raw incoming data, but it has a myriad of options for decoding it too. We went with hex[space] so that we could visualise the MIDI values in hex, instead of trying to decode non-printable ASCII characters (as Putty likes to do). It's much easier to see what a value like 0xB4 means than a checkerboard patterned glyph!



We hooked up our MIDI out to a socket and introduced an opto-isolator to both isolate and invert the MIDI signal from our usb-to-MIDI device. The circuit was something similar to this one (with a few resistor values changed to match values we had lying around)


The strange this is, we got no data from the circuit. Absolutely nothing.
After fiddling about for about an hour and getting nowhere, we took a bit of a risk. Since the MIDI signal was being generated by a laptop usb port, we figured it wouldn't be more than 5v. So we connected the MIDI out directly to our serial in.....
Instead of a puff of blue smoke, we got serial data appearing in RealTerm. Success! (although we did have to invert the signal, with midi pin 4 connected to ground and midi pin 5 to our serial RX.


It might look like gibberish, but it's pure, raw, MIDI data!
The excellent MIDI resource site (https://www.midi.org/specifications/item/table-1-summary-of-midi-message) gave us an easy way of decoding the data - and thanks to RealTerm's hex view, we could even do it onscreen!


The MIDI messages we're interested in are the note on and note off ones. All other messages can be discarded. Most (but not necessarily all) MIDI messages arrive in three-byte packets. Luckily, the MIDI format also makes it really easy to decode.

The first byte of a MIDI message "packet" always has the first/MSB set to one. The first byte is also the "command" byte, telling us what action is to be carried out. Subsequent bytes, containing data values always have the first/MSB bit cleared (set to zero). So it's dead easy to find the start of each message - just read in bytes from the serial port and as soon as a byte has it's first bit set, you know you're at the first byte of a new packet.

We can see from our received MIDI data, we get a repeating "B" message, every three bytes at the very start. This is the MIDI device sending a "control change" message for each channel being used by our MIDI sequencer (since 0x0B in hex is 1011 in binary, which matches the pattern for "control change" in the MIDI specifications). The second character of the first byte is the channel number (from 0-15). The following two bytes are information about how the controller is set up (volume, left/right balance etc).

For the messages we're interested in,  we can just look for a message beginning with 9 (note on) or 8 (note off). If we dump our serial data capture into notepad and split the data into three-byte packets, it becomes much easier to read.


Our first musical MIDI instruction is 90 28 7F

This decodes as:

  • 9 = note on
  • 0 = channel zero
  • 0x28 = decimal 40 = octave1 note E
  • 0x7F = full volume


(note that normally we'd expect anything "full" to be 0xFF but in MIDI messages, the data bytes always have a leading bit zero, so the maximum value we can achieve is 0x7F)

And as anyone who has ever played "Enter Sandman" on a guitar will tell you, the first note struck is always the low E string. Unless you're Bill Bailey....



Things look quite promising so far - so what's next?
The next message is 90 34 7F. That's another full-volume, note on message, this time for note 0x34 (which is decimal 52, or octave 2 note E)

Following that comes 90 37 7F. Another full-volume note-on message, for note 0x37 (decimal 55, or octave 2 note G).

Now comes our first note off message - 80 28 50. It's that first note, low E. Which tells us that all three note have been ringing out until this time. Again, anyone familiar with the opening bars of Enter Sandman (that bit with the clean guitar tone at the start) will recognise that this is the case.


The reason the low E stops is because, when playing this on a guitar, you normally fret the low E string to play the two-note decending riff. Sure enough, the next messages representing the next two notes are

90 2E 7F
90 2D 7F

Even without decoding these to work out what the notes are, we can see that there's a half-step change in tone; whatever note 0x2E is, the next note is 0x2D, one half-step/semi-tone below it. Being familiar with the tune, we already know that this is correct!

What's interesting to note (although, to be honest, maybe not unless you're a bit of a music nerd) is that if these notes had been generated by a guitar, there'd be a note off between the decending tones. That's because both notes are played on the same string. There's no way that you could get both notes playing, unless they were played on two different strings (and just about everyone who's ever played Enter Sandman on a guitar normally plays it by moving down a fret on the same string). In our MIDI playback, somehow both notes are ringing out at the same time. It's only a few bytes further on that we see the note off message for 0x2E, followed a few bytes later by the note off message for 0x2D.

Our screenshot belies the fact that these on/off messages can appear one after the other, almost instantaneously. But it's just interesting to note that this tune was probably played out on a MIDI keyboard (where it's quite possible to sustain two notes next to each other) and the player's inability to get their fingers out of the way quickly enough has lead to some notes sustaining for slightly longer than they would if played on a different instrument.

Anyway, all that aside, we've now got a way of reading incoming MIDI messages and decoding them into note on and note off messages. In the next post, we'll look at how we can use this data to display the notes on our guitar neck....