Peter Ostry

I have a MIDI stream within 0-127 and want to scale it 0-100% in ’audio style’ by one knob.

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?

comment

scale

message

split

function

live.dial

multislider

counter

toggle

metro

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.

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 fou

-scale-problem-with-scaling-100

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.


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.

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

You need to invert the +100 %  position result

Mhmm ... the function controls a multislider.

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.

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

grafik.png


[function] is basically mapping, you should be able to replace it using expr ((($f1-$f2)/($f3-$f2))*($f5-$f4))+$f4

1.)

unfortunately i made an error in picture 3, it doesnt work correctly, but that´s about how your patch looks as expression.

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)))


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)))


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.

I think you can call yourself Roman Thilenius MOX.

Wow.

I knew that it is *just mapping* because they must have programmed the [function] somehow ... but THIS is far beyond my horizon ...

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

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 those two seperate expressions for the lower and higher part from picture 2, 

- where needed, round to 1 -127 for midi output. (if it is for velocity, too, anyway, ignoring the 0 is perfect)


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)


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.

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

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%.


[scale] problem with scaling +/- 100%