Allowing 'Bypass Plugin' via PCE - possible feature request?

[Christofori]

Well, the subject pretty much states the question: Why can't a plugin be bypassed via PCEs?  What are your thoughts on the topic?  Sometimes it might be useful to bypass a plugin for a small section, whereas normally the plugin it is on.. for example.  Currently I believe one would have to modify the dry/wet ratio (if that's even possible with anything other than Zxx/SFx macros.. if even there..) inside the pattern data to do this.

Think of it like a distorion pedal on guitar.  You have a non-distorted verse structure but really wanna 'blow it out' during the chorus.. so you step on the pedal to engage it when the time's right.  Should be able to do that in the tracker!  (someone correct me if I've missed it, but it seems to be missing this feature).

[LPChip]

Why would you assume its not possible?

I assume with PCE you mean midi macros?

Assign a macro to the dry/wet slider, and set it to 0 to get your plugin bypassed.

[Saga Musix]

Why can't a plugin be bypassed via PCEs?

Because, as the name should suggest, they are Parameter Control Notes. They can only automate parameters. But yes, using a dry/wet Zxx macro might be what you want. It does not bypass the effect in the sense of stopping it, but at least it becomes inaudible (so it does what you want but it will probably not save you some CPU time etc)

[Christofori]

Why would you assume its not possible?

I don't -- I stated that I believed it WAS indeed possible in just the way you suggested... but as I had not yet ever done so and was relying only on memory I wanted to be clear that I wasn't SURE.

I assume with PCE you mean midi macros?

No; PCE is common (I thought..) shorthand for Parameter Control Event; PC and/or PCS "notes" usable only in the .MPTM file format; sorry for not being more clear!

Assign a macro to the dry/wet slider, and set it to 0 to get your plugin bypassed.

Yep, this is how I thought it would be possible... but guys the problem I have with this method is that there are only 16 macros..!  If you're like me (thank God there's only one me, but seriously..!) in that you use VSTi's (or their stand-alone equivilents as in my case... when PCEs are NOT AN OPTION...) that DO NOT show their parameters and/or allow one to assign or control ANYTHING VIA PCE (I have tried automation controls inside even the VSTi version of each player to no avail), you would want to keep as many MIDI MACROS free as possible.  I use more than 8-10 in each track currently, most for ARIA (Garritan) and some others for various PLAY controls... but if I were to need to use many more you can see I'd run out quite quickly.  Fortunately a few of the CC controls actually overlap in my case, meaning I can use the same SFx control (albeit with differing results..) seperately for each player's instrument(s).... but alas, I digress.

[EDIT: Let's not even consider how setting a macro to "control plugin parameter" will actually control MULTIPLE plugins at the same time, no matter which instrument number is supplied via the macro pattern data..!  I know this is by design; but it further limits the use of MIDI macros if one were to consider them to control VST plugins at all.  Fortunately this is negated if one chooses to use PCEs via .MPTM modules, anyway...]

Why can't a plugin be bypassed via PCEs?

Because, as the name should suggest, they are Parameter Control Notes. They can only automate parameters. But yes, using a dry/wet Zxx macro might be what you want. It does not bypass the effect in the sense of stopping it, but at least it becomes inaudible (so it does what you want but it will probably not save you some CPU time etc)

After reading the above response to LPChip, I'm hoping you can see the nature of my request a bit more clearly....

Besides, if one were to look at a VST like an effects pedal, whether the thing is engaged or not sure seems like a parameter to me (my hardware pedals both have a bypass switch on them... which of course enables/disables their OUTPUT but not their power state -- so speaking virtually towards the VST, a bypass switch option shouldn't at all change CPU utilization but only whether the signal(s) routed to said VST are changed by the VST... as a pedal's bypass switch doesn't change the power used by said pedal...); ableit we may merely be parsing terminology now.  It might not be a "true" parameter considering it's boolean; or considering it to be more of a host parameter than a VST parameter.. if the latter "floats your boat" better, then perhaps a HCE (Host Control Event) could be added into consideration, so as to avoid 'muddying' things more than needed..?

Again, as I use some libraries which allow ONLY MIDI CC#'s for automation (nothing else works... believe me when I say I've tried.. know you not that I tend to be thorough..?) in addition to other VSTi's which (thankfully!) DO respond to PCEs, it would be nice to avoid using MIDI CC macros for 'global' PARAMETERS like this.  In my specific case, I had wanted to use something like a PCE to change the bypass boolean of a VST effect in the tracker; thus I realize of course (and admit freely) that I wouldn't be able to bypass either standalone library I use with the method... but that's not the point.  The point is: why use a MIDI CC control for a VST?? 

Sure, not everyone fits the uniqueness of my particular case (how many people CANNOT use their sample libraries in VSTi form and must use VST2MID just to get them to work?  I realize you could probably count them on one hand..) so I realize it likely won't happen... but then I think back to nobuyuki's original request/post: http://forum.openmpt.org/index.php?topic=4075.msg35945#msg35945

People are out there... and if someone's music were to become so known as to actually draw attention to OMPT, more people might begin to flock towards it (possibly away from ProTools or other "real" DAW solutions...) and then (possibly) be similarly disappointed because they might not be able to control that one extra thing they needed in some external library, because they had to assign a dry/wet MIDI macro in it's place... for a VST effect...!  Shouldn't necesarilly even be referenced via MIDI CCs!...

[EDIT: Or perhaps solve all the problems by instead introducing a "MIDI Control Event" feature... let's face it, the "OMPT has poor MIDI support" line's just an excuse at this point, isn't it?  I mean there are 127 MIDI CC#'s (arguably 128..) and they should not be viewed at all to be interchangeable with VST(i) parameters; as plugins like VST2MID open a world of possibilities to those like myself, and make the 'poor MIDI support' stance moot.  Why then be limited to only being allowed to touch up to 16 of those 127/128 CCs?  Remove the confusion by making MIDI macros obsolete -- introduce a suitable replacement feature, and the "potential" (or perhaps "looming" is the better word choice in my own case...) problem of one day running out of controls is thus eliminated.]

Which now that I look back, nobuyuki's post wasn't ever taken seriously, either.  No response but my own.. and a negligeable number of reads, at that.

[sigh]

[Saga Musix]

If you run out of macros, you can instead use the Z80-ZFF section for switching between 100% dry and 100% wet - The "off" macro would be F0F00300 and the "on" macro would be F0F0037F.

[Christofori]

.. Well, that does indeed address the original question/request..

Forgive the ignorance in this question.. but is it really that difficult/time consuming to implement a control for midi CCs similar to the usability of a PCE, so that all 128 CCs could be controlled?  You're already technically allowing people to assign control of a CC anyway, so the code should be in place..  (If my coding skillz weren't so archeic I'd take a crack at it.. I know you're overwhelmed and don't mean to pile onto you by any means..!  I'm just imagining a sunny day sometime in the future, where all the feature requests and bugfixes are done/fixed, and you begin to wonder what's next... and then you think back and remember "Oh, chris and that other guy wanted CC controllers, and I've nothing better to do now that OMPT is perfect, so I'll add it!" -- it's that small a ray of hope for me..)

Argumentatively I am only asking because I am working under the assumption that libraries like Garritan will continue to add features over time, thus those control features will take yet another MIDI CC -- and there will (soon..) become a time when I will exceed 16 macros and become unable to continue working in OMPT.  I suppose that 'ray of hope' I'm trying to hold onto will hopefully occur around that time (except that it contradicts with the word 'soon' I just used.. but eh, I can dream..!)  I also don't want to get to the point of having to run a bunch of mixdowns, reprogram custom macro code for different instruments, and all that.  Call me crazy but I like the functionality of pressing "play" in the tracker and everything playing as it's supposed to.. but if you're telling me "there is no hope and we will not implement CC controls ever" then I might as well begin hunting for my new DAW solution.

[EDIT: I believe I am caught up to the 'page' you're on when you're speaking of global parameter control -- the tree view actually clarified it for me.  In it (for MPTM of course) one has: sequences, Patterns, Samples, Instruments, comments, and Plugins.  This helped me realize that the end-goal of MPTM appears to be heading towards templates/projects (as sequences implies multiple songs using the same samples/instruments/plugins, whatnot).  This I think I follow properly; however channel muting is global already if this scope of understanding I'm at is in line with your thoughts -- mute a channel in one sequence and it is then muted for all others as well..  Guess I still don't see what the 'big deal' is.  Sure, let's say you play a sequence that DOES have a setting to turn a plugin's bypass ON (bypassing it) and then you go play another sequence.  That 'you' in this example CANNOT claim fault on OMPT for the plugin being bypassed when they play another sequence (that didn't know any better..) as their bypass switch needed to have been reinitialized (and/or unset if you will..) at the end of their first sequence.  I dunno.. I guess it doesn't really matter whether I understand what you're talking about or not as I've got only one option (which involves disabling another control I may/may not want to use for samples/VSTs anyway) -- so either way you slice it I'm left with a work-around as a solution... As it stands, I'm already calling PC events to specifically set values of a VST before the VST is even used in the song, in case another sequence may happen to modify the VST parameter(s) before I have a preset saved as a 'just in case' -- is the implication that adding a bypass control switch via PCE = it'll mess up another sequence?  Hope not... that theory's got holes all thru it already.. ]

[Saga Musix]

but is it really that difficult/time consuming to implement a control for midi CCs similar to the usability of a PCE, so that all 128 CCs could be controlled?

Probably. I don't really have the time for that at the moment, though.

[Christofori]

I really do wish I had VS and the updated knowledge/skillset to help out.  I don't know squat about audio programming; just a basic (and dated..) knowledge of C/C++ commands and structure.. didn't get into visual.  Used gcc if I recall.. but that's not helpful I wouldn't guess, kinda need VS2003 at least as I understand.   If I can swing getting it over time, I might be able to help out with the small stuff though.. perhaps one day..!

There's a goal for you!   (well it's my goal.. well you know what I mean..)

[Saga Musix]

I think getting VS would be the very smallest issue when wanting to write code for MPT...

[Christofori]

From the (few) references I've caught in forum discussion relating to it's code, I can already state you're absolutely right.

However, my brain's not wired the same as most (oh, THAT's his problem then..! lol)... and though it might not at all transpire this way, I still like to think I'd somehow be able to relate to the code in a way as to follow it more easilly than someone with more 'proper' and structured code practices could.  Don't forget that the bulk of my 'experience' was self-taught and learn-as-you-go beginning with basic and pascal (similar to Mr. Lapicque beginnings if I'm not mistaken); so what today's programmers consider nonsensical and even 'bad practice' I'd be more accustomed to.  I just wish I didn't have the gap in experience that I do.. been since 2002 that I've coded anything in C/++ though I still have some books somewhere... Perhaps I'll work towards this goal after all, you never know.  I know it'd be uber-nice to have someone come along and reorganize the code structure to modernize it for you..   Can't promise anything but as time rolls along I'll dive in and see what I can break along the way..    Besides, doing so may be my only avenue to realize MCEs that I so badly desire..

[Rakib]

I guess the starting point is to download the code and read trough it. Visual studio can be downloaded used for 90 days.

[Christofori]

After these 2 songs I'm working on are done..

[Saga Musix]

I wouldn't say that the code is similar to something that someone who has used BASIC (like me) or Pascal for a long time might be accustomed to or could have written. On the contrary, it's just full to the brim with pointers, macros and old-fashioned code structures, and the latter is what has spawned many redundant pieces of code, or simply code that runs fast but is hard to understand (*). We have tried to make the code look better in the last years (while still being fast), but there is still a lot of work to be done, really.


(*) Here's a nice riddle for you: What does the following code do (m is a pattern cell)?

Code Select Expand

if ((!*((LPDWORD)m)) && (!*(((LPWORD)m)+2)))

Certainly not BASIC style, eh

[LPChip]

(*) Here's a nice riddle for you: What does the following code do (m is a pattern cell)?

Code Select Expand

if ((!*((LPDWORD)m)) && (!*(((LPWORD)m)+2)))

Oh this is easy!

The looped word of the patterncell has to be the same as the looped word of the pattern cell +2.... Or something...

[Saga Musix]

Hmm let's see...

[ ] Understood basic WinAPI data types and naming conventions
[ ] Understood the meaning of &&
[x] Silly post!