MIDI/float thinning

[rotallicso]

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 ?

[Cphas]

Is there any reason that you can't use the grid functionality built into the fader object? If not then that will provide a much simpler solution

[rotallicso]

Sure .... for that example (range set artificially Low for testing purposes) that'd be just fine ... but that fix only works if you limit to 33 steps in total anyway, Thanks anyway! I need more and whilst the annoyance is lessened as you increase the fader range it's the midi overloading that bothers me

My query is regarding the implementation of the logic/conditionals - the example offered is merely to keep it very simple
Yet it doesn't seem to work

[Cphas]

Right I see your problem now. I haven't tried this myself but a possible workaround would be to use your current script as an intermediary and have another script that actually outputs the midi hopefully the on expression execution function won't trigger unless the value actually changes, but like I say I haven't tried it.

[mbncp]

What I'm doing is just store the value in a variable (single or array) , set it to -1 on load, do the math in on expression and check if the cc value has changed.
The thing is that this variable has to be outside of the script, as in-script variables get re-init each time.

btw., not equal is !=

if(val1 != val2) ...

you can also write:

if(val1 == val2) return;

[kraftf]

I think this topic is a valid feature request.
Either give us 128 grid steps or an auto thinout option in every object.
I've crashed my octatrack's midi input quite often using the multiballs and it would be a major drag to code everytiime a thinout script for an oject that you need reduced midi output.

[mbncp]

IMO the lemur should never send twice the same midi event for a given control. On the iPad/iphone, storing these values shouldn't use all the ram, while excessive midi output can become a problem.

[highmountain]

The problem in your script:

Your decl statement is redefining va1 and va2 every time. If you want a permanent variable, create an expression on the object. Use decl when you want a temporary variable for each individual execution of that script.

Also, the not equals comparator is "!=".

Another alternative:

Create an expression called "output" on your Fader, give it a value of 0 or whatever.

Click on that expression in the project browser and you can set up OSC/MIDI mapping just as you would for it's x value.

Set output to whatever you want instead of using ctlout and the Lemur will filter out dupes.

[rotallicso]

Thanks everyone.

It was a conceptual error on my part then. I'll get my head around the use of variables as discussed. It also explains why != did not work when I tried that originally.
FYI(liine) != is not listed in manual explicitly (or not in the relevant section)

PS The midi thinning issue which troubles everyone should be easy, I for one would like to see a simpler app work well than a more capable one work poorly

PPS I haven't tried Multislider yet, but I think it's gonna bug me if all values are punted out when i change one (at least it's easy to remedy in max)

[kraftf]

There is a much simpler solution regarding thining the midi output.
Suppose you have a fader.
Create a script that handles your midi message and for the triggering of the script use expression but you don't put the 'x' variable.
Instead you should put floor(127*x) for 128 values.
This along with others tips and tricks should be gathered in a wiki to make life easier for newcomers on Lemur.