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

[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.

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"?

I have been choosing "trial" forgot we had a beta license file

[AdmiralQuality]

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

Good stuff, Chuck!

If you're using it to drive a synth on another track, keep in mind that there's going to be about 1 buffer of added latency coming from the instrument. This is because MIDI events come in between process buffers. So there's no way MIDI-Guitar can get the event to a plug-in in the same buffer time that it detected it. (This is what my question about negative deltaFrames values is about. In VST hosts that do it right, MIDI controllers played in real time should always have a negative deltaFrames value stamped on their MIDI events. Then on playback the host can move the sending of those events back a buffer and correct the deltaFrames values to the usual positive kind. It's not always handled correctly by all hosts though, and yet another reason why we always want buffer latency as low as we can possibly set it -- to remove these timing "jitter" errors created by the buffer. Someday we'll have an interface with a single sample buffer, and I'll do a little dance! )

[ariajazz]

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.)

That'd be an inmemse contribution for many of us to have that technique in detail. There are a couple of them using different software, check this one using Audacity:

http://manual.audacityteam.org/man/Latency_Test

[AdmiralQuality]

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.)

That'd be an inmemse contribution for many of us to have that technique in detail. There are a couple of them using different software, check this one done with Audacity:

http://manual.audacityteam.org/man/Latency_Test

That's pretty much it. It's just also important to be aware that the host is probably already compensating by the known buffer size when it displays the recorded tracks to you. As chucky5p points out, that buffer size is usually not the whole story when it comes to latency, there can be hidden delays that the host is unaware of.

And as someone who's really into realtime performance with this stuff, even perfectly calibrated delay compensation can't help us there. Only smaller buffers and faster interfaces can. Like I said, I long for the day we get hardware with 1 sample buffers. (Yes, that will stress the CPU more, but it'll be worth it to those of us who care and can feel even small latencies.)

[ariajazz]

Ole is it possible for me to download previous versions of MG, lets say from v0.4 to 0.6? For some reason mines are not working at all, they seem to be corrupted probably in the proccess of transferring them from one machine to another.

I want to do an extensive test with all these versions and compare in detail the results. Thank You.

[chucky5p]

... Like I said, I long for the day we get hardware with 1 sample buffers...

Then you should read the couple of posts I made on this exact subject on Cockos forum here...and the jewell is here

As a matter of fact, the whole thread is a good read.

Chuck

[StickyWicket]

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"?

I have been choosing "trial" forgot we had a beta license file

While playing, I've been continuously clicking on "trial" as well.

Where can I get the Beta License file?

[chucky5p]

Where can I get the Beta License file?

You need to buy it on Jam Origin's website:

http://www.jamorigin.com/midi-guitar/Wi ... index.html

Chuck

[JamOrigin]

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

Chuck, thank you very much for this great analysis and thoughtful feedback!

3ms is on pair with what we find on 0.7.2, although we have stepped a few ms back in 0.7.3 which will be released in my next post. When we reach version 1.0 we will also make latency tests and compare with hardware solutions. I think without revealing too much I can say that we sit on a Pitch Prediction level 4 setting, but for now it seems that latency isn't much of an issue for most.

As for the tuner, its true its still a few cents off. We will fix that in a future release.

Admiral Quality, there is currently no delta on timestamps, so the analysis is valid also even without compensation for it.

[JamOrigin]

Ole is it possible for me to download previous versions of MG, lets say from v0.4 to 0.6? For some reason mines are not working at all, they seem to be corrupted probably in the proccess of transferring them from one machine to another.

I want to do an extensive test with all these versions and compare in detail the results. Thank You.

Sure! Thats going to be a good help for us if you will sanity check the latest versions:

JamOrigin.com/midi-guitar/MIDI-Guitar-0.5.3-Mac.zip
JamOrigin.com/midi-guitar/MIDI-Guitar-0.5.3-Win.zip
JamOrigin.com/midi-guitar/MIDI-Guitar-0.6.1-Mac.zip
JamOrigin.com/midi-guitar/MIDI-Guitar-0.6.1-Win.zip
JamOrigin.com/midi-guitar/MIDI-Guitar-0.7.2-Mac.zip
JamOrigin.com/midi-guitar/MIDI-Guitar-0.7.2-Win.zip
JamOrigin.com/midi-guitar/MIDI-Guitar-0.7.3-Mac.zip
JamOrigin.com/midi-guitar/MIDI-Guitar-0.7.3-Win.zip
(KVR forum has a bug with spaces-in-urls)


This is an oversimplification, and of course impossibly naive to simplify across all sorts of guitar timbre but:

• 0.5 is very crisp and has a nice feel. Nice for legato players and virtuosos.
  
  0.6 Introduced bends and was generally more accurate, but with notable different feel.
  
  0.7 up to 0.7.2 has improvements over 0.6 in terms of latency and strumming, but 0.7.0 to 0.7.2 and hasen't been been entirely satisfactory for us. It introduced a new source of spurious hits and suffers from bugs in small buffersizes (ie. smaller than 256 @ 44.1Khz) and CPU burn problems.
  
  Version 0.7.3 was just published now and it takes some of its genome from 0.5 and inherits a similar feel. It also lends some accuracy DNA from 0.6. In our naming convention 0.7.3 is more like major new version, but we will keep 0.7 naming as 0.7 has not yet been officially released on our website.
  
  The latest and greatest:
  http://JamOrigin.com/midi-guitar/MIDI-G ... .3-Mac.zip
  http://JamOrigin.com/midi-guitar/MIDI-G ... .3-Win.zip

[chucky5p]

Preliminary report for v0.7.3:

Short story: Ahhhhh! Much better than 0.7.2!

Long story: As stated by Jam Origin in response to my 1st latency report, v0.7.3 is not as fast as v0.7.2 BUT it "behaves" MUCH better; much less false triggering, dropped notes, wrong notes, etc. Actually, it's the first version I was able to consistently play 2~3 notes simultaneously like on a keyboard (great for piano parts). Previous versions sometime were able to do that, but not as reliably as v0.7.3. Note that v0.7.3 is still not perfect, but AFAICT it's the "smoothest playing" version yet

BTW, even if v0.7.3 isn't as fast as v0.7.2, it's still very good. From the few tests I made (the same kind I did in my first latency report) I measured latency about halfway between v0.6.1 and v0.7.2. And I must repeat this; it plays beautifully. I'll take precision over a few msec anytime! Of course, if Jam Origin is ever able to reduce latency while keeping the same playability/precision, I'm all for it.

Taking about precision, Pitch Bend is still not very reliable. If I set it up to have a good range, tuning will go off even without bending any notes. Let's hope this issue will be sorted out in time. OTOH, CPU usage as been reduced to about the same level as v0.6.1, so about half of v0.7.2. Nice!

BTW, I've found a way to improve tracking of all versions of MG with MY guitar (Epiphone SG) I'm not sure if this trick would help everyone since we each have different guitars and from what I've read, MG will behave differently with each guitars. My instinct tells me it has to do with the combination of pickup type (active/passive/humbucking/non-humbucking, etc) and string gauge, which combined produce a signal with a specific frequency curve, and depending on that curve, MG will track better or worse. That would explain why some people have no problems with one of their guitars and major problems with the others.

In a few days I'll post my "trick" so others can try it, as well as some suggestions on new features I'd love to see being implemented. For now I must tend to other matters (I've spent the better part of the last few days on MG!)

Chuck

[ariajazz]

I've just tested MG v0.7.3 for a couple of hours. These are my inpressions:

1.- Pluging scanning issues seem to be solved now, however 13 of my plugins failed to load (eg. Sample Tank 2.5, Magix VANDAL, Le Pou amp heads, and some others).

2.- Still cannot see input and output settings in stand alone mode. I insist, text fields are too short and only display a few characters. Again, I only could set the input/ouput by try and error. Developers should redisign this, maybe by making the software to display only the channel numbers and not the entire info of the sound card (in my case it shows the first characters of the name of the sound card).

3.- I still believe SENSITIVITY has been set too high in versions 6 and 7. It is too much sensitive. I have my sound card input set to -6 dB and SENSITIVITY setting does never go above 15 or 20, higher than that clipping occurs and false notes start to appear. I remember one previous version I think it was v5 that tracked beautifully and SENSITIVITY setting was very controllable, it also use to have a sort of a RED clipping indicator. I gig once with that particular version and people were impressed.

4.- Pitch bend is OK, I would say decent, some more work has to be done. Tracking is OK too but not as desirable, I do experience some inconsistencies in velocity and the feel the notes sound (specially soloing) in terms of note volumes. I feel it has something to do with the sensitivity problem I stated above. However poly tracking has been improved significantly making chords sound smooth and full.

5.- The wave form feature does not work for me in stand alone mode, I only get a blank window (it works in plugin mode). Tuner has some little inaccuracies, I compared it with Amplitube's one which is very good and precise.

I will be testing MG some more tomorrow and making comparisons with previous versions to stablish specific aspects between them.

[Eleventh]

I'm just now downloading 0.7.3.. gonna try it soon.

Meanwhile, I'd like to repeat my inquiry from a couple of pages back:

In the future releases should we expect improved detection for fingerpicked chords (simultaneous notes) and chords with semitone-separated notes? I find these two things the most bothersome when playing through MG, and I hope that improvements can be made.

EDIT: after playing around for a while with the newest version it feels like there's a lot less spurious random notes than with some of the previous versions. Very nice.

[mantradream]

im using mountain lion v 10.8.3 . in standalone MODE when you click view the screen of plugin vsti can't resize .. its to small 90 pixel x 90px .. also crash when trying to change the plugin to something else like from absynth [ i have NI komplete 9 ] , to massive ...

[mantradream]

ups sorry i forgot tell im using jamorigin 64bit version ,, also it seem bug on shortcut keyboard .. cmd+Q can not close the program ..