As a vvvv user you are most probably familiar with the node Map (Value)node. You would use it whenever you have to map a value from one range to another.
For example you want to use a hardware sensor input in the range 0..1000 to control the vertical position of a visual element on the screen in -1..1 range. And since you want to make sure that the visual element never leaves the screen you set the Mappingpin to ‘Clamp’:
So far, so easy.
Mapping in VL
Let’s see if we can improve on that in VL.
First we make three important observations:
- The Map node does two things, it maps the value ranges and also knows how to handle input values which are outside the input range.
- The mapping mode almost never changes during run-time for a particular use case
- The specification for both, the input and output range is by Minimum and Maximum (or Center and Width if you use MapRange (Value)node ).
So we separated all functionality in VL to gain flexibility in the following way:
Range
We introduced the concept of a Range. Its a simple generic data type that works for every type and has just two fields and two operations:
If the datatype has the operators +, - and * (Scale) defined, which is the case for numbers and vectors in VL, there are Center/Width nodes that you can use with it:
Range Handling
The mapping mode was a second functionality of the vvvv node and is now a separate story. We have a bunch of nodes which handle an input value that is outside a specific range in a certain way:
Map
The map node itself got pretty simple and just does what its name says, mapping the input from one range to another:
Convenience Nodes
Although the above nodes give the maximum flexibility, you would need to patch a few of them together for every use case. So of course we have convenient nodes that should cover most applications.
Since its often needed, the range from Zero to One:
UnitRange
We made for all nodes a version that takes Minimum and Maximum, one that takes Range and some which work with UnitRange:
Map Map (Range)
Clamp Clamp (Range) Clamp (UnitRange) Wrap Wrap (Range) Frac -> same as Wrap (UnitRange) Mirror Mirror (Range) Mirror (UnitRange)
There is also Mapping and Range Handling together:
MapClamp MapClamp (Range) MapWrap MapWrap (Range) MapMirror MapMirror (Range) MapDelegate MapDelegate (Range)
All nodes are generic and work for numbers, vectors and custom types alike.
Happy Mapping!
Comments:
Comments are no longer accepted for this post.
if the way to go is to have nodes for various combinations of functions of an old-node, maybe its more friendly to be specific to all of them ?
@u7angel
yes, a big part of the library is patched. it is very convenient because you can use adaptive nodes to make patches which work with many different data types which is what you want in a library.
concerning the UI question, the hidden (or much less space consuming) values in pins will be back in a later UI iteration. list as well of course… but not dates are fixed yet.
… or a much less space consuming solution ;)
having hidden values in pins is a bad concept in most scenarios. up to now there is no final decision on how it will look, but its clear that if a pin has a value other than it’s default, there has to be visual representation for it.
it is a bad concept to not indicate a change,yes and to solve the problem with extra nodes too
hello color
@antokhio
the value box in VL is something very different then the one in vvvv. the code is also different and does not do as much as the vvvv IOBox, so you cannot compare it in that way. but we are aware of the performance problem and we will work on that of course.
not sure about adding the MinMax version @ggml because the style is always to have no version title for the most basic node version. also in the nodebrowser you will see the signature of the node if you hover with the mouse over it:
@woei
added MapDelegate and MapDelegate (Range) that lets you specify what to do in the unit range as a region or a node with delegate input. does this cover your use cases?
looking at the map image, i still find it hard to see an improvement compared to vvvv
while in vvvv i just need a map node, in vl it seems i need 7 nodes to achieve the same setup. this makes the patches crowded but also requires a lot more user interaction. i dont want to imagine how my patches would look like with that kind of noise..
@u7angel
…which naturally includes the case on your second picture.
@tonfilm
delegate version look good! what would happen, if you go beyond unitrange in within the region? outofrange exception? guessing the math behind all this i also guess a 0 range will lead to a division by zero exception… any way for the user to handle these cases?
@tonfilm, probably need to get used to the fact the whole language is patched anyway.
concerning ioboxes, values hidden in pins might confuse a beginner but it allows to distinguish between important values and not so important.. making the patch more readable.
question: is there a way to have spreaded ioboxes like a list ?
@woei the mapping code looks like this:
nothing special will happen if you return values outside the unit range. the input range will throw a division by zero exception if From and To is the same. i thought about an if region around this part… but then decided against it because of performance. if it creates problems we can update the internals… as a user you can check From==To before the Map and cover the case in the delegate.