Cutoff previous midi note with next

[psishock]

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?

[Saga Musix]

Well, 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.

[Relabsoluness]

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.

[Saga Musix]

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.

[psishock]

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

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

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

[psishock]

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.

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.

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.

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.

[Spock]

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.

[psishock]

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.

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.

[Rakib]

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

[Relabsoluness]

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.