Plugin-specific panning / volume macros - Opinions wanted

Started by Saga Musix, August 08, 2011, 17:08:20

Previous topic - Next topic

Saga Musix

Not yet. but in this case, they are not affected anyway because VSTis still don't work in XM files. :)
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

Harbinger

Backwards compatibility is one of the nicest features of MPT.

I'm not sure what you're actually doing here (i just don't have time to digest what you're planning), but the MPTM format does not need backward compatibility as much as IT, mainly because MPTM composers have opted for PCEs since they came out. If i was composing IT tracks and still using macros, i need full backward compatibility.

Perhaps there could be a toggle in the Options dialog or perhaps an INI switch. IOW, keep the old code when translating old macros, but allow for an option to use your new macros for new tracks.

Was this a feature you always wanted, but only now are getting around to? Or was this requested by someone else?

Saga Musix

Quote from: Harbinger on August 11, 2011, 17:09:59Backwards compatibility is one of the nicest features of MPT.
And certainly one of the most frustrating ones from the coder's point of view.

Quotebut the MPTM format does not need backward compatibility as much as IT
How does that make sense? Why would MPTM not need backward compatibility, but IT, which is not even OpenMPT's own file format? I'd even say it's the other way around...

Quotemainly because MPTM composers have opted for PCEs since they came out.
...because PC Notes don't help a single bit in this situation. Panning / volume macros are supposed to be applied automatically, without having to enter an effect in the pattern editor. In fact, you cannot even do the same thing with PC Notes since they are applied globally to a plugin, unlike MIDI CCs which can be applied per-channel, or aftertouch events, which can even be applied per-note. So if you want your panning or volume envelopes to control MIDI aftertouch, you cannot do that with PC notes, but it could be done easily with the new extra macros.

QuoteIf i was composing IT tracks and still using macros, i need full backward compatibility.
I think you are confusing "macros" with "Zxx effects" here. Macros are simply strings of MIDI commands (which, at the moment, can for example be executed through a Zxx effect). The idea here is to replace the dropdown lists for volume and velocity handling in the instrument editor by a mod instrument-specific or VST instrument-specfic setting (and I strongly prefer the latter) which could execute any MIDI command, including those that are currently available from those dropdown boxes. The question here is simply whether we want a system that is easy to use and easy to understand or if we want to bloat the old dragon OpenMPT is even more by options that someone could have used ten versions ago. Seriously, the chance of a module breaking because of this change is relatively small because most people didn't even touch these options, and even if it breaks, you can fix your song.

Just imagine how likely this scenario is: One mod instrument assigned to plugin X uses the option "Volume handling: MIDI" and another mod instrument assigned to plugin X uses the option "Volume handling: Dry/Wet". Since they share the same VST instrument, this would mean that whenever volume events for the second instrument are encountered, they will also change the dry/wet ratio of the notes triggered by the first instrument, while if volume events for the first instrument are encountered, they would change the MIDI volume also of the notes triggered by the second instrument. Why would anyone want that to work? Just think about what I just wrote. This is what currently is possible, it totally doesn't make sense and we now have the chance to fix this stupidity once and forever.
Even if someone would has exploited this silly behaviour like described above, it is highly unlikely to find such a module "in the wild" since we all know that modern tracker users are too afraid of sharing they work as modules, because someone could steal it or whatever. That means that if someone used this exploit, they would probably be the only person in the world that has access to this file, so if they still want to listen to their tune they can just fix it. It's not like the file is write-protected after you finished working on it.

QuoteWas this a feature you always wanted, but only now are getting around to? Or was this requested by someone else?
Using native tracker commands to control volume and panning of VST instruments is something that everyone wants, I think.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

Harbinger

OK i think i understand.

Go full-bore with the non-backwards compat changes, but leave instructions on how to update old tracks based on the changes you make to the code. Your new plan does sound intriguing, and i wonder if it also fixes the "channel plugin vs instrument plugin" macro conflict.

I just would hate to work on one my old tracks with these new features, only to find out the playback is mangled.

Chang is s c a r   y... :o