Change node returns NIL when the change is to/from value/NIL in 33.3

I’ve got a patch that uses select, change and s+h to latch midinotes, as in the picture. This always worked fine in previous versions, but i’ve just opened it in 33.3 and it’s not working.

It looks like the problem is the change node no longer returning a 1 when the default NIL going into it from the midinote becomes a value when a note is played.

Change used to return a 1 when going to/from NIL/value, but now it’s just returning NIL or 0.

Anyone got any insight or ways around this?
Many thanks

Maybe AvoidNIL is of some help. I’d place it before Change node.

thanks H99, I thought that’d probably help, but was hoping for another explanation/solution.
having just tried it, AvoidNIL does help, but the change was then triggering on both the on&off changes, so a togedge was needed as well.
That solves the problem, but it’s rather inelegant, I’ve got quite a few instances of these latched switches, and having to add 2 nodes to each of them isn’t great. It’s not the end of the world either of course, but if anyone has a slicker fix i’d love to hear it!

Well, Change is frame based and when a value in input changes (in the current frame), it bangs. From Change (Animation) helppatch:

outputs 1 when the input has changed in this frame.
outputs 0 if the input was equal to the one in the last frame

In the patch (33.3_x86) down here, Change seems to behave correctly. I mean, I’d expect that (in that scenario). Then, it’s true, I don’t know what your patch looks like and what you want to achieve, but consider that both Change and TogEdge are spreadable (and that you would not use Change, probably).


change node returns NIL (11.3 kB)

Sorry for slow reply (ive not had much time for vvvving this week sadly), and sorry, i thought i’d attached a screenshot of my patch with my initial question, but i guess i didn’t.
This time i’ve attached it! Although there’s not a lot of point as you’ve kind of already answered the question. avoidNIL and togedge will fix the problem, but i’m still curious as to why it’s changed in 33.X.
It worked in earlier versions of V, it seems like there the change still acknowledged (returned a 1) the change going from NIL to a value, but not from a value to NIL, which was perfect for me as it negated the need for togedge :)

But in the new version of V change doesn’t return a 1 if there is a NIL involved at all, either before or after a value.

I guess there’s little point in anyone explaining why this has changed because i won’t understand it! (unless you can spell it out in very basic terms for me!)
I’m still curious though…

I’ll just have to figure out a way to combine all my latched midi buttons into 1 spread so I don’t have to add loads of avoidNILs and togedges!

still managed to screw up attaching a picture, what is wrong with me haha!
I’m gonna try again just for the sake of my own practice, not that it’s helpful for any of you to see it!

hi fatalex,

this was supposed to be a fix which was done this January (2014).
First beta that had the change was beta32: node/154886

Changelog says:

The overall idea is that for any heavily generic operation you can interpret the input in different ways:

  • you wanna know if the whole spread changed or
  • you wanna know if a value changed and get a per slice info

I guess we changed the behavior for “Change (Value)”, since this is not a binsizes advanced version. It should work on per slice basis. This leaves room for designing another node that concentrates on spread change. We however shouldn’t try to implement both ideas within one node.

Note there is a hidden pin “Bang on Create”, which gives you the opportunity to define what shall be done on a per slice basis, if a slice was added since the last frame.

If you use this feature you will get a spread of ones when changing from NIL to anything else.

while the other node (change spread) doesn’t exist:

if you want to know if the whole spread has changed:

  • see if the count has changed
  • see if any slice has changed (changed + spectral or)
  • put the results in a OR
    you get a single bool for a spread (or subspread)

thanks for the explanation gregsn, it hadn’t occurred to me that what I was asking of the change node was in fact detection of a change in spread count, from NIL to 1, rather than a change in value