basic for loop fail

[oldgearguy]

Ok, I've been banging my head against this kind of thing in Lemur and I need to ask --

why can't a simple for loop work for any value higher that about 7700?

what I mean is -- if you have code like this:

for(i=0; i < 7000; i++)
Monitor.value = i;

you will see 6999 in the monitor.

Change 7000 to 8000 and you'll see 7691. If I have other things running ("on frame" scripts, etc) I usually can't go any higher than 5880.
Why can't Lemur simply execute the for loop for as many iterations as I specify? I have a lot of other questions on how the OS executes thigns, but I'm currently really stuck on this problem.

Thanks for any insights.

[Softcore]

I dont think "loop" is meant to be used as a "counter" in the first place....perhaps there's a timeout function for scripts so the loop is "disrputed" so to speak? It really looks like the script is not reaching its end (the "done" part is clearly not executed)

Do you really want such a long loop? or are you trying to achieve a counter or "delayed" function of some sort?

[Macciza]

Sounds like you are hitting the frame rate limit! scripts have to execute within certain time limitations . . .
Moving the test parts outside the script may help but may also introduce other timing issues

What are you wanting to achieve with so many iterations of a loop?

[oldgearguy]

I figured I was hitting into the frame rate window and each script has to complete in one frame or else results are indeterminate.

This ws a side effect of trying to figure out how the Lemur OS processes scripts.

At the end of the day, I'd like to have a simple way to insert a programmable delay between MIDI messages. That's all.

It would also be nice to be able to throw up a dialog that asks the user "are you sure?" before saving changes to a patch, but there seems to be no way to force the Lemur into that type of wait state where it won't continue through a script after displaying the window. What I observed is that it will display the window (since I made a call to show(user_prompt, 1);) but execution will continue through the main script without waiting for a response. Even if I try to make a call and say ret_val = display_dialog(userprompt); , any attempt to capture the yes/cancel button press is too late since the script does not wait for the user.

Obviously I can do it by embedding all the sysex/MIDI into the save/cancel buttons, but that ends up with a lot of duplicated code and there's still no way to pause the calling script at that point. It makes juggling the sequence of MIDI messages way more challenging than it should be.

I also observed (correct if I'm wrong) that Lemur will evaluate a script that executes "on expression" when for example you press a button in this way --
It reads through the script (including parsing commented out lines!!! - try inserting a " in a commented line) and determines the initial value of variables; then executes the lines in the script.

So, if you try to do something like:

//(globally) decl variable = 0;

while (1) {
if (variable == 1)
break;
}

and have variable being set from another button press or an "on frame" script executing, it never re-evaluates that variable, so it never breaks the while loop.

I'm really trying to understand how Lemur works through all the scripts and "on" event processing. When variables are instantiated, when they're re-evaluated, flow control, etc are all fundamental bits that need to be understood to make applications run better.

Another random bit -- if I have an "on expression" x going from 0->1 script, if I manually set that x value to 1 from another script, it will trigger execution of the 'on expression" script as if the button was pressed, but if that "on" script sets x to 0 and then calls the second script, does that re-trigger the first "on script" again? if so when and if it does, does that create an infinite loop?

I've been writing software for 25+ years in a variety of languages and I find that I write better code with a better user experience if I understand the language and platform I'm working in at the time. So, all these tests/questions are a result of me trying to code up a nice user experience for this TX-802 editor and trying to understand what the heck Lemur is doing while it runs.

So far, I've got about 100 hours in the project. Even though some of that is necessary design time to craft the UI the way I want, a lot of it has been spent trying to get Lemur to do something and then trying to understand why it works the way it does. There is no developer documentation that really explains this stuff. It really takes creating simple test projects that isolate the issue and then experimenting until the problem is solved, the system is understood, or a workaround is designed.