Alright, this is REALLY screwed up...

[ForestCat]

Sorry for the subject, but try this and see if you don't agree,

Overview: a script which randomizes a monitor's value, attached to a pad's OnExpression x Up Trigger Mode. Tha Pad is named Pad:

Code: Select all

Monitor.value = rand();

Another script, attached to a second pad's OnExpression x Up Trigger Mode, which sets the first pad's x expression to 1, then back to 0. The pad is named OnOffBtn:

Code: Select all

Pad.x = 1;
Pad.x = 0;

Pressing Pad works as expected. Pressing OnOfBtn does nothing. WHY?????? So, further investigation:

changing the script to:

Code: Select all

Pad.x = 1;
//Pad.x = 0;

results in a new random number, and the pad stays lit, as expected. Changing it to:

Code: Select all

//Pad.x = 1;
Pad.x = 0;

turns the pad off, as expected. So:

Code: Select all

Pad.x = 1;
if (Pad.x==1){ // read the value right from the pad itself
    TrapPadXVal.value = Pad.x; // add another monitor to read and trap the value of Pad.x if it goes to 1 even for an instant
    Pad.x = 0; // turn it off ONLY if it's already on
}

The trap is sprung. Pad.x IS going to 1, but its script triggered on x up is still NOT executing.
I'm thinking maybe Lemur is tripping over itself? Lets add a little loop to delay the Pad.x=0:

Code: Select all

Pad.x = 1;
if (Pad.x==1){ // read the value right from the pad itself
    TrapPadXVal.value = Pad.x; // add another monitor to read and trap the value of Pad.x if it goes to 1 even for an instant
    decl i;
    for(i=0;i<9997;i++){ // loop to add a little delay
    }
    Pad.x = 0; // turn it off ONLY if it's already on
}

Here's where it gets even weirder. The astute among you are wondering, no doubt, "Why 9997???" I'm glad you asked that. Because, friends, for any value <=9997, the loop makes NO DIFFERENCE. But at >=9998, Pad.x=0 IS NEVER EXECUTED. This is where I throw my arms up and say:

WTF???????!!!!!

Attached is a small test template demonstrating this, for your listening pleasure

[oldgearguy]

been really busy, so no real time to go into depth...

the short answer is that Lemur works in frames. So setting the value to 2 different values in a row they all get executed in the same frame so you don't see the transition.

Same with a loop counter - try having a script that loops forever (something like x=1; while (x> 0) { x++; Monitor.value=x;} ) and you'll see it stop after a finite amount of time. That's the end of a frame of execution.

I've been bugging the Lemur developers to explain how this all works under the covers so we can better script things, but they haven't bothered to do so.

[ForestCat]

I appreciate the reply. Lemur template design has been, for me, 50% trial & error trying to find ways to code around things that don't behave according to the sparse available documentation or reasonable expectations based on decades of programming experience. Another 20% fighting with this pathetic excuse for an editor, which would be a frank embarrassment to any company/developer with a a gram of self-respect. Another 20% scouring the internet for the experiences/solutions of others experiencing the above. Finally 10% of "wow, that's cool! It works!" Lemur is a tragedy, in that it is on the one hand a brilliant, brilliant app that is currently without equal, and on the other hand, has been 80% finished for 7 years, and never will be, because Liine has clearly "lost that lovin' feelin'. It's 5 years past the time that they should have just released the source code already.