My request it for TRANSFORM to send the “Work with Value in Range” L/H values if next incoming value is less/greater then L/H range.
This way you have guaranteed L/H values appear on your output
my problem is when i divide e.g. cc#4 0-127 into two ranges,
with two TRANSFORM pipes e.g. cc#18 0-55 and cc#17(visible in the picture) 56-127 ,
and then i RESCALE both to 0-127
what happends is that 56-127 range(cc#17) will not end up at 0 if i move fader quicker down
i think i could be nice that if, TRANSFORM “Work with Value in Range L/H” when set to any other then Low 0 and High 127 , then incoming value is checked against e.g. Low 23 High 89 and if exceeds one of them then 23 or 89 is sent at the end,this will nicely sort to speak “close the range”
for example incoming data is 30,28,24,22 then just after 24 for TRANFORM to send 23.you get the idea.
My guess it’s very unlikely that Transform is going to get this capability, not least because
Transform already is ram-packed with properties in the byte-allocation that each pipe has (and I’ve seen no hint from @Giedrius that he thinks Midihub needs to be overhauled to add another byte per pipe)
Transform is probably the top of most users’ list of "Pipes I hear are Useful but find Really Confusing "!
Maybe what we need is a new pipe that, for now, I’m going to call Extrapolater
The issue is that MH isn’t receiving all the values it needs in certain circumstances cos our CC controller is skipping values to avoid logjams,
so this pipe would be designed to insert them into the flow at a roughly appropriate time by either using some kind of best fit to extrapolate (…see graph below)
or, if the user chooses Interpolate mode (with an accompanying microseconds delay) to monitor the CC stream skip the desired value and insert it in the delayed flow
This pipe would have other uses like being able to provide “missing” values when an LFO is too fast to provide them (e.g. my ADSR patch has to use Equalizer to get around this to pick up the end of the Attack LFO)
To make it really flexible, I’d also have it look for a range of values defined by a No. of Values and Values in Range Low|High properties; that would make it very useful for using variable LFOs to provide a (linear) sequence of Transformable values
A fair few edge case to pin down on this, but there’s the basic idea!
****
there’s room only for a data bit here and there {0:"Type#Bypass", 1: "Arg2|withAny", 2: "Arg1|Keep", 3:"What", 4:"Into|Mode|SetId|SetVal", 5:"WorkwValLO", 6:"WorkwIdHI|Use Id",7: "Priority RT|WorkwIdLO", 8:"with Channel|Set To", 10:"WorkwValHI",}
PS. @kazeko, if you want to make this topic a Feature Request, lemme know if you haven’t got the permissions
pretty sure it’s possible;
but I’m no coder so dunno how costly the the best-fit stuff might be compared to the manipulations MH usually does in its various pipes.
I’ll stick this over in Feature request just in case someone else picks up on it there and adds ideas
PS. I agree that Transform is worth the learning curve!
I could see a new pipe for this purpose, one that would have one or more configurable ‘stage’ / ‘boundary’ / ‘edge’, similar to the ‘filter in range’ pipes, but using single values instead of ranges. What the pipe would do is to monitor CC values, and whenever it notices the value crossing one of the edges, it would inject the CC of the edge value, and then the original new CC value. This will ensure, that zeros and maximums are achieved further down the line for pipes that depend on particular value ranges.
I am not sure though what sort of terms to use for the ‘edge’ parameter and the pipe itself - Stager, Edger, Stepper, Ensurer, Bounder ?
yep, that would work for @kazeko’s scenario…
…but not mine where a fast Saw Up|Down LFO never reaches 127|0
I guess the way you envisage the pipe “injecting” the “edge value” late is like an Insert Before the “crossing value”? If so, an extra option would be Replace the “crossing value” – useful for when you have a small range Transform waiting down the line to pick up but just one value.
(I use this kind of state -detection a fair bit)
If the AsYetToBeNamed pipe has the option of creating a CC of a different id/channel, this can be used to give direction-detection in certain scenarios.
with properties in the byte-allocation that each pipe has
