assurance-tunnel
assurance-tunnel
assurance-tunnel
assurance-tunnel

Highest and Latest takes priority in Matrix Value Send



  • I have just submitted this as a bug report regarding the "mode" input on the Matrix Value Receive.  I was wondering if anyone else had an opinion on the functionality of these actors with regards to highest-takes-priority and latest-takes-priority.
    I am still experiencing improper behaviour with the "mode" input on the Matrix Value Receive actor.  This is particularly relevant when there is more than one Matrix Value Send active at any given point (either two in one scene or one in each of two active scenes).  When the mode is set to highest everything reacts the way I would expect and the highest level for any given value is observed.  But, when jumping between scenes there is a noticeable dip in the levels.  For instance if a value for a particular channel is at 50 in two scenes, when you jump between the two scenes that value will dip to 25 and then return back to 50.
    When the mode is set to highest the last Matrix Value Send that has been affected is the one that is sent to the Matrix Value Receive.  This is problematic because the values for EVERY channel is sent, even if it is not present in that Matrix Value Send.  This results in every other channel getting set to zero.  The expected behaviour would be for only the channels present in that Matrix Value Send (or better yet only the specific channels being affected) to change and all other channels remain where they were set by other Matrix Value Sends.
    In an ideal world, I would love to be able to select highest or latest priority on a per-channel basis. In a lighting context you would set all intensity channels to highest-takes-priority and all non-intensity channels (such as pan and tilt on a moving light) to latest-takes-priority.


  • Dear Craig,

    Well, hmmm... I see what you're saying about the crossfade problem. But my logic goes like this: the value of the Matrix Value Send is modulated by the intensity of the scene. When you're in the midst of a cross fade, Scene 1 is fading down from 50 to 0, and Scene 2 is fading up from 0 to 50\. In the middle of that transition (Scene 1 intensity = 50%, Scene 2 intensity = 50%) the highest value is 25.
    Now I can see why you'd want it the other way. But what about secondary scenes that are faded in or out using the Activate Scene and Deactivate Scene actors? In this case we would most definitely want to pay attention to the Scene's intensity, no?
    The problem from my standpoint is that the mechanism for activating/deactivating secondary scenes the same as the crossfade one. The Scene itself doesn't really "know" if it's in the midst of a crossfade or functioning as a secondary scene. Whatever behavior is chosen, it needs to be function consistently across all situations.
    Regarding the comment "This is problematic because the values for EVERY channel is sent": This is because of the way I programmed it. It seems to me that if no Matrix Value Send actors are present, then the outputs should be 0\. I can, however, see your what you're going after here: you want the values to persist until another Matrix Value Send actor specifically changes a setting. 
    But this seems just rife with problems and confusion to me. When moving from Scene to Scene using the mix mode, it seems to me you want to crossfade between specific values you have set, and if you haven't specifically said "channel x should be a y value" then the value should assumed be zero. If one did not do this, then you'd have to specifically add Matrix Value Send actors to set values to zero which, in most cases, seems highly undesirable.
    Even worse is this: moving through scenes out of order would cause all kinds of problems -- there would be no way to tell by looking at the scene if the output at that point were accurate or not. To me, this is Very Bad.
    I guess this whole thing is partially a matter of opinion and desire for a particular workflow. But, my main design goal is always to make things behave as simply and consistently as possible. The whole Matrix Value thing is already complex. By making different modes behave in substantially different ways, i feel it becomes even more confusing.
    I'm going to need to think this over. I look forward to your thoughts on the matter.
    Best Wishes,
    Mark


  • Here's how I see it working programmatically:

    The values need to be managed at the channel level.  For each channel there is a flag that says if it is HTP or LTP (set in the"edit channels map" window).  Each channel also maintains its own list of values - one value for every active Matrix Value Send (MVS) that contains that channel.  
    When a new scene is activated, all the values in the MVS are passed to the channels as well as the fade time.  If a given channel is flagged as HTP, the new value is added to the list.  It is then also checked against all other values.  If the new value is now the highest value, the outputted channel value is then faded from the previous highest value to the new highest value in the specified fade time.  If the new value is not the highest value it is still added to the list but there is no change in output.  Similarly, when a scene is deactivated, the value for the given channel is removed from the list.  If that value was the highest value, then the output is faded down to the second highest value in the specified amount of time.  If the value was not the highest value then it is simply struck from the list and there is no change in output. If there are no other values in the list, then the value can be faded to zero.  This behaviour can be consistent with scene activate/deactivate as well as jumps.  If a value is changed manually within a scene (or with an envelope generator, etc) then the same check for highest in the list can be made and the output changed in real time (if necessary).
    If a channel is flagged as LTP, then the values for that channel are stored in order of activation.  When a new scene is activated and the MVS contains the channel in question, the new value is added to the list and the value is faded from the previous latest value to the new latest value over the specified time.  If the MVS does not contain the the channel in question then no change is made to that channel. When a scene is deactivated, the value from that scene's MVS is struck from the list. If that value was the latest value, then the output is faded to the second latest over the specified fade time.  If that value was not the latest then it is simply struck from the list with no change in output.  If no values remain in the list then the value is faded to zero.  If a value is changed manually within a scene  (or with an envelope generator, etc), then the value is immediately changed to that value and that value then becomes the "latest" value.
    Hopefully that makes some sense.
    Craig

Log in to reply
 

Looks like your connection to TroikaTronix Community Forum was lost, please wait while we try to reconnect.