I noticed this issue today and made a small example to illustrate what I’m talking about (attached). By placing a Null CHOP set to Selective at the end of this patch, the Logic CHOP gives less consistent results. Nothing is actually reading from the Null, it’s just hanging off at the end. Disabling it fixes the problem.
In this case, I’m trying to hold the difference of only the most recently changed channel. There’s probably a smarter way of doing this, but regardless I find this behavior strange. Am I missing something super obvious about CHOPs?
I’m using the latest 61480 build, btw. weirdLogic.toe (4.32 KB)
Interesting, that’s a cool technique, thanks. I can’t recreate the error procedurally- the logic node (combine channels to Or or Exclusive Or) seems to be confused by the null only when sliding values around interactively.
Simply adding a lag after the constant fixes it, which is okay for now.
The Feedback CHOP may give somewhat difficult to predict behaviour.
For your specific example, have you tried the Slope CHOP?
It calculates differences between frames directly.
Similarly, you might use the Delay CHOP, and subtract the two CHOPs.
Here are 2 ways. CHOP Execute DAT outputs the difference when the value changes. It’s convenient that it already gives you the previous value.
Second is Rob’s idea: difference between current value of channels and the same but delayed 1 frame using Delay CHOP. To trigger the Hold CHOP, I generally use the Slope CHOP to detect when channels have changed. Logic CHOP turns any non-zero value to 1. weirdLogicG.3.toe (4.78 KB)
Bit late to the party - but thank you rob for your suggestion of using the Slope CHOP!
I’m running TD and UE5 at 30fps to minimise fps drops, but the Logic CHOP alone wasn’t happy reading very fast channel value changes coming from a piano through TDAbleton.
I put the Slope CHOP before the Logic CHOP now I have all my MIDI values normalised and coming in on time. Thank you again!