| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000248 | OpenMPT | Plugins / VST | public | 2012-05-06 17:15 | 2012-07-13 17:33 |
| Reporter | harbinger | Assigned To | Saga Musix | ||
| Priority | normal | Severity | crash | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Platform | x86 | OS | Windows | OS Version | XP |
| Product Version | OpenMPT 1.20.01.00 (upgrade first) | ||||
| Target Version | OpenMPT 1.20.02.00 (upgrade first) | Fixed in Version | OpenMPT 1.20.02.00 (upgrade first) | ||
| Summary | 0000248: M1 GUI broken in 1.20 | ||||
| Description | When loading the Korg M1 VSTi into a new module, the following happens:
I have tried loading other plugins, including complicated VSTi's like Oxytocin, and plugins without their own GUI, like MDA's Loudness VST, and everything else i tried works fine. This bug also occurred when i loaded an MPTM track that already had the M1 as part of the plugin list. When i went back to 1.19.3, the M1 loaded correctly and showed its GUI as it always has. Interestingly, when i loaded the M1, opened its window, and instead of clicking in the window, i changed the preset in MPT's menu, there was a bit of a stutter, but it changed the preset and it preview-played fine. UPDATE: After playing the track, the GUI elements appear as normal and tweaking the controls does not crash MPT. EXCEPT i did notice that clicking on the GUI keyboard did not play the notes UNTIL i used the PC keyboard to play the GUI keyboard, then it accepted mouseclicks. | ||||
| Tags | No tags attached. | ||||
| Has the bug occurred in previous versions? | |||||
| Tested code revision (in case you know it) | |||||
 |
The advice I'd like to give here is "Fuck Syncrosoft and everything that uses their drivers and get a real Korg M1 instead", but that's obviously of no help. The only reason I can imagine why this didn't happen before is that OpenMPT 1.19 didn't have exception handling (aka crash prevention) enabled, and that the plugin in question doesn't like that change. I could compile a version of OpenMPT 1.20 that doesn't have exception handling enabled to confirm this. If that is really the cause, I'm afraid I can't do much about it because exception handling is vital for OpenMPT's increased stability as a VST host, but it might be possible to get the plugin running again in jBridge or Chainer then. |
|
|
Oh, and of course you could also try re-installing the dongle and plugin drivers, but I doubt it will help. It's also possible that this is a problem only happening with test builds (the V2 plugin has similar issues during debug mode, but not when running OpenMPT standalone), so please test if this also happens with the freshly released OpenMPT 1.20.01.00. |
 |
Actually the best advice you gave here is for the fresh release of 1.20. I am using the test version from several days ago, and that probably is the cause if it's debug-oriented. I'll try the official update and report back... |
|
|
UPDATE: After doing a clean install of both OpenMPT 1.20 AND a clean install of the M1 VST and its licensing control, the problem as described above still exists. As far as i'm concerned the issue is not major because there is a workaround. The user will need to play a pattern or start the song to have MPT "initialize" the controls before tweaking any controls in the GUI. If he wishes to use the mouse to access the M1's keyboard display (something i rarely do), he needs to press any note key to activate the note player function of the M1's keyboard. The test i gave it was for a track already built as well as a new track. I did not try it with Chainer, so that's next on my list... |
|
|
Here's a version of OpenMPT without exception handling for plugins: Please try if it fixes the problem. If it does, I'm afraid the issue cannot be fixed directly for the sake of VST hosting stability. In that case, using JBridge to create a bridged version of the plugin could help, though. |
|
|
M1 bug update: As i would normally do, i loaded a track that used the M1 VSTi as an Instrument. The first thing i did in the General page was click on the Edit button in the plugin section to see if the GUI would display. Immediately i got a message indicating that there was a C0000005 error (which i remember from my studies at some point, this is a common error). I have attached a pic of this first notice. BTW all of this happened with the recent "NO-Exceptions" version you provided; i got none of this with any other version.... Also i tested this special version of MPT with other tracks and they played fine and displayed other VSTs just fine, in case there was a problem with this build. Hope this helps. |
|
|
You have to zip (or 7z) the crash dump to upload it. But since the exception was handled in the official OpenMPT 1.20 now it was not handled (and thus resulted in a crash), this means that the plugin itself caused the crash, and the crash dump will not be of much use for me. This puzzles me a bit, because this must mean that the plugin also crashed with OpenMPT 1.19 (which also didn't have exception handling). Maybe I will have to try another exception handling mode. In case you are using a limited Windows user account, you should also try running OpenMPT in administrator mode to see if the problem vanishes then - Apparently copy protected plugins often require administrator privileges. |
|
|
UPDATE: I have yet to try jBridge and must find that. I'll do some testing again with that wrapper and see what happens. BTW, the M1 ships with a second Korg Legacy VSTi called Wavestation (which i believe was also put out as MIDI hardware in the 90s). When i loaded the Wavestation into a new MPTM track -- using the no-exceptions build -- it immediately crashed and quit without a dialog or anything. When i tried the same thing with the 1.20.1.2 build, the same crash dialogs (more or less) came up as with the M1. Both use the Syncrosoft License Control so the problem may be with that rather than individual VSTi's. |
|
|
Since you say the plugin didn't crash in 1.19.03.00, can you please also confirm whether the plugin crashed in OpenMPT 1.19.04.00? That would greatly help with finding the source of the crash. |
|
|
Will do. I never tested 19.04, so i don't know how it would have taken it. (BTW, went looking for it, and from the stickie at the forums, the download link takes me to the Downloads page of ModPlug Central, where you can't find old versions directly. Consider changing the 19.04 DL link at the forums to the sourceforge folder for 1.19., in case that's ever needed for the future -- as it was now.) |
|
|
Version 1.19.04.00 is still available on the FTP server as all other versions. The Download page already has a "previous releases" link. |
|
|
UPDATE to M1 bug: Under 19.04, the M1's GUI loaded up as expected, and all the elements were visible and clickable. Interestingly the keys on the M1's GUI did not activate with the mouseclick, but needed a PC keypress to "start" it up; after retro-testing with 18.3, this has always been the case and i just never noticed it. Also tried using jBridge, but wasn't sure how that worked. After extracting it, running its "tool", and starting up MPT, all i got was a notice that jBridge could not "find its proxy", whatever that means. It doesn't load as a VST of any kind in MPT, so i uninstalled it. No further tests will be made in this bug with jBridge. So this means the bug was introduced with 1.20, and a know alot of development happened between 1.19 and 1.20.... |
|
|
The JBridge website would have answered you how to use JBridge. JBridge isn't a plugin host like Chainer, it's just a Bridge between Hosts and Plugins. Point the JBridge tool at your plugin directory containing M1, and let it create a bridged version of the plugin somewhere else. Start OpenMPT with admin rights and load the bridged version of the plugin into OpenMPT. Anyway, seems like we'll have to take the (admittedly slow, because you aren't here every day) approach of progressively isolate the revision in which the M1 GUI broke. For that I'll zip up a bunch of OpenMPT 1.20 development builds... |
|
|
Ok, I've compiled 6 old versions of OpenMPT 1.20, available at http://sagagames.de/stuff/mptrack_revisions.7z - please test them all and tell me which is the last version in which the M1 GUI works correctly. After that, we'll narrow down which revision between the last working one and the first broken one is the culprit. |
|
|
I couldn't find anywhere on their website what jBridge does or why i should use it. I don't even know what a "bridged" plugin is or what good it does me. I keep hearing you throw around the term "admin rights," falling into your habit of automatically thinking other people know what you're talking about. I'm on my own computer with no internet and no one else uses it -- do i still need "admin rights" or does this have to do with a server? "Ok, I've compiled 6 old versions of OpenMPT 1.20, available at http://sagagames.de/stuff/mptrack_revisions.7z [^] - please test them all" |
|
|
I don't even know what a "bridged" plugin is or what good it does me. "Bridging" is a common term for running plugins outside of the real host (The latest Renoise versions can do this, Firefox does it for its plugins, OpenMPT should do it at some point too) to prevent the host application from crashing if a plugin crashes, or to pass the 32 <-> 64 bit border. In this particular case, it could help with certain security features OpenMPT employs - if the plugin doesn't like one of them (f.e. Data Execution Prevention), it could still work in jBridge because then it would run in a separate process without those security features. I find this to be a rather realistic cause of the bug because I had my own share of problems with copyright enforcement software (Syncrosoft) and the only way to get it to work was to disable Data Execution Prevention for the Syncrosoft drivers. I keep hearing you throw around the term "admin rights," falling into your habit of automatically thinking other people know what you're talking about. I'm on my own computer with no internet and no one else uses it -- do i still need "admin rights" or does this have to do with a server? People running Vista or Win7 would very well know what I am talking about, because the default Windows user there is not an administrator. Seeing that you're using Windows XP, you are probably already running as an administrator user. A normal user account cannot install software for example. If you can install software normally without entering a password, switching to a different user account etc., you are already running in administrator mode and OpenMPT runs in administrator mode as well. On Vista/7, you would have to right-click the application and choose "Run with administrator privileges". I thought i was clear in my previous post. And I thought so was I: Test all versions and save both us a lot of time. It is worth the effort: The initial 1.20 release is where the bug started I am very sure that this is note the case, because I doubt that you had access to the "initial version". You only tried the first official release. All 6 old versions in this package are from the time between the release of OpenMPT 1.19.03.00 and 1.20.01.00. During this time, the support for M1 probably broke, but it certainly did not break in the initial build (1.20.00.01), nor in the first official release (1.20.01.00). Don't know if you see my issue as affecting others, but i'm not too anxious to go thru all this superfluous testing when i've not only narrowed down the version The issue affects everyone using the plugin, so yes it is worth pursuing this method. After you have verified which of the 6 executables is the last working one, I can narrow down the problem to 50 code revisions (from initally over 300). After this, I will give you another set of executables from those 50 revisions, which will narrow down the problem to 10 or so revisions. And after that, we're almost done (the number of versions to test will decrease logarithmically). You see, this is not superfluous testing. I'm giving you several executables at once (testing each will take you a minute at max) to effectively rule out hundreds of other intermediate executables. I'd much rather send you my copy of the M1 installer and let you find the problem if you view it as a problem that will only get worse in future versions. I'd prefer to stay clean of copyright enforcement software on my work machine (Syncrosoft drivers are already enough). ;) |
|
|
You have made very cogent, lucid, and civil arguments (sorry for sounding so bratty). If you're dedicated to finding the problem so that i can go back to the original behavior (without need of workarounds), then i shall dedicate myself to helping you squash that bug. Downloading your test builds now... Get back to you next week or so. |
|
|
UPDATE: The M1 GUI opened immediately with build 1200 in the version pack you provided (as well as the previous versions), but in r1250, there was a crash with the Dispatch warning as i noted in the initial post. |
|
|
Ok, so it's a rather late error that sneaked in... I've created another batch of revision ranging from revision 1200 to 1250. Download the files from the same link as above, and test again which is the last revision in which the plugin runs as intended. |
|
|
Under some lucky circumstances, I managed to get my hands on a Korg Legacy license. I'm running the plugins on Win7 and the M1 GUI works without any problems here, however the Wavestation GUI remains black (but doesn't throw any exceptions) until playback is started. Are you sure that you are using the latest version of the plugins (available from korguser.net)? The latest versions work without a dongle, so this might get rid of some trouble as well. Please try again using the latest version of the plugin - if it then works without problems for you, I will not pursue the issue any further. Edit: My bet is that the problem is related to a fix in revision 1230, which was made to fix issue 0000210. I slightly changed the code of this fix to make the Wavestation GUI accessible again. This might also fix your M1 problem. |
|
|
|
|
|
Then I am rather sure r1230 was the cause; |
|
|
This bug has been completely fixed in the 1.20.02 release. Feel free to close or mark "resolved". |
