Is anyone here an expert in PIC?

[Mick Bailey]

A while ago I built a PIC-based guitar-to-midi interface which now works really well. Actually it feeds an Arduino midi-to-CV interface and overall has no problems with glitching or mis-tracking. The problem is the acquisition time on lower notes, resulting in unwanted latency due to the waveform's cycle time needed to determine the frequency. This happens twice, as the initial calculation is not saved but needs to be recalculated to complete the process. Higher frequencies from about the halfway point upwards in the guitar's range are OK and not really noticeable.

I discussed this on another forum where someone had done some other work on the design but had no further interest in putting any more time into reducing the latency. I wonder if anyone here has the expertise in assembler/PIC and the time to analyse what's going on?

If so, I'll post the source code and Schematic etc.

[Pixel]

It has been decades since I worked with PIC but I do have experience with it and assembler. Most likely this is beyond my abilities but I would read any forum discussions or look at code if you wish. From your description of the problem I would guess it would be difficult to solve without major rework.

[Mick Bailey]

Thanks. Here's the magazine article describing the circuit on page 38 https://www.google.com/url?sa=t&rct=...Srryuaig9S6grF

See the discussion from post #15 on Stompbox Forum where the detection process is further explained https://www.diystompboxes.com/smffor...topic=128583.0

[glebert]

Based on the DIY thread it sounds like the note detection is done in the time domain? Can this handle polytone at all then? I would think doing the note detection in the frequency domain will be much more robust and quicker to detect frequencies, but the amplitude scaling may be problematic. Also don't know if your PIC has DSP, I guess some do(?) I've never actually seen a PIC used to do anything "advanced," more like keyboard controllers, etc, but they are certainly not my field.

Note: corrected an error in my first sentence. Meant time domain.

[Pixel]

I can understand what the assembler code is doing but haven't got the slightest inkling of why it does it. I don't have any technical knowledge whatsoever about detecting or identifying notes. From that perspective I don't see any obvious optimizations that would solve the problem. Since the problem occurs only on low frequencies I actually don't think fixes in the code or faster processor or faster adc, etc will help. The algorithm is the issue. The only suggestion I have is to tune the guitar higher and change the lookup table to lie about the notes played.

[Mick Bailey]

I forgot to include the code, which I've now attached.

The latency arises from the period of the lower note frequencies so yes, a faster processor doesn't change things. The setup is to control a synth using CV and gate/trigger outputs. If velocity is needed for the MIDI output a constant value could be used. Potul notes "The pitch detection uses data from the amplitude detection algorithm, so amplitude must come first. Maybe the algorithm could be rewritten to do both concurrently, that's something that deserves a spin".

With this particular design time and frequency amount to the same thing, but is a complete cycle needed in order to detect the frequency? It seems to me that sampling a half cycle would give the waveform period, but I may be missing something. This isn't a polyphonic system - that would need six of the circuits and a hexaphonic pickup.

Here's a clip of someone demonstrating the latency and tracking ;

https://www.youtube.com/watch?v=zOiG9qEXN9E

https://www.youtube.com/watch?v=SsWi7GWlPD8

[Pixel]

I have already reviewed the source code from the magazine and this code is identical. I wonder if it would be possible to just ignore half of the signal all the time. Just find peak high and peak low is always zero.

[Pixel]

I guess you can't throw away half the signal because then you would have to wait during the "off" period. But you could run it through a bridge rectifier so that you don't lose half, it is just flipped. Then you can just determine the frequency almost as before except in half the time. Does that make any sense?

You could do it in software by figuring out which way the signal is going when it crosses zero as well.

[Mick Bailey]

The more I think about it, the more I like this idea. Also, I've been thinking again of doing the whole process in Arduino. At the moment I'm using PIC to convert the guitar to MIDI and Arduino to convert MIDI to CV, which maybe adds to the latency.

[glebert]

You should be able to do FFT on Arduino for note detection if you wanted to dabble in the frequency domain.

[Pixel]

The more I think about it, the more I like this idea. Also, I've been thinking again of doing the whole process in Arduino. At the moment I'm using PIC to convert the guitar to MIDI and Arduino to convert MIDI to CV, which maybe adds to the latency.

What programming language are you using on the Arduino? It makes good sense to do it all on the Arduino if you already have it. Programming a PIC is always like doing work because you can't get away from doing everything at a very low level due to resource restrictions. The Arduino would be a lot easier and more fun.

I know nothing about MIDI or CV but perhaps you can go from guitar to CV directly. In any case you will ditch latency just not having the PIC and Arduino talking to each other.

[Mick Bailey]

I'm using C++. I'm not good at it, but can just about get by by looking at the syntax reference and what others have done. Arduino is quite good due to the extensive library functions (such as the DAC handler). I can think of a few ways to detect the frequency using an Arduino Nano, and the lookup table for converting the guitar notes to feed to the DAC is already specified. I don't know at this stage how to link the two. Of course there's also the detection process for a new note (to generate the gate/trigger). Eliminating the MIDI conversion could make it much easier to implement continually varying pitch changes to allow for bends, vibrato or slides - that would need some different thinking from using a lookup table.

[Pixel]

Writing C++ well at a professional level is very difficult. Writing C++ that just works is not difficult at all because C++ does not enforce many/any good programming practices. Since you are interested in having this project do more than it currently does I would recommend you work your way through an introductory C or C++ programming course. The time investment will pay off in the long run.

If you want to take baby steps you could use the signal processing bits of the PIC project to make the signal easier to work with. By that I mean all the hardware up to but not including the PIC. You could then port the existing PIC code over to Arduino. However that signal pre-preprocessing may prevent you from implementing the advanced features on your wish list.

Ideally you forget about the PIC and dive into the libraries available on the Arduino.

[Mick Bailey]

I have a simple but effective fundamental extractor circuit that I used as an input for an octave divider and it tracks really well and is instant. It gives a 1:1 square wave output and I was thinking this could be used as as a digital input, which simplifies the signal processing side. I should be able to get a sub-15ms read of the lowest guitar frequency this way using the timer function. This would be a vast improvement on the existing setup and be perfectly acceptable. Also, it may be quick and easy to use a PWM output through a simple filter to get the DC control voltage, rather than using a separate DAC (Arduino Nano doesn't have an inbuilt DAC). I don't yet know if this would be accurate enough compared with a12-bit DAC.

There's some really good code for FFT on Arduino, but it takes up all of the space. I want to stick with Arduino if possible because they're cheap, small, really easy to use and I have a bag of Nano R3 boards I got cheap.

[Pixel]

If you have a bunch of Nanos you could split the processing up between a few of them. You could splice together a really cool Franken-machine.

I don't really want to mention this because I want you to build a cool new thing...but the swarm of Nanos thing just made me realize that you don't need to adhere to the MIDI standard. You could up the speed of your existing PIC to Arduino link right now and see if that fixes your problem.