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

[ariajazz]

AdmiralQuality say on his coments

"Pitch bend has gone insane"

I noticed this strange behavior on some synth patches, not all

[AdmiralQuality]

AdmiralQuality say on his coments

"Pitch bend has gone insane"

I noticed this strange behavior on some synth patches, not all

The synth doesn't affect the controller. If you're noticing it on some instrument patches and not others, that's simply because those patches don't have any amount of pitchbend set.

It's easy to see in Poly-Ana as there's a virtual pitch-wheel that's just wiggling like crazy the whole time.

It does seem to happen more noticeably on higher notes vs. lower notes. From the G string on up it's very noticeable.

[Cecelius2]

A poster on another forum got his Midi Guitar to scan vsts in 32bit mode. So since I had only used the 64bit standalone version I gave it a try.

At first the 32bit standalone Midi Guitar gave the same trouble as the 64bit by not loading a vst. Then I closed it and tried it again. I pointed the vst scan toward one instrument only--kontakt4. It loaded it. So then I opened the 64bit standalone. It did not show the Kontakt4; however, once I scanned it, the kontakt4 was available in the 64bit standalone Midi Guitar.


So then I tried adding a second individual scan--Rapture. It loaded in 32bit standalone mode. When I exited and relaunched the 32bit standalone, both Kontakt4 and rapture were available in the pull down menu for instruments. So I then tried it in 64bit standalone. At first it crashed, but the next time, it had both kontakt4 and rapture available for pull down instruments in 64bit standalone version of Midi Guitar.


This is not an ideal way, but it at least is progress in the right direction. I will just scan individual softsynths one at a time like Omnisphere and Alchemy and my IK synths and see if they stick.


This is a trial and error beta testing, but I am making some progress getting the vsts to load on my system.

[ariajazz]

This is a trial and error beta testing, but I am making some progress getting the vsts to load on my system.

That's the idea, all this try and error and different issues experimented by testers build the fine tuning of the software. I do too believe we're in a good direction

[ariajazz]

Here is my convoluted way around my trouble:

1. I installed loopmidi, and set up one instance of loopmidi, which gives one midi input and one midi output track.
2. In Sonar X2a's Preferences, I activated/selected loopmidi for active in both midi input and midi outputs.
3. Next, run Jam Origin Midi Guitar in STANDALONE MODE only outside of Sonar. Do not insert this as a vst instrument (only because that never worked on my system).
4. Next, I inserted a different vst instrument --whatever vst softsynth you want to play. I chose Alchemy in Sonar X2a.
5. On this softsynth midi input (Alchmey's in my case), select "loopmidi" within its midi input track. Choose omni as the channel.
6. Make sure that the softsynth has input echo activated.
7. Arm and record the midi from the soft synth's own midi input track (Alchemy in my case).

This convoluted method (while not getting Midi Guitar to work within my DAW as a vst itself), did provide a means for me to use Midi Guitar along side of, and in conjunction with my version of Sonar X2a. By running Jam Origin as a Standalone along side of (in addition to) my Sonar X2a it works fine to trigger and record softsynths within Sonar.

This is actually the easiest way to use MG with Sonar. However I've use MG as plugin inside Sonar 8.5 by using external virtual midi ports such as midiyoke, assigning and routing them properly

[JamOrigin]

So it turned out that the scanner problems are caused by the filename "MIDI Guitar 64.exe"...

It turns out that if an app ("MIDI Guitar 64.exe") wants to launch a process (in this case the scanner which is also in "MIDI Guitar 64.exe") - Windows will first try to run "MIDI.exe" and "MIDI Guitar.exe" before the more sane approach of "MIDI Guitar 64.exe". So the scanner launch the 32 bit version if you have it in the folder... and things start to go even more wrong from there because then it might find 32 bit plugins in the 64 version which won't load.

The quick fix is to rename "MIDI Guitar 64.exe" to "MIDIGuitar64.exe".

Good catch with the "warbling" pitch bends. 0.7.5 will be ready to tomorrow.

[AdmiralQuality]

S
It turns out that if an app ("MIDI Guitar 64.exe") wants to launch a process (in this case the scanner which is also in "MIDI Guitar 64.exe") - Windows will first try to run "MIDI.exe" and "MIDI Guitar.exe" before the more sane approach of "MIDI Guitar 64.exe". So the scanner launch the 32 bit version if you have it in the folder... and things start to go even more wrong from there because then it might find 32 bit plugins in the 64 version which won't load.

What? That doesn't sound right. (What are you calling, LoadModule()? You shouldn't be loading anything that's not a .dll extension, for starters. But also check that your pathnames have quotes around them, like quotes IN the actual string. This usually fixes problems associated with spaces in filenames.)

Good catch with the "warbling" pitch bends. 0.7.5 will be ready to tomorrow.

I don't know how you guys don't catch big obvious stuff like this before you let it out to the public. Do you not have a guitar player in house?

And fixing the pitch bend control so changes on the Advanced page are reflected on the Essentials page should be easy to get in there too.

[JamOrigin]

S
It turns out that if an app ("MIDI Guitar 64.exe") wants to launch a process (in this case the scanner which is also in "MIDI Guitar 64.exe") - Windows will first try to run "MIDI.exe" and "MIDI Guitar.exe" before the more sane approach of "MIDI Guitar 64.exe". So the scanner launch the 32 bit version if you have it in the folder... and things start to go even more wrong from there because then it might find 32 bit plugins in the 64 version which won't load.

What? That doesn't sound right. (What are you calling, LoadModule()? You shouldn't be loading anything that's not a .dll extension, for starters. But also check that your pathnames have quotes around them, like quotes IN the actual string. This usually fixes problems associated with spaces in filenames.)

Since 0.7 we launch the scanner in its own process, just like DAWs do. This way a buggy plugin or a .dll file which is not a plugin cannot crash the host process (in this case MG or your DAW).

[AdmiralQuality]

S
It turns out that if an app ("MIDI Guitar 64.exe") wants to launch a process (in this case the scanner which is also in "MIDI Guitar 64.exe") - Windows will first try to run "MIDI.exe" and "MIDI Guitar.exe" before the more sane approach of "MIDI Guitar 64.exe". So the scanner launch the 32 bit version if you have it in the folder... and things start to go even more wrong from there because then it might find 32 bit plugins in the 64 version which won't load.

What? That doesn't sound right. (What are you calling, LoadModule()? You shouldn't be loading anything that's not a .dll extension, for starters. But also check that your pathnames have quotes around them, like quotes IN the actual string. This usually fixes problems associated with spaces in filenames.)

Since 0.7 we launch the scanner in its own process, just like DAWs do. This way a buggy plugin or a .dll file which is not a plugin cannot crash the host process (in this case MG or your DAW).

Not sure which hosts you're referring to. I'm still used to bad plug-ins crashing or hanging the host. But most hosts will know to skip that plug-in next time they scan as they see the record of starting to scan it and no record of the scan completing, so they automatically skip it next time around.

I really think you've gone down the wrong path here, trying to be a plug-in host is a BIG can of worms, as you're obviously discovering. And a lot of effort that takes away from where you should be focused, on the analyzer's performance. And does it save and recall plug-in state yet? And once it does that, does it record and play back automation? Can of worms...

Oh! I just remembered you're JUCE-based. So hosting seemed like something you could add "for free"? Right...

[scook]

To me this issue points to a minor packaging problem. The 32bit and 64bit versions should be packaged in separate directories. It is clear that some just unzip the archive without any consideration for the different formats. I like simple install processes but this one may be too simple.

[JamOrigin]

AdmiralQuality, MG is keeping track of bad plugins also, and skipping upon next scan, but its still not an excuse to crash the users host. Google Chrome got it right with safe browser tabs using same trick and im just saying that a safe plugin scanner is preferable to an unsafe.

Scook, we havent decided upon installer. People seem very split on this.

[scook]

Scook, we havent decided upon installer. People seem very split on this.

I am not talking about the final v1.0 installer for windows. I am sure that some expect a very slick front end to what is essentially a simple copy process. Even now, I believe some might benefit from providing a zip with two folders to keep the 32bit binaries separate from the 64bit ones. Of course, had the 0.7x betas been delivered that way, this current scan bug might not have been discovered.

[ariajazz]

Here is my convoluted way around my trouble:

1. I installed loopmidi, and set up one instance of loopmidi, which gives one midi input and one midi output track.
2. In Sonar X2a's Preferences, I activated/selected loopmidi for active in both midi input and midi outputs.
3. Next, run Jam Origin Midi Guitar in STANDALONE MODE only outside of Sonar. Do not insert this as a vst instrument (only because that never worked on my system).
4. Next, I inserted a different vst instrument --whatever vst softsynth you want to play. I chose Alchemy in Sonar X2a.
5. On this softsynth midi input (Alchmey's in my case), select "loopmidi" within its midi input track. Choose omni as the channel.
6. Make sure that the softsynth has input echo activated.
7. Arm and record the midi from the soft synth's own midi input track (Alchemy in my case).

This convoluted method (while not getting Midi Guitar to work within my DAW as a vst itself), did provide a means for me to use Midi Guitar along side of, and in conjunction with my version of Sonar X2a. By running Jam Origin as a Standalone along side of (in addition to) my Sonar X2a it works fine to trigger and record softsynths within Sonar.

This is actually the easiest way to use MG with Sonar. However I've used MG as plugin inside Sonar 8.5 by using external virtual midi ports such as midiyoke, assigning and routing them properly

[FrettedSynth]

Still having a blast here latency feels quite nice. From what I have read here it seems MG does much better with humbuckers right now, might be some peoples problems? Shecter with EMG's here.

Haven't had as much time as I would like, been pretty busy BUT this is what I have found.

When I load the VST setup presets are not recalled from what I last used, My Setup 1.

For the VST it would be nice if it did not load the Test Piano loaded, would be better at none?

The extended range of the Sensitivity that was added seems a bit too much? Might be the problem some have with the v0.7..... releases?

For the FX section routing, routing and routing like we had talked about?

Will let you know more when I can
Peace
Joe

[memyselfandus]

"For the VST it would be nice if it did not load the Test Piano loaded, would be better at none?"

+1