.MPTM File Editor

[christofori]

This note's primarilly for Jojo but if anyone else has ideas feel free to chime in..!
 
This really isn't a bug report, nor technically a feature request (though it fits there better perhaps..) and I don't believe it has to do with OMPT even; but a VST I had loaded.  A little bit of background as to the problem:
 
I use a Roland SH-201 analog synth, which comes with editor and librarian software (to edit and store/retrieve patches to the synth, as it can only hold 32 user patches at a time).  It also included a VSTi which allows a host to play it AND edit it.  So, I had loaded the VSTi into the tracker and have used it just fine with the song I just finished writing.  Now typically, I tend to like the same samples (in the tracker) from song to song and may add or remove some during the writing process, but as I begin a new song I copy the previous one's file into a new folder and then remove the patterns from the order list and begin making the new song in new patterns (I know, I know.. I could get around to setting up a project and I might not have this problem.. it's on the to-do list and now has higher priority..!  Call me old-skool but it's how I've always worked).
 
Anyway.. I use other sample libraries which actually use the SH-201's ASIO as their output source in addition to playing the active SH-201 patch from within the tracker (which could be risky of course..) -- at some point I'm unsure of, one of those libraries had switched itself to use my ASIO4ALL driver (which wasn't supposed to be in use by anything).  This probably happened as result of not loading things in the right order and I hadn't caught it right away (loading in the right order goes back to how this is 'risky' -- if you don't load programs in the proper order the sound may not work from one or it could switch sources as in this instance).  Now then, my previous song DID use the SH-201's patch in the pattern data; but the current song DOES NOT use it at all.  However, because the SH-201 VSTi is loaded and has been saved into the .MPTM file via an instrument's plugin setting, now when I attempt to load my file or any of it's autosaves or backups, OMPT freezes after loading the SH-201 VSTi.
 
The question, then:  Could there be an .MPTM 'editor' built which could allow loading of an .MPTM file and then allow the user to remove a VST/VSTi and then re-save the file?  [EDIT: Or, perhaps just a quick custom OMPT build that completely ignores (FE does not load, even) VST/VSTi's when opening a file..] Doing this, I will not lose the song nor the pattern data... if not, it looks as though I'll have to begin again from scratch.  Either way, I will be very careful about loading the 201's VST into songfiles, henceforth..

[Saga Musix]

Hey Chris,
I think you should try the command line parameter "/noplugs". It won't load the plugin list at start-up, so you can open the file and remove any plugin references and then re-save it.

[christofori]

Awesome -- I will try that!  I had just logged back in to mention that I'd tried to open OMPT (not loading the file..) and go into the plugin manager to remove the 201's VST and then load the song file; but it put the VST back into the plugin manager and loaded it on it's own... Following that I then went and renamed the .DLL file and attempted to load, which caused OMPT to freeze as well.  I'll try your suggestion (hadn't even thought of looking for CL parameters!..) and see what happens.  Worst case scenario might still at least allow me to recover the pattern data!
 
Thanks!

[christofori]

Well, I did get the file open and removed the VST from the plugin list, then resaved the file.. but then when loading normally it froze again.
 
I think I'm going to stick with this solution however, and just recover the pattern data into a new file.  Then I can do the sensible thing and build a project file... and start using it from here on out..!  (And although I do make periodic backups [in addition to OMPT's autosaves AND .bak file creation] I had only worked in this song for a couple of hours' composing time I'd say.. and hadn't made one of my own backups yet.. but it might not have mattered as I'm not quite sure why it's still freezing.. but it's moot anyway I think, at this point..!)
 
As always, thanks for your help and special kudos to you (in addition to my enduring gratitude..!) for the very quick response!

[LPChip]

If you copy the directory of OpenMPT to a new one, and inside it, set it to portable mode (you can do so in the mptrack.ini by setting portable=1) you can then open OpenMPT and remove all vst's/vsti's. Once done, loading the song will tell you that it didn't find the vsti's, and if you want to search for them on KVRAudio. Say no and you have a song without the plugins loaded, but with the rest in tact. Remove the plugins manually from the general tab (to avoid getting the same message) and save the file as a new name. I am not entirely sure if the cleanup menu can also clean up vsti's etc...

[christofori]

I'm (already / still) running in portable mode.. and I even still download the archive instead of using the installer for the new builds..   But I did remove the VSTs (using Jojo's suggestion of the command line parameter '/noplugs') and then save it to a new filename.  I'm in the process of building a more sensible/recoverable (in case of problems like this..) project/template file.  Though your suggestion would've also worked now that I think of it (wish it would've occurred to me before I'd made this posting; but eh, that's what happens when you're up late working on something!)..   I'd bet even simply renaming the plugins.ini file in my existing folder and then loading OMPT and opening the file would've worked, too.  But when you're faced with losing work, your (well, mine at least.. can't speak for anyone else!) brain doesn't always work with logic.

[Saga Musix]

Did I get that right that you removed the plugin in question, saved the file, reopenend it in a "normal" OpenMPT instance and the crash still happened? Somehow this would mean that the plugin wasn't the right one, doesn't it? :s

[christofori]

Possibly so; logic would dictate such at any rate.  However I'm at a loss to pick one that DID cause it as I made no other changes at the time I saved the file last, which would've caused it.  Aside from that, I also cannot explain how NONE of the backup files (autosaves nor the .bak) would open, either; as none of them would've had any change that would cause a freeze on open.
 
The thing that led me towards the 201's VST was that IT would load (there's a splash screen as it loads, and then upon it's init you see a dialog that reads something along the lines of "loading data.." and another "reading data.."...) and then sit there... waiting... for.. ev.. er... (if I didn't kill it).  However, as mentioned prior, I *DID* entirely remove and then even rename the 201's VST.dll file and similar issues were experienced when then opening a backup file; which did (try to, in the case of the 'renamed dll'.. lol, that one made me feel sorry for the tracker for a brief moment..!) auto-populate the 201 VST back into the plugin manager all on it's own... <sigh>
 
So (since I'm sure you're aware of my nitt-picky level of troubleshooting detail already..) having exhausted what I was willing to try I decided to just wipe all the VSTs from the file, rather than pick and choose and eventually discover the culprit.  Part of the problem likely is due to having so many loaded in the first place (as this was a song-to-song kind of file, I had accumulated a lot that weren't even in use but were loaded anyhow..!)...
 
No answers for ya; just more oddities.  I'm good at those.