Author Topic: PCE Behavior questions..  (Read 6700 times)

Offline christofori

  • Workaholic artist
  • ***
  • Posts: 124
  • Gender: Male
  • christofori -aKa- Chris Molyneux
    • christofori's official web site
  • Operating System: Windows 7 Pro x64
PCE Behavior questions..
« on: June 20, 2011, 06:41:23 »
OK you guys are already sick of me, I know.. :`(
 
PCEs (parameter control events, sometimes referred to as parameter control notes; applies to .MPTM format; either PC or PCs is displayed in the channel...) exhibit the following 2 behaviors which I am uncertain as to if they be intended by design, or a bug; if the design/function is intended, I'd appreciate some clarification as to why.. as it (in my mind) goes against the otherwise 'normal' operations of events/notes/effects/etc. within trackers.  I'll explain with each instance...:
   
  • If a channel containing PCEs is muted, the PCEs are still executed -- regardless of the "Ignored Muted channels" setting being set or not.  Any/all other event data in a channel is subject to the 'muted' state and/or the 'ignored' setting (if applicable) -- would there be reason for PCEs to be treated differently as they are?  This would mean the user would have to delete the PCEs in order to hear an uneffected segment, where simply muting a channel containing PCEs would be far friendlier.. forgive me if I'm missing something, haven't worked with MPTM or PCEs (worked only with IT files until recently**) and haven't found specific answers to the question(s) I'm asking (yet).  As most (including the OHM) seem to equate PCEs with MIDI macros (SFx and Zxx) I feel obligated to mention that they are ignored if their channel is muted.. ;)
  • MPTM modules that have PCEs which control parameter automation will unset the 'module has changed' flag upon playback.  Yep, simply playing a module causes the VST(i) settings to change; I understand that..!  I might suggest setting a flag to check if a detected change has been performed via automation or by the user... and ignore automation-flagged changes -- unless (again) I might be missing the rationale for why this would be important.  I have noticed that using PCs events can sometimes generate different results each time a module is played; but I also seem to remember noticing something similar about the macro/slide commands during playback so I'm not sure it's worth checking into.
That's all.. and if indeed these could be bugs at least they should be easy fixes, and not some big new feature one guy wants to have.. :P
 

**Note: Recently -- that was about the time I began using ARIA and PLAY in combination with several VST effects and VSTi's AND samples ... so, right about when I ran out of MIDI macros for everything I wanted to do..!  This necessitated my adoption of the new MPTM format, which I love but have a few slight concerns about it's functionality and consistancy, is all. ;)
/christofori
'slightly disturbed and wonderfully content'
*Master of the Obvious*

Offline Saga Musix

  • OpenMPT Developers
  • *****
  • Posts: 7,333
  • aka Jojo
    • Download music, samples, VST plugins: Saga Musix Website
  • Operating System: Windows 10 x64
Re: PCE Behavior questions..
« Reply #1 on: June 20, 2011, 11:05:50 »
regardless of the "Ignored Muted channels" setting being set or not
This setting only affects sample syncing. That said, I very much would not want PC notes on muted channels to be ignored; Think of them as a global setting; and now think of other global settings like the Vxx effect - is it affected by the channel's mute status?

Quote
MPTM modules that have PCEs which control parameter automation will unset the 'module has changed' flag upon playback.
That must be a bug in the VSTs you are using, they possibly send an automation command back to OpenMPT when they received automation data. Doesn't happen with any of the plugins I'm using.
» 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.

Offline christofori

  • Workaholic artist
  • ***
  • Posts: 124
  • Gender: Male
  • christofori -aKa- Chris Molyneux
    • christofori's official web site
  • Operating System: Windows 7 Pro x64
Re: PCE Behavior questions..
« Reply #2 on: June 20, 2011, 14:59:47 »
.. wow.. okay.  I'll just delete a range of PCEs and use 'undo' whenever I want to temporarilly remove the effect and possibly/hopefully put it back.. or I s'pose I'll keep a(nother, hehe) spare sequence set aside for placing PCEs that I haven't decided to keep for sure, yet (to me, doing so is indeed simpler/easier to keep track of, than it would be to re-create...)

I fail to see how/why they should be global other than you saying for me to do so.. if they are specifically implemented (as everything I've read has stated or suggested..) for controlling plugin parameters, then follow this line of logic for a moment; does one HAVE to have a plugin control ALL channels or none at all? (I realize you could, but it'd be messy)...  Plugins ought to be viewed as manipulators for individual sounds/instruments (albeit virtual in some cases)... and inside that scope they certainly aren't global (ie: applicative to all other samples/instruments/channels/what-have-you's in the tracker..!)

Now I do understand of course that they're global in the context of the PATTERN itself (you can put events in any channel and they'll do as designed, since you specify the plugin, parameter, and value per each event..) but that's barely worth calling them global in overall scope and operation.  That would imply they work much more like CCs than individual plugin para controllers, which simply is not the case..! (IE a CC could be mapped to control several plugin para's and then a macro could be used to slide them all up at the same time, using the 1 CC's macro..) THAT's a global scope in the context of instruments... which is where my mind's been centered during this line of thought...

Really -- and I'm not being sarcastic or snide as (again) I know you probably don't have the time at all -- but if I'm totally off base and you don't have time to point me to something to study on the topic, nor personally share the 'missing link' of knowledge I'd need to shed light onto my dark little CCless world here, it's cool man.  I've been in the dark most of my life and am kinda used to it I suppose.. ;P
/christofori
'slightly disturbed and wonderfully content'
*Master of the Obvious*

Offline christofori

  • Workaholic artist
  • ***
  • Posts: 124
  • Gender: Male
  • christofori -aKa- Chris Molyneux
    • christofori's official web site
  • Operating System: Windows 7 Pro x64
Re: PCE Behavior questions..
« Reply #3 on: June 20, 2011, 15:11:08 »
Point of clarification regarding the "control parameter automation will unset the 'module has changed' flag upon playback" issue (not calling it a bug)..:
 
I have not yet tested with another VSTi/VST and PCE; but I did just now discover that it ONLY happens when the plugin window is open as the module is played, and the playback includes/triggers PCE's for said VST.  No, the plugin is not still in record params mode nor are any channels record-selected.  I will do further testing as it is quite possible to be a bug in the VST as you suggest; and frankly I'm curious to see if any of the other 'staple' plugins I tend to use will do the same or not.  Will let you know more on this when I have it..
/christofori
'slightly disturbed and wonderfully content'
*Master of the Obvious*

Offline christofori

  • Workaholic artist
  • ***
  • Posts: 124
  • Gender: Male
  • christofori -aKa- Chris Molyneux
    • christofori's official web site
  • Operating System: Windows 7 Pro x64
Re: PCE Behavior questions..
« Reply #4 on: June 20, 2011, 15:54:29 »
That must be a bug in the VSTs you are using, they possibly send an automation command back to OpenMPT when they received automation data. Doesn't happen with any of the plugins I'm using.

I can confirm that it is local to (so far) just one VSTi I use.

=-=

Just back to the 'ignore muted..' line of thought.. -- I know (and have always known..) that it only deals with sample syncing... I only mentioned it in the original question because I thought to check it anyway... perhaps overly-thorough to a fault. ;)  However, please continue to follow me here briefly:

1) PCEs globally control VST/VSTi plugin(s) and/or parameters therein.  OK, got it.
2) A muted channel containing notes on an instrument with only a VSTi loaded (no sample data..) doesn't playback thru the VSTI.  .. uh, .... hmm.
3) If PCEs are global then evidently VSTs are not.

Do you get my point?  PCEs are presented to the end user as 'notes' in several places; yet they behave completely ignorantly towards whether or not the channel they're in is SUPPOSED to be playing back ANY notes of any kind... either mute should NOT mute VSTi's OR it SHOULD mute PCEs..! (why else would someone want to mute a side channel (containing control events only..) anyway?  IT IS THEIR OWN FAULT if they mix another instrument's notes into the channel (how many channels can you have again?  Oh, enough to dedicate at least one solely to PCEs for a particular plugin .. that's right.  No need to use a channel for an instrument and then for PCEs some 5 patterns later.. in fact that I would consider to be a bad practice on many levels (you cannot change a channel's label/header name mid-sequence after all...)

*scratches head*

I'm lost.  This is nonsense.
/christofori
'slightly disturbed and wonderfully content'
*Master of the Obvious*

Offline Harbinger

  • Extreme artist
  • *****
  • Posts: 1,146
  • Gender: Male
  • Operating System: Windows XP
Re: PCE Behavior questions..
« Reply #5 on: June 20, 2011, 21:59:48 »
I get where you're coming from, but don't understand your whole intention. I work with MPTM tracks nearly exclusively, and most of my work involves VSTs and PCEs, so i can understand your perspective...

PCEs are not notes, but they ARE events (in the sense that they must be processed on some level but at a specific time). I have used muted channels that use VST-based instruments (as well as channel assigned VSTs) and passed PCEs to monitor the effect on the VST in its GUI window. I prefer to be able to apply a PCE without actually outputting from a given channel OR VST so that i can do little audio routing tricks either for effect or for monitoring.

My point is, don't worry about it! 8) If you haven't used PCEs yet, you will find them a godsend, and you work with whatever limitations they present that may be inherent in their use. Except for plugins that can't be manipulated by PCEs, i don't even use macros anymore. That's how powerful they are. PCEs are virtually exactly the same as turning a knob or pressing a button on your synthesizer. As such, they may be internally handled somewhat differently than a macro or note event. Sobeit.

If you need tips on using PCEs, Jojo created them, and i tested them extensively for the OHM. I'm sure we can help you see how easy they are to use and get EXACTLY what you want from your VST... ;D

Offline Saga Musix

  • OpenMPT Developers
  • *****
  • Posts: 7,333
  • aka Jojo
    • Download music, samples, VST plugins: Saga Musix Website
  • Operating System: Windows 10 x64
Re: PCE Behavior questions..
« Reply #6 on: June 20, 2011, 22:47:42 »
If you need tips on using PCEs, Jojo created them
I think I clearly stated at least once that PC notes were the brainchild of and implemented by Relabs, not me - I didn't write any of necessary code.


Anyway, chris... Of course there are two ways to see this, and mine (which you don't have to share, but that's how I prefer it to work) is:
- Notes, no matter if handled by a sample or a plugin, are one thing, effects are another.
- Notes are affected by the channel's mute status, effects aren't (example where this is obvious: Zxx, Vxx, Txx, Axx, Bxx, Cxx, PC "notes"/events).
- The only format which OpenMPT supports that has effect muting is the S3M format. And believe me, it is totally not cool to have global effects being affected by the channel's mute status. For example, you might miss an important pattern break or tempo change just because the corresponding channel is muted. Thus I think all effects (and that includes VST parameter manipulation) should not be affected by the mute status.
Now of course the term "PC Notes" might give the wrong impression of how they work here, but really, they aren't notes in this sense, they even occupy a whole pattern cell and not just the note cell. They're probably just being referred to as PC Notes because of how they are handled internally.

PS: Making the "ignoring" part when muting channels a global setting won't work, either, because the channel mute status is saved to files,  but a global setting obviously cannot be saved to a file.
« Last Edit: June 20, 2011, 22:50:48 by Jojo »
» 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.

Offline christofori

  • Workaholic artist
  • ***
  • Posts: 124
  • Gender: Male
  • christofori -aKa- Chris Molyneux
    • christofori's official web site
  • Operating System: Windows 7 Pro x64
Re: PCE Behavior questions..
« Reply #7 on: June 21, 2011, 02:18:52 »
...and mine (which you don't have to share, but that's how I prefer it to work) is:

LOL -- I can see so! ;) 

I have no problems using PCEs, guys.  I've been succesfully using them during my past two songs and find them quite easy to understand, once you dig in and do it a time or two -- they're actually beside the overall point of my bringing these two threads to life recently.  Asking if they could be affected via channel muting was something that'd make life somewhat easier for me; yet perhaps impossible for you -- so scratch it.  I'll manage.

A lot of the confusion I'm sensing here is indeed because of my own lack of understanding for the internals of OMPT -- though I've used it for quite a long time now, I didn't begin to 'poweruse' it (or push the envelope of my skillset, if you'd rather) until I began tracking and releasing songs again earlier this year.  I can see that some of what I've asked wasn't 'encapsulated' by you guys; and I can also see that it was likely due to my own improper understanding which caused any confusion for you in trying to understand and then address my thoughts.  In other words: I couldn't explain it as well as I should have; but I feel it's pretty moot at this point.

I get where you're coming from, but don't understand your whole intention.

This all stems from the 'MIDI CC' issues I and (so far...) one other person have noticed; much of the resultant discussion (or back-and-forth perhaps.. :) is in another thread.  The quick version of the story begins with my use of both the Garritan Personal Orchestra 4 library (via their ARIA player) and the Complete Composer's Collection from EastWest/Quantum Leap (7 of their libraries on a massive hard drive they ship to you).  I can actually use the VST version of ARIA just fine with OMPT; but it does not work with PCEs or even allow a peek inside to the parameter list; instead they force you to utilize MIDI CCs for several parameters.  However, PLAY (the engine for EWQL's libraries now... ugh..) does NOT at all work in OMPT as a VST -- so I've had to run it's standalone player and control everything via MIDI notes and events using the VST2MID component of midibag.  Currently I also run ARIA in this fasion as it relieves some tension for the tracker concerning memory usage. 

That said.. ARIA has me tying up about 8 CC/Macros and PLAY's got me using a few.. the fortunate thing for me is that I can 'route' the CC controls via MIDI channel to the appropriate instrument; and also that common CCs (like vol/7 or modwheel/1 FE) are used by both samplers (though not always for the same type of parameter or effect...) so ... the point of my OTHER post has been to raise awareness on these kinds of samplers (or VSTs, some do exist that don't work with anything BUT CCs) as eventually I'm going to work myself away from OMPT as I'll have run out of controls.  I've gotten 'a bit here, a bit there' which actually helps (Thanks Jojo.. the dry/wet stuff's in my notes and I might need it before too long, especially if I ever become inclined to write a full orchestral song...) but doesn't 'paint a pretty picture' for my future with tracking, unfortunately.  I just hope that day never comes.. I'm 'stuck' on composing with OMPT -- nothing else works for me.  I think it's because you can do so many freaking awesome things with it that other software finds problematic (sometimes, a sound you obtain may even be unintentional but end up kept as it sounds damned cool!!)

If my skillset with C/++ were up to date and I had the required tools, I'd jump at the chance to tackle a MCE (MIDI control event) feature in OMPT -- but I can't even begin to be helpful there, either.

=-=-=

However, THIS thread was more along the lines of "Hmm, I thought this did that instead..." and having not found clarification on my own, I asked. ;)  Also thought I found a bug, but it was a bug/oversight in the VST and not OMPT.. ;)
/christofori
'slightly disturbed and wonderfully content'
*Master of the Obvious*

Offline Harbinger

  • Extreme artist
  • *****
  • Posts: 1,146
  • Gender: Male
  • Operating System: Windows XP
Re: PCE Behavior questions..
« Reply #8 on: June 23, 2011, 14:59:00 »
If you need tips on using PCEs, Jojo created them
I think I clearly stated at least once that PC notes were the brainchild of and implemented by Relabs, not me - I didn't write any of necessary code.

My bad!! And i'm sorry, Relabs, for not giving you proper credit!  (You're always invisible. We don't know what you do! :D )

Offline christofori

  • Workaholic artist
  • ***
  • Posts: 124
  • Gender: Male
  • christofori -aKa- Chris Molyneux
    • christofori's official web site
  • Operating System: Windows 7 Pro x64
Re: PCE Behavior questions..
« Reply #9 on: June 24, 2011, 13:35:23 »
Kudos to Ralebs from me as well, as I've had 1000% more fun than one should have since I started working with PCEs.  What I thought I'd never be able to do without sampling one synth performance at a time (which would be control so many para's at once..!) is very sweet!  I can even use them to control my hardware synth's knobs from within the trackuh! Booyeah.  And stuff.

I used to layer sampled instruments and 'weave' them back and forth to do what I can do with one VSTi now that PCEs are reality. :D

...

Also I shouldn't overlook that other guy though.. :P   Props to Jojo for helping and/or putting up with me so much! :P
/christofori
'slightly disturbed and wonderfully content'
*Master of the Obvious*

Offline Relabsoluness

  • OpenMPT Developers
  • *****
  • Posts: 714
Re: PCE Behavior questions..
« Reply #10 on: June 25, 2011, 17:34:57 »
I agree that disabling parameter controls on a channel is more difficult than it needs to be: while some effects should not be affected by mute status, parameter controls seem like a good candidate for the opposite behaviour. Perhaps the easiest way to rectify the shortcoming would be to introduce a modflag to tell whether channel mute should affect the PC notes. A better but much more arduous option would be to introduce PC-only channels which would have enabled/disabled status. And a third way, not exclusive with the previous, is to introduce both mute/unmute and enabled/disabled status to channels.

Offline christofori

  • Workaholic artist
  • ***
  • Posts: 124
  • Gender: Male
  • christofori -aKa- Chris Molyneux
    • christofori's official web site
  • Operating System: Windows 7 Pro x64
Re: PCE Behavior questions..
« Reply #11 on: June 26, 2011, 01:23:12 »
No matter the given choices there'd be an update to the MPTM format spec... I don't know if many others would even want this feature even though I think it should be there (I'm one person).  Whatever happens, happens of course -- but I'm getting really good at moving my strings of PCEs from between sequences.. in the mean time.. ;)

Seriously.. I've set a seperate sequence aside with a few spare patterns to organize 'templates' of PCE's that I can then quickly implement when needed.. and sometimes use it as a 'clipboard' buffer when I'm evaluating or otherwise tweaking combinations of PCEs in a track.

Back to the options, though -- I would recommend AGAINST the PC-only channel option as you might have to set a limit for how many there could be... when you've got people like me that go about controlling 10 at a time for one synth... imagine the overhead that could build up.  (actually most I've done at once [simultaneously automating multiple controls for ONE synth that is..] is 4 or 5 .. but still.. I'm a Freak Show in the Excessive sense..!) :P
/christofori
'slightly disturbed and wonderfully content'
*Master of the Obvious*

Offline Harbinger

  • Extreme artist
  • *****
  • Posts: 1,146
  • Gender: Male
  • Operating System: Windows XP
Re: PCE Behavior questions..
« Reply #12 on: June 27, 2011, 20:05:30 »
From a programming POV, the simplest way is the first method by Relabs: introduce a global option that the user can toggle which simply bypasses PCEs in muted channels. However, i can see some users turning this off and on in the same track while composing, so i would also add a keyboard shortcut for this toggle.
 
From a tracker's POV, he would want to apply it on a per-channel basis. Fortunately it's only one bit extra for each track channel, but it would require a little more GUI tweaking from the programmers. Perhaps this should bump the Feature Request for an updated Channel Manager. (What's a little plug between friends? 8) )

Offline Relabsoluness

  • OpenMPT Developers
  • *****
  • Posts: 714
Re: PCE Behavior questions..
« Reply #13 on: July 02, 2011, 09:15:12 »
No matter the given choices there'd be an update to the MPTM format spec... I don't know if many others would even want this feature even though I think it should be there (I'm one person).
Updating MPTM specs is not a problem.

Back to the options, though -- I would recommend AGAINST the PC-only channel option as you might have to set a limit for how many there could be... when you've got people like me that go about controlling 10 at a time for one synth... imagine the overhead that could build up.
The limit is not something to be concerned about: at least the way I thought it would naturally set the limit of PC-only channels to the same as limit for pattern channels.