Guitar-to-MIDI project article

Started by Mark Hammer, November 02, 2009, 01:07:26 PM

Previous topic - Next topic

wordstep

to mikestorm
I sent a e-mail to you.

There are 2 files in the e-mail. One is wav, the other is mid.

My recording setup:
Guitar --> zoom ps-02 (complete clean) ---> guitar to midi --> midi to usb interface --> PC (Overtune 4.0)
The wav file is from PS-02.( cut and save in smaller size by goldwave)
The mid file is record by Overtune.

I do not have time to adjust the guitar sound and the setting in Overtune. So the result can be better. Feel free to use them.

potul

Hi guys,

I've been thinking about potential improvements to this project lately... 
If I compare this to the Sonnus G2Midi, the main gap is the fact that this project is not able to track pitch changes after the note attack. So no bends, no pullups, no hammerons, no slides. (well.. BIG hammerons should work)

The way the current algorithm works is not allowing this, because the pitch is not continuously tracked, but it is only measured during the initial attack of the note, and then only the amplitude is tracked to determine when to end the note or start a new one.

So the flow is something like:

Amplitude tracking -> New note detected -> Velocity calculation -> Pitch determination -> Amplitude tracking -> New note or end note -> ......

This is done this way with the assumption that at the beginning of the note, right after the pick, the fundamental frequency will be strong enough not to be messed by the harmonics. But if we continue to track pitch with the used algorithm (zero counting), at some point during the note decay harmonics will be strong enough to mess up things.

If I want it to be continuously tracking, I see 2 options: Modify the algorithm or add some hardware to do part of the job in order to remove the harmonics.

Regarding changing the algorithm, I've been thinking around other pitch detection techniques that can live with the extra harmonics, like FFT and Autocorrelation, but definitively there is not enough horsepower with the 16f88 to do such a thing.

Regarding adding some hardware, I was thinking on using something like the OC-2 fundamental extractor. This could give a better tracking, but would eliminate the dynamics, so no amplitude tracking anymore (no velocity calculation possible). A potential solution could be to combine the original signal envelope with the fundamental extracted by OC-2, using a compandor or something similar, so that we get the fundamental frequency but the dynamics of the original signal.
But after some thought, I think it would be easier to simply use 2 DAC channels of the PIC and input into them both the fundamental (from the OC2) and the original signal (or maybe an envelope of it). This way the PIC will still be able to continuously monitor pitch and amplitude.

On the other side, I'm trying to understand how the OC2 fundamental extractor works. I wonder if the same principle of fundamental extraction could be used on the software side, and avoid adding more hardware to the thing...

What do you think?

Regards,

Potul

Andre

Here are 2 small demo's of my Guitar to Midi build.

This demo shows the tracking and delay:
http://www.youtube.com/watch?v=zOiG9qEXN9E

This demo shows just a bit of playing around with it.
http://www.youtube.com/watch?v=SsWi7GWlPD8

potul

Good demos. Looks like it tracks pretty well, and the latency is not bad.

Jaicen_solo

Wow, i'm surprised how well that tracks actually! I'm even more interested in getting the project files now!

potul

Regarding my idea of feeding 2 different versions of the same signal into the PIC, it seems that (as usual), there's nothing new under the sun. Today I found this Tom Scarff's project
http://www.synthdiy.com/files/2008/pt_uc_ct.gif
It does exactly this. It is tracking separately the frequency of the signal and the amplitude, and trying to optimize the signal for each purpose before the ADC. One portion gets squared trying to retain mainly the fundamental, and the other is rectified to be used as an envelope.

I'm now taking a look at the source code to see if I find anything interesting to be reused.

regards

Potul

potul

Hi All,

I've had this in stand-by for some time while I was working on some analog builds...

This week I re-breadboarded this and did some tests.
I've abandoned the idea of adding the OC-2 tracking part, because after analysing in depth what the circuit was doing, I realized it was exactly (or close to) what the software is doing... So I would not expect any improvement from it. Instead I decided to focus on the software portion and try to improve it.
I have a first beta that implements tracking of hammer-on, pull-offs and slides. What it basically does is keep on monitoring the frequency after the attack of the note, and based on some logic decide if the note has changed. If so, the current note is ended and a new note is triggered.
I'm still having some issues on trying to distinguish a real new note from tracking errors, but looks promising.
When I'm satisfied with this modification, I plan to jump into a harder one, which is to enable bends. This will be more complex and may require some hardware mods in order to increase sample rate. I will keep you updated.

Potul

space_ryerson

Very interesting. Definitely keep us posted! I keep meaning to get into this project, but keep getting sidetracked.

potul

Well,

my modified code to allow slides/pulloffs/hammerons seems to work well. And I've added a switch to be able to change to the "normal" mode if desired.

But I tried to implement the tracking of bends, and so far it's been a failure. It seems that the system does not have enough accuracy for this. The question is, I don't know if it's a problem of resolution or a problem of the natural limitations of the used algorithm with a guitar signal.

Next step I'll try to speed up the PIC to have more timing resolution, and see if this makes a difference. But this will require quite a code re-write, as all the timings and lookup tables depend on the oscillator frequency. Next 2 weeks I'm on a business trip, so I will not be able to experiment more. When I'm back I will continue.

PD: If anyone is interested in the modified code (without the bend part), just ask and I'll send it to you.

Potul

potul

By the way, I was thinking on adding an "octave down" mode so that the midi signal is transposed one octave down. This would allow me to play a midi bass preset at the correct octave.

Any other feature you think could be added?

Potul

space_ryerson

The ability to use it with a bass was one thing I was considering. The ability to track bends would be great, simply so I could play the guitar synth line at the end of 'Ashes to Ashes' in my own home :)

Jaicen_solo

For sure, tracking hammer ons and pull offs would be a great boon to this relatively simple project, if the PIC is capable of processing that much info. How glitchy does it get in this mode? Having a mode switch is great by the way.
Don't forget, the early MIDI guitar synths like the GR700 sacrificed pitch bend to improve accuracy because the hardware just could not cope. Heck, the JX3p it's based on would freak out if you tried to use MIDI control with lots of MIDI information (trust me, I know!). I've found that pitch bends with latency really suck, they make it sound so sloppy and out of tune, I usually use my guitar synths in chromatic mode where available. I think a simpler option is an analogue input for a pitch bend pedal. Much simpler, uses MIDI commands (so it's faster, less processor intensive).That's teh way I would go for sure.
+1 for the octave switching, perhaps you could have an on-off-on for +/1 octave?

potul

Here you have the modified version of the code of this project I'm working on.

http://sites.google.com/site/potulfx/marketing-docs/G2Mplus.asm?attredirects=0&d=1
http://sites.google.com/site/potulfx/marketing-docs/G2Mplus.HEX?attredirects=0&d=1

The tracking of hammer-on, pulloffs and slides seem to work fine.
The switch to select mode must be connected to RA1, setting it to high or low depending on the mode (I think 0v is "legacy mode" and 5v is "hammer on mode")

In order avoid false pitch changes there is a rule, so if a pitch change is detected higher than a threshold, and no new attack is detected,  it is ignored. It is set to 5 semitones, but you can easily change it to a bigger value. The idea is that you usually don't do a hammeron of big intervals unless you're into tapping... Slides are no problem because the note is changing in 1 semitone intervals as you slide.

Note: This version is configured for MCLR pin acting as MCLR, because my programmer requires it. This means you need an additional conection of the MCLR pin of the PIC to 5v through a 10k resistor. If you want to make it compatible with your hardware you may need to change the configuration bits.

If you trie it, just let me know the results

Regards


jman 31

I'm not sure exactly how midi works, but does this encompass a range of the midi number/notes? If so, what range does it cover numbers wise. Say, looking at THIS CHART for example. You will have to scroll to see the entire list.

potul

The device covers all octaves in a guitar. If you plan to use it with other instruments (like bass guitar), the code needs to be adapted. Do you need the exact numbers? I don't remember by heart, but I can check in the code.

Potul

jman 31

Man that would be great if you get a chance! I am working on another project that I am going to try to incorporate with this, but I need to know the exact numbers. Don't go out of your way, but if you can I would greatly appreciate it! Also, I am using a PICkit 2 to program the chip. Do I still need the pull-up resistor on MCLR for your code?

Thanks,
J

potul

The MIDI note numbers of a guitar can go from 40 (E2 - 6th string open) to 90 (F#6 - 1st string 26th fret).
The program can handle this for sure. I think the code is able to generate midi notes from 35 to 94, but I'm not sure if the tracking algorithm will be able to track notes under 40 (E2), because of a limit of around 12ms in the tracking routine.

From my understanding, with the PICkit2 you don't need the pull-up resistor in the MCLR (but you have to modify the configuration bit).

Let me know if you need more information.

jman 31

Thank you so much for that valuable info!! That is just what I needed.

I do have another question. I know just enough about programming IC's to get the HEX file to the chip. I loaded the hex into PICKit 2 and here is what showed up. Below it is the default config bits. I have the LED's on the Guitar-to-Midi board flashing so I know that it at least loaded when I ran it, but I am getting no midi-out activity on midi-ox. I am using a midi-to-usb adapter with it that I know is working. I can only assume that the fuses are not set right unless there is a short somewhere on the board that I am missing.

Any advice would be greatly appreciated!




potul

If the 2 LEDs are flashing once when you power on the device, it means then that the program is loaded and working (this flashing is done by the program, so if the pic would not power on you would not see it). Try connecting the guitar and play... the midi activity LED should flash as well.
If this does not happen, the guitar signal is not reaching the PIC, so check the audio path from the jack to the PIC input.
If the midi activity LED flashes, but no midi in midi-ox, double check the midi out connections. It is a quite common mistake to connect the cables reversed in the midi out jack, because it is not very clear in the schematics if the midi jack is seen from the inside or from the outside.
Murphy's law causes that I always do it wrong the first time...

Let me know your findings,

potul

jman 31

Thanks again Potul. Both leds flash when I power it up, and I have both leds getting the signal from the guitar so it has to be after that. I checked over my midi jack traces and it is all correct. I just can't figure what I have done wrong. I can't find any shorts or breaks with my continuity tester. I am going to go back over all of the components and make sure I have them all in the right places. I think they are though.

Thanks for the info!
J