MIDI/float thinning

[axel_liine]

Hey
I am stumped (or there's an working issue)
I'm trying to thin the output from a fader ...
The fader range is a float 0-1, as you know
I can multiply this (e.g * 3) and floor() the result ...
so valid output is limited in steps to 0,1,2,3
however, the fader will send out countless duplicate messages between step changes
i tried an IF arrangement using a second variable (set within curly brackets which also contains the ctlout msg)
the logic check should have prevented(and thinned) the repeated ctlouts in one direction

a typical attempt was as follows
//++++++++++++++++++++++++++++
decl va1,va2=9999;
va1 = floor(x*3);

if (va1<va2)
{
va2 = va1;
ctlout(0,9,va2,1);
}
//++++++++++++++++++++++++++++++

there is no comparator for not equal, so i'd tried other strategies to achieve that to no avail
it makes me suspect that there's something not right (or my understanding is flawed)

fwiw - i know about using the 'normal' midi scaling - this is a scripting 'scaling' question for custom midi !

btw, the outcome is copious data in both directions of travel for the fader with the above script (on expression : value x)

any thoughts ?

You could just create an expression called "thin" inside the Fader, set it to : "floor(x*3)", and map it to MIDI without typing a complex script, no ?

[kraftf]

Yeap that solution goes too for more simple stuff.
Hey Axel, this solution should have been part of the manual or even better inside all objects a variable that is not float and would be suitable for midi.
Programs like midiox many times can't stand the float amount of data they receive espsecially when physics is turned on and as consequence there a steady data flow. The midi buffer constantly crashes on midiox.
I am very glad to have a found a simple solution but again this has been done the hard way.
By the way congrats for 3.04, problems regarding file size and communication between Lemur editor and ipad have benn resolved.

[rotallicso]

Aha
Yep - thinning by that means does work - it addresses the main concern of the post

however, i've noted that the output of values 126 to 127 is rather steppy

if you create an inbuilt cc out or use a custom ctlout with the above thinning via the 'on expression' tip given above

the faders will happily run smoothly up and down the range and the output values are as expected and immediate
however, when you get to the max (or 127) end the output is very very sluggish, it will pause on 126 then almost a 1/10 of a second later it'll output 127 !!
this is both visually with a monitor and externally looking at the timing of midi events

i also note that the thinning trick doesn't even output value 0 (it stops at 1) i'll look further into this (tested with a small fader on iphone)

i'm on the right path now - but there's still a few gremlins, any advice on those ??


EDIT:

FWIW - the last line here fixes the non-zero issue

Custom script on a normal fader with Execution 'on expression' with floor(x*127)


decl intx;
intx=floor(x*127);
ctlout(0,1,intx,1);

if(x==0)ctlout(0,1,0,1); <----- this enables 0 to be output, puzzled why it doesn't work without this though !

[rotallicso]

in case my above post reads out of sync with the thread before it - i hadn't seen page 2 til i posted my prev reply - will investigate the other solution suggested !

[rotallicso]

Okay - Yep, that Thin expression tip works great too - had never used that before, i'm wondering if the issue with the steppiness of the higher value is because there's only 1 float position (ie 1.000) which outputs that value, whereas the others are happening more often
it's very laggy going from 2 to 3 (taking the original simple idea in OP), but immediate going from 3 to 2

simple fader > Execution = on expression > with x
New Expression > Thin > floor(x*3)
New Script > name > ctlout(0,1,Thin,1);


EDIT:
This modification sorts out the lagginess, go from 3 to 3.1
New Expression > Thin > floor(x*3.1)

now jumping from 3 to 2 or vice versa is the same time wise

[rotallicso]

okay - bit late to this party - i can see that the physics mode being set to none makes the lagginess of the fader readout at the high value work as expected - albeit at the expense of a physics mode !