Hi,
I'm using some VSTi's in Modplug (no midi keyboard set up, so just entering the note data directly) and if I trigger a note on a track, when I play another note on the same track the previous note still stays on. Is there any way to set up Modplug to auto key off the previous note when a new midi note is called on that track without having to use '='.
Thanks for your help.
That should not happen. Do you use Portamento (3xx or Gxx) on that note?
QuoteI'm using some VSTi's
VSTi specialist here. That is most possibly not OMPT, but VSTi related issue (unless its a tricky bug, but i didnt experienced it yet). Some of them can feature multiple "virtual channels" or polyphony channels in them (up to 64 or even more in other cases) and if the internal envelope, sustains, loops are not setup correctly, the sounds will just continue to gather up in the background with every additional new note entered.
Solution is to setup your VSTi correctly. Either by checking the loops and the envelopes, or by switching the polyphony to "mono", means only 1 sound will play at the time, no matter what. The second is nice for pitch glided lead sounds for instance.
Quote from: psishock on February 02, 2011, 08:53:50
VSTi specialist here.
Solution is to setup your VSTi correctly. Either by checking the loops and the envelopes, or by switching the polyphony to "mono", means only 1 sound will play at the time, no matter what. The second is nice for pitch glided lead sounds for instance.
As far as I am aware the VSTi's are perfectly set up, it happens with any patch I use within Omnisphere and also Stylus RMX (set to groove mode) and trigger a loop with a specific note. Every time the sequence loops around, another note is played whilst the other continues in the background. The reason I believed it to be an issue within Modplug is because I downloaded a demo of Renoise and tested this issue there and the VSTi's work perfectly and as intended with no adjustment to the VSTi itself. However, after using Modplug for years now, I would prefer to stick with a program that I am familiar with.
Setting to monophonic isn't an option as I want to use these sounds as polyphonic instruments.
Thanks.
Quote from: Jojo on February 02, 2011, 08:07:37
That should not happen. Do you use Portamento (3xx or Gxx) on that note?
I agree, and it doesn't happen in a different tracker therefore I thought there was a required setting I'd missed within Modplug. I'm not using any portamento commands.
I think I have found the issue.
I normally use samples and write in XM format and even though I can add VSTi's to an XM I noticed in the instruments tab that under 'New Note Action / Action = Note Cut' this was greyed out. I started a new song in IT format and it works fine now.
What would be the best song format for me to use to get the best VSTi compatibility? What do you use when using VSTi's?
Thanks.
Use the modplugs own fomat. mtpm or what its called (dont have modplug here). It has lots of extra options regarding vst.
QuoteI think I have found the issue. I use XM format.
Yep, that's a problem. XM doesnt support VST plugins at all, no matter that you can "theoretically" load up external plugins in OMPT to it. It is a sample-only based legacy module format.
As Rakib suggested, use OMPT's own native ".mptm" format to get the best compatibility result.
Or if you prefer use ".it" (some lesser control over external plugins). Those two will work just fine.
Ah, I had this problem too when converting from one format to the other. .itp to .it in my case.
I mentioned this to Jojo and he guided me through getting my song to work.
In the General Tab, Song properties, there are some flags (check boxes) I had to change these. You should compare them with a new .IT song and set them the same to get it right again. That should allow you to change the new-note action on your adjusted .xm file.
Quote from: LPChip on February 02, 2011, 14:36:02
Ah, I had this problem too when converting from one format to the other. .itp to .it in my case.
No, It's not a problem with any flags, it's a general problem with VSTis not working in the XM format. Since this has been the case since like forever, there are two possible things to do:
- Remove VSTi support from XM alltogether (that's what I prefer)
- Fix it
QuoteNo, It's not a problem with any flags, it's a general problem with VSTis not working in the XM format. Since this has been the case since like forever, there are two possible things to do:
- Remove VSTi support from XM alltogether (that's what I prefer)
- Fix it
Please solution #1.
You are a compatibility driven person. I would go even fas as: VSTi "support" (together with all the non legacy extras) should be removed from all the legacy module formats. Including our new "hacked" .IT format. These hacked modules are only playable with ompt only anyway, if you try to load a vsti extended song to a normal, .IT compatible tracker or player, it will fail to play, or in the worst cases even fail to load. Basically we're speaking about format features and standards that every related programs are following*.
Our special extended command list, channels, rows and all the plugins, other fixes, "hacks", etc. should strictly stay in the OMPT's native .MPTM format. Every other tracker is working* like this with the non legacy stuff, for an obvious reason.
*(or at least, we would expect that ;D)
Thanks for all of the replies and advice, I think I will use the MPTM format. I'm guessing that most of the general commands are still the same?
Thanks again.
The most obvious difference are different effect letters (ScreamTracker notation instead of ProTracker notation), and also subtle and not-so-subtle differences in effect handling, mostly because of how fucked up some XM effects are (e.g. arpeggio).
QuoteThe most obvious difference are different effect letters (ScreamTracker notation instead of ProTracker notation), and also subtle and not-so-subtle differences in effect handling, mostly because of how fucked up some XM effects are (e.g. arpeggio).
i think he should be safe, most of the standard tracker effect don't really work with VST(i)s. I would even advise to avoid them altogether and use midi automation instead. Because VSTs were invented for midi sequencers in the first place, its the most natural way to control them.
Tracker effects are basically for the tracker's embed sampler engine.
Well, it would be much nicer to have some commands like panning working directly with plugins, and I don't see a point in not using them (when they actually work). It's simply more convenient to use pxx instead of Zxx or PC notes. And it's in no way inferiour to Zxx, simply because it's noted the same way in the pattern.
Not sure how far you went with making the general midi standard controls respond to the tracker effects. Last time i've checked (was several months ago) panning didn't worked also.
Just for clarification, can we have a list of fully working effects somewhere?
QuoteWell, it would be much nicer to have some commands like panning working directly with plugins
Commands that work are volume and portamento up/down. I have experimental panning control (also with envelopes, random variation and so on) and arpeggio code, but it's far from perfect.
Quote from: Jojo on February 02, 2011, 19:38:23
Quote from: LPChip on February 02, 2011, 14:36:02
Ah, I had this problem too when converting from one format to the other. .itp to .it in my case.
No, It's not a problem with any flags, it's a general problem with VSTis not working in the XM format. Since this has been the case since like forever, there are two possible things to do:
- Remove VSTi support from XM alltogether (that's what I prefer)
At least for new files saved with XM-extension. Completely dropping VST support even for old OpenMPT-made XM files seems a bit questionable given that modplug has allowed VSTs in XM for years without any warning saying that it's a ugly hack that shouldn't be used. Also I would consider dropping the VST support from XM's as a bigger change than dropping it from IT's because IT users have no problem switching to MPTM, but XM user don't have such option - ideally MPTM would provide ability to choose between XM and IT commands. It would be great to have some statistics how many people use VST's with XM's.
Well, I was mainly thinking about VSTi here as a first step, because as we can all see here, VSTis never worked as intended in the XM format (I checked with OpenMPT 1.17.02.54 and it does the same). Of course most portions of the code concerning VST also handle VSTi, but f.e. as a first step, the note events could be prevented from being sent to VSTis, effectively keeping people from using VSTis in XM files.
I would say we should go radical in this question Relabs. Compatibility is a very important question.
Sure it went like this for years, but ultimately if you apply a modplug-only extension to any of the legacy format, it will become straight broken. Other trackers may or may not even load it. All the extended controls should be grayed out in them.
It could be an option to leave them available, but as soon someone would use them, a warning would appear, and the song could be only saved in MPTM format (while "exporting" could be still available, but then all the extended stuff should be ripped off from the song again in the process, to make the module perfectly compatible with outer programs).
QuoteIt would be great to have some statistics how many people use VST's with XM's.
I would say about none, because vst and xm related stuff seems to be broken, as we figured out in this thread. :)
Quoteideally MPTM would provide ability to choose between XM and IT commands.
Not sure about all the legacy tracker commands, but if there are differences between them (asides from notation), we should make two MPTM formats to avoid incompatibilities. MPTIT and MPTXM or anything simpler if you prefer.
If all the effects, their function and behavior are the same, but only the notation differs, it would be safe to have one MPTM forman, and only choose between effect notation on the song properties menu for instance.
Quote from: JojoCommands that work are volume and portamento up/down. I have experimental panning control (also with envelopes, random variation and so on) and arpeggio code, but it's far from perfect.
Ok, then in this state its still not advised to use anything but midi to control VSTs (perhaps, aside from the listed two). Making tracker effect controls (the reasonable ones that is) compatible with VSTs extends the super long TODO list. :)
QuoteWell, I was mainly thinking about VSTi here as a first step, because as we can all see here, VSTis never worked as intended in the XM format (I checked with OpenMPT 1.17.02.54 and it does the same). Of course most portions of the code concerning VST also handle VSTi, but f.e. as a first step, the note events could be prevented from being sent to VSTis, effectively keeping people from using VSTis in XM files.
This would only work out well, if we would have a working MPTXM format as i've suggested in the previous post. Or to have a MPTM format, but with IT or XM effect notations, by choice.
Also, dont forget that making a vst compatible xm format (MPTXM) would mean a message to all the xm users out there: hey guize, you can use OMPT to code future modules with all your favorite xm effect notations and environment, but even can extend your work with external vst plugins!
I say many XM users, who are not really willing to learn and use all the IT commands (but surely want VSTi stuff) would find this feature charming.
Quote from: psishock on February 02, 2011, 21:13:51
Just for clarification, can we have a list of fully working effects somewhere?
Indeed. Is there a list of working commands to trigger VSTi's that I can look at ? Moving on from the XM format I want to make sure I'm using the correct commands. :)
QuoteIndeed. Is there a list of working commands to trigger VSTi's that I can look at ? Moving on from the XM format I want to make sure I'm using the correct commands.
pleas read the further comments also. ;)
almost none of the ember tracker commands work for VSTs, so its pretty much only in developer experimental state. Use the traditional midi or macro controls to handle them.
I use exclusively PC-notes to handle vst now. For how to use it, get the manual here:
http://forum.openmpt.org/index.php?topic=4067.0
Quote from: psishock on February 02, 2011, 22:37:42
I would say we should go radical in this question Relabs. Compatibility is a very important question.
Sure it went like this for years, but ultimately if you apply a modplug-only extension to any of the legacy format, it will become straight broken. Other trackers may or may not even load it. All the extended controls should be grayed out in them.
I'm sure we all agree that OpenMPT should produce standard XM/IT files and the GUI should tell user what is available and what is not in the format. But I don't think that the right and only solution for this would be to remove the extensions(which can't be completely done in any case if intending to maintain compatibility), because much of the problem can be solved simply by introducing a different file extension for the extended files. Until making the GUI improvements, yes user would still be in problems in knowing which of the features can be used in standard XM/IT, but it would be clear that the files using OpenMPT-specific extensions are not standard XM/IT.