Polyphonic Guitar to MIDI VST/AU "MIDI Guitar"- BETA TEST

[AdmiralQuality]

Latency has been greatly reduced (from ~25ms with v0.6.x to as low as 8ms with v0.7.x)

Curious. Can you share your methodology for how you measure its latency? And in which configuration do you do this test? Stand-alone VST host? Stand-alone MIDI generator? Plug-In VST host? Or Plug-In MIDI generator?

[ariajazz]

ariaJazz, karozas,

Hope your scanning issues are fixed with 0.7.2.
I've yet to experience stuck notes myself. It must have been loosing some audio frames - maybe you are cpu limited?
0.7 is certainly harder on the cpu - but i think we can optimize it in a 0.7.3 update.

Well not in my case, my system is Athlon II x2 270 (3,4GHz) 4Giga RAM. I can have several instances of amp sims and soft synths at the same time and CPU usage hardly reaches 60-70%. For safe performance I use 128 latency buffer. I can go further lowering latency. I will be testin v 0.7.2 tomorrow

[memyselfandus]

the newish "trial pop up" thing Sucks for testing. keeps popping up and stopping the sound while I am testing. especially in reaper when I leave the midi guitar screen to futz with a vst plugin. other than that I am blown away still.

[JamOrigin]

the newish "trial pop up" thing Sucks for testing. keeps popping up and stopping the sound while I am testing. especially in reaper when I leave the midi guitar screen to futz with a vst plugin. other than that I am blown away still.

Oh, thats not supposed to happen! - you activated it with the license file? or do you get a screen upon startup where you choose "trial"?

[wasi]

Scanning in standalone 64bit keeps popping up another instance and then closing it again here, I assume once for every scanned plugin. 32bit works OK.

Still, Alchemy, Absynth and a few others are not recognized. 64bit in particular seems to have trouble with plugins that have multiple inputs and/or outputs. I actually kind of preferred the 6.1 way of manually selecting a .dll file, because it was fool proof. Alchemy worked, Absynth worked. With the new scanning system they are not recognized.

I'd also like to have different plugin folders for 64bit and 32bit VSTs depending on whether it's MG 32bit or 64bit.

Great work though, I'm so blown away by this.

[copacetic]

Hello.

Not sure if this is relevant or helpful to anyone, but I thought I'd point it out.

I'm using Reaper, and changed my sample rate of my interface via the soundcard software.

Then reaper overrode the 44.1 to 48, and whatever the reason, or set of circumstances, Midi Guitar was an absolute horror to use - Double notes, tracking absolutely abysmally, tuner totally borked, etc.

Once I told Reaper to stop overriding the interface sample rate, it's working beautifully again.

So just a heads up - There are a set of conditions under which it is possible to totally screw up the operation of Midi Guitar, and for a while I had no idea why.

Cheers!

[JJunkie]

Hi,

Still having Audjoo Helix (my main synth) crash / not recognised.

Just want to clarify from my first feedback on 0.7. I truly felt an improvement on tracking single notes. Not sure about chords though. I do have false triggers as some has already reported.

I'm happy that your're looking into all our reports. It doesn't matter too much for me if there are a few baby steps or issues along the way, its still getting us closer to the destination, right?

[copacetic]

With my pitch bend set to 1/2, I can play with vibrato.

Which is awesome!

[copacetic]

With my pitch bend set to 1/2, I can play with vibrato.

Which is awesome!

Issue regarding this - Especially on the thicker strings, the attack of the note causes a very noticeable pitch bend dip/wobble (because the string is bent as its plucked).

This is undesirable - Is it possible to somehow stop the pitch bend from happening during the attack of the note?

Or something along those lines.

[AdmiralQuality]

With my pitch bend set to 1/2, I can play with vibrato.

Which is awesome!

Issue regarding this - Especially on the thicker strings, the attack of the note causes a very noticeable pitch bend dip/wobble (because the string is bent as its plucked).

This is undesirable - Is it possible to somehow stop the pitch bend from happening during the attack of the note?

Or something along those lines.

You realize that you're supposed to match the pitch bend range setting in MIDI-Guitar to the pitch bend range on your instrument, right?

[copacetic]

You realize that you're supposed to match the pitch bend range setting in MIDI-Guitar to the pitch bend range on your instrument, right?

Sure.

From earlier versions, I didn't notice mild normal guitar playing vibrato being applied when I did it, now I do, and it's nice.

Actual full tone/s pitch bending is not so hot, so I don't use it much at this stage.

*edit*

I take that back, pitch bends are working pretty well. O.o

The initial dip on the heavier strings is still an issue though!

[chucky5p]

Latency has been greatly reduced (from ~25ms with v0.6.x to as low as 8ms with v0.7.x)

Curious. Can you share your methodology for how you measure its latency? And in which configuration do you do this test? Stand-alone VST host? Stand-alone MIDI generator? Plug-In VST host? Or Plug-In MIDI generator?

Sure, no problem. But a couple of notes before going further: The results I got with MIDI Guitar (MG) did vary quite a lot between each tests, so much so that at first I was tempted to throw out all the results and blame these inconsistencies on MIDI Guitar's Beta state. However, to be fair to MG, many of the factors that affected the results would also have affected other Guitar-to-MIDI systems (Fishman, Roland, etc) Factors such as; which string was being struck, with how much force, how close to the bridge was the note been played, was it played cleanly or sloppily, etc. etc. So in the end I decided to keep these results, but I take them with a grain of salt. Let's hope newer Betas will deliver more consistent performance.

Incidentally, while re-testing version 0.7.2 in order to make screen caps for you, I was able to obtain even smaller latencies (~3ms!) than I'd previously measured on certain notes (~8ms), while simultaneously getting far worse latencies on v0.6.x (46ms vs. 25ms) so as you can see, the results are really inconsistent (that's for all version of MG). Again, I hope newer version will improve on that.

One last note: my tests results don't take into account the ASIO latency of my audio interface (FastTrackUltra 8R) because I just wanted the result of MG alone, without some artificially added latency that would affects any type of Guitar-to-MID converter, even hardware ones. Remember that even for Midi Guitars such as Triple Play, they still need to feed some kind of VSTi (with their built-in latency) and to go through some kind of audio interface, also adding their ASIO latencies. And since this ASIO latency can range from as low as ~3ms (RME) to >20ms (el cheapo interface) adding these type of latencies would "color" the result way too much and in an inconsistent manner (depending on the audio interface). I prefer isolating the conversion process from other sources of latencies so we can compare apples to apples. FWIW, my FTU8R has 8.4ms Round Trip Latency @ 44Khz. BTW, I whish the devs of MG will eventually optimize MG to enable us to use higher sampling rate and lower latencies efficiently. In my case, my FTU8R can go to 96khz@64 samples for a total RTL of 3msec. That's much better than the 8.4msec I'm "forced" to use with this version of MG. BTW, all my test were done at 44.1Khz/128 samples

OK, let's go to my test methodology (please refer to the 2 screen caps for more details):

-In order to measure accurately the difference between each MG version, I used each version simultaneously in VST mode inside my DAW, in occurrence Reaper, (which has an extremely flexible routing) but in order to run these different version simultaneously, I first renamed each version DLL to a descriptive name, i.e. "MIDI Guitar_0.6.1.0.dll", "MIDI Guitar_v0.7.2.dll", etc. Then Reaper was able to detect/load all the different versions without any conflict. I then created a new project with 5 tracks.

-On track one I recorded my guitar totally dry, no FX of any kind. I recorded many styles of playing; full chords, individual notes, while picking, while strumming, etc. For the actual test showed on the screen caps, I played individual notes with a pick on the high E string close to the bridge. That's the actual test where I got the amazing 3msec detection latency (on Screen cap #2 I've also included more typical latencies)

- The output of track one with the guitar was then sent to track 2, 3, 4 simultaneously "feeding" a different version of MG on each track (check the timeline items to know which track has which MG version) Track 2, 3, 4 were setup to record the MIDI output of each MG version. You can see the result as long black horizontal lines. That's Reaper's way of showing MIDI data. The small black dot below the beginning of each line is the velocity data.

-Track 5 was a VSTi with a sound preset with a very fast attack (clave) and was being fed simultaneously by track 4's MIDI output of MG v0.7.2. In this particular case, it added ~ 1msec of latency, for a total of 4msec. Note that on the track 5 lane, it says "Virtual Sound Canvas" but this VSTi was changed to FM8 because I wanted to use a VSTi with the fastest attack possible. I never took the time to rename the track accordingly.

Screen Cap#1 shows an overview of 3 notes being played. You can see that v0.7.2. miss-detected note #1 and #3 whereas the other version correctly detected all 3 notes. Also, v0.7.2 produced some double notes on all 3 notes, even though a single note was being played (look at track 5 "double" waveforms.) Again, the other versions detected this correctly (not show here)

(click picture for more details)


Screen cap #2 shows a close-up of note #2 being played. I used Reaper's counter calibrated in H:M:S to measure the precise latency. The beginning of the source (guitar) is at 0:00:500 or 0.5 second precisely. This feeds MG 0.7.2 which detects it ~ 3msec later. This again feeds the VSTi which produces an output ~ 1msec later, for a total of 4 msec. Note on that screen cap the typical results I get for v0.6.1 and v0.7.2 (~25ms and 8~12ms respectively) These results were measured the same way as the current test.

(click picture for more details)


This shows without a doubt that version 0.7.2 is quite faster than the other versions; however, it produces a lot more extraneous signal. Again, let's hope this will improve with new betas.

If you have any other question regarding my tests, feel free to ask.

Chuck

[AdmiralQuality]

You realize that you're supposed to match the pitch bend range setting in MIDI-Guitar to the pitch bend range on your instrument, right?

Sure.

From earlier versions, I didn't notice mild normal guitar playing vibrato being applied when I did it, now I do, and it's nice.

Actual full tone/s pitch bending is not so hot, so I don't use it much at this stage.

*edit*

I take that back, pitch bends are working pretty well. O.o

The initial dip on the heavier strings is still an issue though!

In 0.7.1 I was finding vibrato didn't work very well at high pitch bend range. Better at low range. This is not how it should work, the range of the pitch bend shouldn't affect the sensitivity.

I can't get 0.7.2 to do anything other than make the occasional spurious blips. For the few notes I managed to get it to recognize, the tuner does seem correct now.

Also still has the issue with the Advanced screen Pitch Bend Range setting not changing the setting on the Essentials screen.

And is also still coming up with Test Piano activated, even though I saved the project with it off.

I'd still like to know if clipping is bad on the waveform display. Do we want to adjust sensitivity to avoid hitting the peak? Or does that not matter?

I can no longer make meaningful tests with 0.7.2. (And I've tried with both my single coil and humbucking guitars. And rebooted my system and verified good guitar tone to make sure nothing weird was happening.)

(Windows XP 32. Reaper. Edirol UA-1000. Edirol ASIO driver. 96 samples.)

[AdmiralQuality]

Latency has been greatly reduced (from ~25ms with v0.6.x to as low as 8ms with v0.7.x)

Curious. Can you share your methodology for how you measure its latency? And in which configuration do you do this test? Stand-alone VST host? Stand-alone MIDI generator? Plug-In VST host? Or Plug-In MIDI generator?

Sure, no problem. But a couple of notes before going further: The results I got with MIDI Guitar (MG) did vary quite a lot between each tests, so much so that at first I was tempted to throw out all the results and blame these inconsistencies on MIDI Guitar's Beta state. However, to be fair to MG, many of the factors that affected the results would also have affected other Guitar-to-MIDI systems (Fishman, Roland, etc) Factors such as; which string was being struck, with how much force, how close to the bridge was the note been played, was it played cleanly or sloppily, etc. etc. So in the end I decided to keep these results, but I take them with a grain of salt. Let's hope newer Betas will deliver more consistent performance.

Incidentally, while re-testing version 0.7.2 in order to make screen caps for you, I was able to obtain even smaller latencies (~3ms!) than I'd previously measured on certain notes (~8ms), while simultaneously getting far worse latencies on v0.6.x (46ms vs. 25ms) so as you can see, the results are really inconsistent (that's for all version of MG). Again, I hope newer version will improve on that.

One last note: my tests results don't take into account the ASIO latency of my audio interface (FastTrackUltra 8R) because I just wanted the result of MG alone, without some artificially added latency that would affects any type of Guitar-to-MID converter, even hardware ones. Remember that even for Midi Guitars such as Triple Play, they still need to feed some kind of VSTi (with their built-in latency) and to go through some kind of audio interface, also adding their ASIO latencies. And since this ASIO latency can range from as low as ~3ms (RME) to >20ms (el cheapo interface) adding these type of latencies would "color" the result way too much and in an inconsistent manner (depending on the audio interface). I prefer isolating the conversion process from other sources of latencies so we can compare apples to apples. FWIW, my FTU8R has 8.4ms Round Trip Latency @ 44Khz. BTW, I whish the devs of MG will eventually optimize MG to enable us to use higher sampling rate and lower latencies efficiently. In my case, my FTU8R can go to 96khz@64 samples for a total RTL of 3msec. That's much better than the 8.4msec I'm "forced" to use with this version of MG. BTW, all my test were done at 44.1Khz/128 samples

OK, let's go to my test methodology (please refer to the 2 screen caps for more details):

-In order to measure accurately the difference between each MG version, I used each version simultaneously in VST mode inside my DAW, in occurrence Reaper, (which has an extremely flexible routing) but in order to run these different version simultaneously, I first renamed each version DLL to a descriptive name, i.e. "MIDI Guitar_0.6.1.0.dll", "MIDI Guitar_v0.7.2.dll", etc. Then Reaper was able to detect/load all the different versions without any conflict. I then created a new project with 5 tracks.

-On track one I recorded my guitar totally dry, no FX of any kind. I recorded many styles of playing; full chords, individual notes, while picking, while strumming, etc. For the actual test showed on the screen caps, I played individual notes with a pick on the high E string close to the bridge. That's the actual test where I got the amazing 3msec detection latency (on Screen cap #2 I've also included more typical latencies)

- The output of track one with the guitar was then sent to track 2, 3, 4 simultaneously "feeding" a different version of MG on each track (check the timeline items to know which track has which MG version) Track 2, 3, 4 were setup to record the MIDI output of each MG version. You can see the result as long black horizontal lines. That's Reaper's way of showing MIDI data. The small black dot below the beginning of each line is the velocity data.

-Track 5 was a VSTi with a sound preset with a very fast attack (clave) and was being fed simultaneously by track 4's MIDI output of MG v0.7.2. In this particular case, it added ~ 1msec of latency, for a total of 4msec. Note that on the track 5 lane, it says "Virtual Sound Canvas" but this VSTi was changed to FM8 because I wanted to use a VSTi with the fastest attack possible. I never took the time to rename the track accordingly.

Screen Cap#1 shows an overview of 3 notes being played. You can see that v0.7.2. miss-detected note #1 and #3 whereas the other version correctly detected all 3 notes. Also, v0.7.2 produced some double notes on all 3 notes, even though a single note was being played (look at track 5 "double" waveforms.) Again, the other versions detected this correctly (not show here)

(click picture for more details)


Screen cap #2 shows a close-up of note #2 being played. I used Reaper's counter calibrated in H:M:S to measure the precise latency. The beginning of the source (guitar) is at 0:00:500 or 0.5 second precisely. This feeds MG 0.7.2 which detects it ~ 3msec later. This again feeds the VSTi which produces an output ~ 1msec later, for a total of 4 msec. Note on that screen cap the typical results I get for v0.6.1 and v0.7.2 (~25ms and 8~12ms respectively) These results were measured the same way as the current test.

(click picture for more details)


This shows without a doubt that version 0.7.2 is quite faster than the other versions; however, it produces a lot more extraneous signal. Again, let's hope this will improve with new betas.

If you have any other question regarding my tests, feel free to ask.

Chuck

Thanks for that. That's playback latency, which Reaper and/or MIDI-Guitar can be compensating for. (They won't reply to my questions about the deltaFrames values they're stamping their MIDI events with and I'd need to go to some effort to come up with a test to determine it.)

But it's certainly a valid test of relative latency between versions. But as far as absolute latency you can't tell as, again, the host is already shifting the guitar track in time by how much it thinks the input latency is. (Which is almost always not enough by the way. Someday I'm going to write a page about how to determine your REAL latency and tweak your hosts settings to compensate for it. You need to do an analog loopback test to really be sure.)

[chucky5p]

Thanks for that. That's playback latency, which Reaper and/or MIDI-Guitar can be compensating for. (They won't reply to my questions about the deltaFrames values they're stamping their MIDI events with and I'd need to go to some effort to come up with a test to determine it.)

But it's certainly a valid test of relative latency between versions. But as far as absolute latency you can't tell as, again, the host is already shifting the guitar track in time by how much it thinks the input latency is. (Which is almost always not enough by the way. Someday I'm going to write a page about how to determine your REAL latency and tweak your hosts settings to compensate for it. You need to do an analog loopback test to really be sure.)

Actually, I accounted for that in my tests. I've done extensive tests on RTL in the past (round trip latencies) That's why I always specify RTL in all my tests, and in the case of the FTU8R, WYSIWYG. When Reaper shows the IO latency for the FTU8R, it's actually the exact same latency you'll get if you do an analog loopback test (whether using centrance or doing it manually). The FTU8R is one of the few Audio Interface that doesn't use ANY kind of hidden/safety buffers. Of course it uses "some" type of buffers, but they are reported 100% accurately to the host by its drivers.

Even so, my results could have been affected by Reaper moving the 1st track (audio track) by the input latency through its PDC mechanism while recording. That's why I first recorded the guitar track, and then after it was recorded (and that any PDC while recording had been applied) I did the routing to the multiple instances of MG. Since MG reports 0 PDC, Reaper "probably" didn't move anything on the MIDI recording pass and I can be "relatively" confident that the results I got were accurate as far as the delays produced by MG. I even repeated my tests after turning off Reapers's automatic PDC and got identical results.

Of course, to be absolutely 100% sure would require a special analog loopback test, special because here were looking at Analog->AD->MIDI(MG)->VST->DA->Analog. You can't just plug a impulse generator to the audio interface and look at the output, MIDI Guitar will probably bark at it Actually you got me curious. I'll devise a test procedure that take into account ALL latencies of my setup. Most likely this will probably involve using a second computer to record simultaneous audio from the guitar jack out on one side and the audio interface/MG out on the other side and compare the difference. THAT is a 100% reliable test.(speaker delays not withstanding)

Chuck