Plugin-specific panning / volume macros - Opinions wanted

Saga Musix · August 08, 2011, 17:08:20

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?

Rakib · August 08, 2011, 23:50:02

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?

Saga Musix · August 09, 2011, 01:05:50

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

LPChip · August 09, 2011, 10:04:09

If you'd only make this work for .mptm songs, wouldn't that work?

Then you can use the 2nd method.

Saga Musix · August 09, 2011, 12:02:50

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.

LPChip · August 09, 2011, 15:33:34

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.

Saga Musix · August 09, 2011, 16:01:01

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.

Rakib · August 09, 2011, 16:56:30

Will there be any midi routing options with the new macro system?
http://bugs.openmpt.org/view.php?id=78

Saga Musix · August 09, 2011, 17:28:39

That's two technically completely unrelated things, and it's at least not planned to be implemented anytime soon.

LPChip · August 09, 2011, 19:40:58

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.

Saga Musix · August 09, 2011, 19:55:30

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.

LPChip · August 09, 2011, 20:55:43

Okay, then my opinion is: do it the first way.

Saga Musix · 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?

LPChip · August 10, 2011, 12:07:33

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.

Relabsoluness · August 10, 2011, 20:42:17

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?