I tried to speed up the processor to its max using an external cristal, and then try to do some filtering/averaging in order to get a stable pitch detection that could be used for bends,.. but never got anything satisfactory.

I still have a the hope that something could be done to improve the pitch detection algorithm, but I'm running out of ideas.

My reason for asking is I'm runninng a smaller project that detects guitar pitch (though weirdly I'm detecting when pitch *hasn't* changed.....don't ask!). I was pondering having a pop at pitch to midi inc pitch bends etc ....but if you're struggling with the latter, chances it'd take a bit of my time (which I haven't got a lot of spare capacity at the moment)

Hi, I've followed with interest your respective comments on the EPE article. Having purchased a MODUS G2MIDI and been properly disappointed with it, I built the unit in the article, and as it stands it is very good. One of the aspects you have discussed has been pitch bending, and in fact I used to filter out the annoying tidal wave of pitch bend messages from the Modus unit. Mostly I play finger-style and only bend for stuff like the blues. I'll be reckless here and say that MIDI electronics will NEVER be able to reproduce the subtleties of guitar string-bending, especially on a modest little engine like the 16F88.

I too have hacked the source and re-coded it to use the 8Mhz clock rate, though upping the pre-scale rate for TMR1. As you know the timer value is divided and then interpolated in a look-up table, which contains a handful of same-value entries for a small-range of the TMR value. Possibly it is here that you should look for a method of detecting bends. Currently all the multiple-entry table does is save face for either an out-of-tune string, or inbuilt timing errors in the code, but the value that is used to index the table could be used as an indication of percentage bend, providing that an accurate setup, and tighter code is implemented.

For a much simpler solution (and one that might be deemed a work of the devil) can I mention Whammy Bar? Implementing a two-pot (like a joystick) whammy setup and using this as a controller will get round all of the niggly problems mentioned so far. The use of a whammy bar in the hands of a very skilled practitioner can be every bit as soulful and expressive as string-bending. Examples include good ol' Hank Marvin, who can make a guitar sound exactly like a human voice if he chose to. Personally, my whammy technique is rubbish, so I don't use it, but might if there wasn't the choice.

A couple of other points that have been raised are to do with detuned strings. Currently the initial 'window' for detecting a working trigger level and velocity is nominally 12ms - according to the authors code comment. I measured this window and it was nearer 15ms, so dropped 'D' tuning and the like will still work. I tightened mine up a little by tweaking the loop count. This nominal 12ms is a broad brush - set to accommodate the lowest string frequency. A window of just under 4ms is all that is necessary for the 'high' E string. On my home-made pickup each string has it's own coil, and I'm putting together a 6-channel version of the circuit, but using only one (more powerful) PIC, consequently I've trimmed these 'windows' to a proper length for each string, in an effort to cut down on latency.

One other thing I noticed was that as I'm using high-gain amplifiers (the coils are relatively insensitive) residual high-frequency spot noise on the input to the PIC was causing it to omit the MIDI-OFF sequence. I slugged the op-amp feedback resistor with a 1n5 capacitor (NOTE my final op-amp has a 100k feedback resistor - the article value is different) so that the response starts to roll off above 1200Hz (highest note on the guitar I use)

...As you know the timer value is divided and then interpolated in a look-up table, which contains a handful of same-value entries for a small-range of the TMR value. Possibly it is here that you should look for a method of detecting bends. Currently all the multiple-entry table does is save face for either an out-of-tune string, or inbuilt timing errors in the code, but the value that is used to index the table could be used as an indication of percentage bend, providing that an accurate setup, and tighter code is implemented.

That's in fact what I implemented in the code. And it's working in the sense that it detects percentage of pitch, and responds to pitch changes. The problem is accuracy. Most of the notes are detected as bended even if they are not, and pitch fluctuates. The end result is an out of tune MIDI signal that sound horrible...The problem is the device accuracy is good enough to be able to distinguish semitones, because these innacuarcies get corrected by the lookup table and rounded to semitones. But when you try to go to semitone cents, doesn't seem to work.

Anyway, I've seen some projects implementing a guitar tuner using a similar PIC, and I assume these require a sub-semitone accuracy, so I will take a look and see if I can find anything that could be applied here.

Yeah, I get what you are saying, and this brings me back to my assertion regarding the almost impossible task of synthesizing guitar string-bending in any realistic way. We get used to applying just the right pressure behind a fret to get the note on 'perfect' pitch (after years of practise and getting to know a particular instrument) and this is a cognitive process that is well-nigh impossible to duplicate using the comparatively primitive system we are discussing.

Your comment: Anyway, I've seen some projects implementing a guitar tuner using a similar PIC, and I assume these require a sub-semitone accuracy, so I will take a look and see if I can find anything that could be applied here.is interesting, but I doubt whether anything more useful than what we already have can be found. By far the most accurate and useful guitar tuner project I've seen, used a selectable bandpass filter and frequency-to-voltage converter set up, but these type of instruments are too specialised to be useful for what we want - an accurate repeatable note value output for any string/fret combination, plus information on any bend applied.

My experimental setup tries to obviate some of the problems in the following ways:

1. Each string has it's own pickup and amplification chain.2. The guitar fretboard/strings are also scanned as a matrix. (This needs each fret to be wired as a 'row', and each string as a 'column') This gives an accurate and consistent note value for any strings fretted.

Using the above in combination with some firmware, some of the problems go away. For example:

a) We always know which string is being plucked, irrespective of the output frequency, hence any 'notes' derived from a particular string that are out-of-range for that string can be ignored.b) The software can recognise when a string is being bent, as on initial fretting/pluck, discrepancies between the actual and 'desired' unbent pitch can be measured and stored, allowing an easy calculation of subsequent percentage bend thereafter.

Downsides are of course the relative complexity of the hardware/software, and irreversible surgery required to the guitar. At this point I'm still working on the project, and I bought a second-hand Fender Squier Acoustic (suits my fat fingers) for £35 (GBP) on which to implement the prototype. Currently this instrument looks even worse than some of the other FrankenGitbox stuff I've produced, but ultimately I'm aiming for a relatively acceptable solution that is not obtrusive in any way.

When I have a fully-debugged and usable system, I'll be publishing details on my site(s). I am still fiddling with the EPE code at the moment, but will publish any improvements I have to this in the meantime.

yeah, for sure the hex pickup can help a lot, and it can allow for polyphony as well.The idea of "relative" bend is interesting. From what you mention, I understand that your algorithm assumes the note is always pluck unbent, and the bend happens afterwards. Althuough it covers the most typical uses of bending, there are some cases where the note is plucked already bent. Anyway, if it works it's an interesting approach.

Hi,Yeah, as far as it goes. However, because the fretboard is scanned, as soon as you fret a note, it is 'recognised', and it's notional absolute value calculated and stored. What you do with this is up to you. In fact it is not necessary to pluck the string/strings before having it/them heard - a bit like tapping, and this is one weird way to play, though I have found it strangely pleasing. So, the string/fret combination is known before you either bend or pluck it, therefore pre-bend is entirely possible. The key to making everything work 'in tune' is knowing the absolute string/fret combination as I hinted earlier. As it is at the moment, because the note forming is being done in duplicate, but different systems, I can play soft string (MIDI) chords by just fretting these, and by plucking a string or strings have these play separate MIDI (on another channel) and/or 'normal' mag. pickup through an amp. Add on a peizo pickup for good measure and the guitar can sound like an orchestra.

To clarify. In the above the fretboard/string matrix scanner software/hardware maintains a set of lists. In the following, I've used the word 'key' to mean a string/fret crosspoint as I haven't a short alternative. Constant scanning of the fretboard is done, and as string/fret combinations are detected they are put in a 'keylist'. At the end of the scan, this keylist is compared with a copy of the previous 'keydown' keys, and any duplicates are removed from keylist. Next, any keys in 'keysdown' not found in the newly scanned 'keylist' are marked as 'keyup' and put into 'keyuplist'. Finally, any new 'key' down is added to 'keysdown'. All of this happens after each full scan of the fretboard. The foreground process examines the keysdown and keyuplist and can, if required, generate MIDI ON or OFF. All of this can happen without plucking any strings.

Adding the multi-head pickup and processing the output from this augments and/or controls the above process, and the combination is very powerful. However, as I said earlier, this is at the expense of some complexity. But... I love messing about, especially with hardware and PICs in particular, and I don't have a problem coding stuff, having been in the business since 1979.

I hope this clarifies some of my thinking aloud.Regards from Joe.

Logged

Belief in Divine Intervention shown to be worthless, so I've done this stuff myself.

Hi,I've posted two oscilloscope dumps showing PEAKS and TIMING routines working with an upper open 'E' string pluck, on my site joebrown.org.uk. I've also detailed the removal of the software loop in PEAKS and replaced this with TMR0. Full source-code project is also given.

I finally got my boards made up for my add-on to my Midi triggered LED kits. Works great thanks to Potul customizing the firmware for me. I hope to have a video of it in the near future, but in the meantime here is a video of my drum light kits in action by one of my customers. Midi Knights Video

Dear all,I’m working daily with PIC using ‘C’ language, so I’m interested to add my help to this project.Reading the posts I have not understand which hardware and software to use.‘potul’ has posted ASM source, but it seems that is running on a different hardware than I have found in ‘pt_uc_ct.gif’. I’m wrong?Can anybody explain to me the algorithm to recognize the note pitch?Thanks, and sorry for my bad English

I am sorry to be a bother, but I have one more favor to ask you if you have the time. I tried to get your .hex code for the G2MPlus that you wrote but I can't get it to work with the PICKit 2. When you wrote that modified code for me you did something that made it work with the PICKit 2, is there any chance that you could do the same for the G2Mplus? If not, no problem, I know you have done a lot for me, but if you can I would sure appreciate it!

I have a problem that I just noticed though that has nothing to do with the programming. When I run it into my amp I get a kind of clicky noise every time I play a note. It is only just the brief period at the very beginning of the pluck of the string. Almost sound like an electrical staticy click if that makes any sense. Does anyone have any idea what could be causing that? I tried swapping the TL072 with a different one, and I even checked my original prototype. They both have the same click with every note palyed. I wonder if it is the layout of my components or if someone else has had this issue. Any advice would be greatly appreciated.

Just for a test, I removed the PIC16F88 and the noise went away. It still had power to it and everything was treated the same except the chip being removed. The "click" seems to coincide with the led's flashing.

I tried another experiment today. I put an unprogrammed pic16f88 into it and no click. So something in the wiring of the chip or like you said "filtering" must be causing it. I am going to breadboard the original schematic today and see if I still get issues. If not then it will have to be in the small changes that I made. In the meantime, here is my revised schematic. SCHEMATIC