I'm currently in the process of extending the current macro capabilities of OpenMPT. One of the next goals is to provide custom macros that handle plugin panning and plugin volume. Currently there is a very limited per-instrument system to control how VSTi velocity and volume are treated. This could be extended using macros in two ways:
- Add three macros (volume / velocity / panning) to each mod instrument, remove the dropdown lists that are currently there. This would be the most backwards-compatible approach, as the old settings could simply be translated to macros.
- Add three macros to each VST instrument. This approach makes a lot more sense, as I don't think you'd want volume / velocity / panning handling to differ between multiple mod instruments that reference the same VST instrument. Of course this would break old modules which which do indeed use different volume and velocity settings for a VSTi that is referenced by multiple mod instruments. But it would also be a lot easier to grasp and work with.
What's your opinion on this? Do you prefer the first or second method?
As long as older songs can be read, I favor the second method. Making mpt easier and more intuitive to use should be the main target when adding new function, so this would be one of the new steps.
I dont use macros so much anymore because of pc-notes, but can you control wet/dry with it?
You could do anything with those macros, including dry/wet control. The main advantage of this macro set would be that it would be automatically called on every tick, so you can finally have full volume / pan control for VSTis with maximum flexibility (because the macros can be set per instrument).
If you'd only make this work for .mptm songs, wouldn't that work?
Then you can use the 2nd method.
Quote from: LPChip on August 09, 2011, 10:04:09
If you'd only make this work for .mptm songs
Uhm, that is pretty much the plan.
I suppose we should then investigate who's using this in the .mptm songs.
I don't. In the songs where I might've used this, they're .IT songs.
Quote from: LPChip on August 09, 2011, 15:33:34
I don't. In the songs where I might've used this, they're .IT songs.
You mean you conciously used different values in the volume and velocity dropdown lists in the instrument tab for mod instruments that share the same VST instruments? In which cases would this be neccessary?
Oh, and just to elaborate on my previous answer - the old dropdown lists would be removed completely - importing from raped IT files would still be possible of course, but saving those values to IT files would probably not be possible anymore. I really want to get rid of all the MPT-specific stuff in IT / XM files at some point, and slowly removing seldomly used features as it has been done in the past few versions seems like a good plan to me. If you still need them, there is absolutely no reason
not to use the MPTM format.
Will there be any midi routing options with the new macro system?
http://bugs.openmpt.org/view.php?id=78
That's two technically completely unrelated things, and it's at least not planned to be implemented anytime soon.
I ment, that I don't use different volume/panning values in an .mptm file, because I nowadays use chainer, and in chainer I can set the volume and panning. My old projects that might have this, are all .IT files. This was from before I started to use chainer.
This has been quite a while, so it will probably break those modules then. Thats why I suggested that it might be best to only affect .mptm files. That'll cause the least problems, and if anyone has an .mptm file that still has this, they can convert it to .IT files to fix it.
Well, I will certainly not implement both behaviours, and I think the number of modules that would not play correctly anymore if the second behaviour is implemented would be marginally low.
Okay, then my opinion is: do it the first way.
Do you just prefer it because of your fear of not being able to play back your old tunes in new versions of OpenMPT or do you have other reasons why you prefer this way?
Quote from: Jojo on August 10, 2011, 12:06:44
Do you just prefer it because of your fear of not being able to play back your old tunes in new versions of OpenMPT or do you have other reasons why you prefer this way?
For the fear of not being able to play back my old songs that can have this problem.
Quote from: Jojo on August 09, 2011, 16:01:01
I really want to get rid of all the MPT-specific stuff in IT / XM files at some point, and slowly removing seldomly used features as it has been done in the past few versions seems like a good plan to me. If you still need them, there is absolutely no reason not to use the MPTM format.
Have you had plans how to deal with possible XM-files/users (who don't have mptm to switch to) that rely on extensions that MPT/OpenMPT has made available?
Not yet. but in this case, they are not affected anyway because VSTis still don't work in XM files. :)
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?
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.
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