InputMorph (Value Cyclic)

Is there such a thing? Or a workaround?


proly few map nodes on inputs with range set to 0-1 and wrap

not really … at least not in a way that I could think of.

in the cyclic model the morphing direction depends on the value of the morph target, and maps with wrap don’t know anything of that.

hm…can you make a drawing that would show how this would work? apart from cycling the morph-value (which should be trivial) i have no idea how this could look like…

Well, I think it is actually quite trivial. Trivial to code, and ugly to patch:

Given input0 = 0.1, Input1 = 0.9 and input2=0.6.

If you morph from input0 to input1, output should be -0.1.

If you morph from input2 to input1, output should be 0.6.

If you morph from input0 to input1 to input2, output should be -0.4.

edit: and ah now what if the inputs change dynamically during lerp. I think there should be an option to keep the cycle direction during lerp, even if the inputs change and return a difference > 0.5.

from … from


from … to


to … from


thanks, björn. I edited my original explanation

waahh…i cannot follow, but i wonder if the innards of - (Value Cyclic) and/or = (Value Cyclic) could be of any help there?

if its easy to code, then you should code it and make a plugin…

as a starter, patch attached.
doesn’t work when jumping from one integer to the other.

generally it appears quite nontrivial when thinking of dynamic inputs:
think of having the morph somewhere between a and b, and both of them moving. heading of the difference should stay the same, but that could result in either a or b leaving normalized space.
further with 3 input, jumping from between b and c to a position between a and b: which direction do you go? backwards or wrap? since this affects whether a should be nearest to b or to c…

starter.v4p (13.4 kB)