General
MIDI/float thinning
Started by rotallicso on .
Sign in or create an account to join the conversation.
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 ?
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 ?
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
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
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
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.
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;
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;
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.
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.
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.
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.
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.
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)
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)
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.
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.
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 ?rotallicso wrote: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 ?
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.
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.
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 !
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 !
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 !
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
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
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 !