[scale] problem with scaling +/- 100%
I have a MIDI stream within 0-127 and want to scale it 0-100% in ’audio style’ by one knob.
I failed with [scale] objects alone.
Finally found a method with [function] but it looks like overkill.
Am I just too dumb or is there really no possibility to do it otherwise?
Please see the attached patch.
you could probably just replace the function with a zmap, but first i´d like to point out that the middle between 0 and 127 (or between 32 and 96) is 63.5.
so if you want precise control over panorama or pitch with a selectable center position here, you have to rethink the whole concept. (for example not using value 0 at all)
i just tried to rewrite it and i started by dividing both input ranges to a range 0. - 1 and then used multiplications.
Well, then sticking to [function] is just fine, thanks.
Regarding precision, no, don’t need to be precise. It is for scaling random notes. Actually I went up to 0-1000 and scale later down to the note/velocity range. So I can use it for effect parameters also.
But not using value 0 is a good idea, I will keep that in mind.
is this what you're looking for?
this is more flexible, in my opinion
No, it doesn’t go steep enough. Only halfways.
My description was wrong. 0% was ok, a flat line. But the steepest should be infinite percents. You know, 0 meter forwards and 1 meter upwards. Let’s say a smooth gainer that finally becomes a switch. This is what the method with the [function] does.
You need to invert the +100 % position result
Mhmm ... the function controls a multislider.
What does that tell?
Ah, I know – I stick to the function :-)
Never mind, I just thought there is a little math trick to ged rid of the function. But it is ok, it just sits in a handful of subpatchers.
[function] is basically mapping, you should be able to replace it using expr ((($f1-$f2)/($f3-$f2))*($f5-$f4))+$f4
1.)
2.)
3.)
unfortunately i made an error in picture 3, it doesnt work correctly, but that´s about how your patch looks as expression.
p.s.: now it works. :)
expr ($f2<=0)*(((($f1)/(127))*((127-abs(($f2/100.*64)))-(abs(($f2/100.*64)))))+(abs(($f2/100.*64)))) + ($f2>0)*(((($f1-($f2/100.*64))/((127-($f2/100.*64))-($f2/100.*64)))*(127)))
Wow.
I knew that it is *just mapping* because they must have programmed the [function] somehow ... but THIS is far beyond my horizon ...
Works perfectly and I was able to convert it for the range 0.-1000.
Thank you very much.
I think you can call yourself Roman Thilenius MOX.
Master Of Expression.
Both original patch with function and this superb Roman's expr exibit same
inverted output when scaling is set to + 100% and max number is sent through.
That was the purpose of the patch I posted, not to animate
function to multislider .
you can probably optimize that expr further (or use a better approach) but i thought it makes most sense to just convert his patch.
to avoid the usual mind-boggling "integer range releated problems" you can use float instead and all is good.
if i would write that for myself i would probably do it like that:
- the UI object would already output 0. - 1. (beside other things, very good for automation / preset saving)
- then the dial would be followed by
[expr ($f1*2)-1.]
[clip -1. 0.] [clip 0. 1.]
[change] [change]
- then those two seperate expressions for the lower and higher part from picture 2, but on base 0. - 1. for both inputs.
- where needed, round to 1 -127 for midi output. (if it is for velocity, too, anyway, ignoring the 0 is perfect)
of course, the value required for the maximum extrapolation factor (100%=?) will depend on this converted integer output (some *63.5 in the case of midi)
Thank you, Source Audio, for the heads up. I already started wondering why this thing does not really do what I expected in my patch. You made clear what happens.
Oh yes, this was my fault. I was happy that the [function] line moved nicely and the values moved but did not see that it does not work steeper then 45 degrees (max. output). After that it goes crazy. Roman’s [expr] does the same of course because he re-built what I delivered. Sorry for the bad request.
First time I looked at the original patch, I thought this looks like
attenuating 7 bit ( 0 -127) audio signal centered at value 64
in range of -100% - 0%, and kind of log gain and clip for the range
0 - +100%.