do loop

[Macciza]

Hi
I understand your frustration and have experienced similar over my time as well . . .
Often it can be worse when we are so used to doing things a particular way and it suddenly doesn't work the way we expect . .
Or we get so caught up in making our way work that we forget about the environment in which we are working, I' did that earlier. . .
All I can say is Don't give up - take a break and let inspiration come after some thought - other solutions will be possible . .
Anyway enough psuedo-psycho-babble . . .

I am sure you understand what I mean - it is a Granularity problem, a do while can't exceed it's execution time/frame boundary, I don't think.
Now 40ms is a different thing to 4 sec as was used earlier, and makes it all a lot easier I think.

I would suggest forgetting about 'time' as a reference point for what you want to do
Use 'Frames' as your reference and count/compare frames not time. This is because of the 'Granularity' mentioned earlier - things happen 'per frame'.
At the nominal 60 frames a second which I believe is fairly consistent, (despite disclaimer from the Legacy documentation) frames occur ever 16.66r msecs.
This grain-size means a 1 frame delay is 16.6msec,2-33.2,3-49.8 etc co for your purposes choose either a 1 or 2 frame delay and implement that.

Rather than creating a looping as you would in a realtime environment, make use of the OnFrame 60hz loop implicit to Lemur, makes sense?

Will have a look at this problem - I did have a look at the project you posted and the timing issue there but did not solve anything, not knowing what some of the expected values were and scope of operation etc. The circularity of the various time definitions kept getting me, I think a reference time variable is what is need possibly similar to what I did in the earlier post, or a frame-based approached for short delays.

Hope this makes sense - will have a look at problem and see what comes to mind
Cheers
MM

[axel_liine]

For every frame displayed, all Lemur scripts are executed. Things happen synchronously, so while a script executes time doesn't "move". The time variable is evaluated at each frame, which typically happens 60 times per second, and less with very heavy templates or lots of scripts. So a loop in a script that waits for time to cross a certain mark will never exit, since time is "frozen" in a way. (Actually there's a watchdog that makes sure script eventually exit and the app is not stuck indefinitely).
Maybe this is not made clear enough in the manual ?

[joebataz]

Thanks Macciza and axel_line. My season is coming up and having this template work would vastly simplify what I need to do and replace the tedium with more time for creativity. A couple of things. First I would definitely supplement the manual in regards to how time "works" in the Lemur environment. Even with all the discussions about this point I am still a little fuzzy as to how to implement it effectively. In light of that I would include somewhere on this forum a tutorial topic which contains nothing but Liine generated help content and selected user videos/methods. There are gems of knowledge spread throughout the forum but just about all of them I have found accidentally while searching through for other topics. Same for code. I realize its a lot of effort to do this but I think would help immensely.

Back to my nemesis issue; if I understand this correctly I need 3 frames to achieve my target delay. This would be equivalent to 3 different ascending values of;
floor(time) + time%.25
The following would be in an OnFrame script
cFrame would be equal to
floor(time) + time%.25
playing would be equal to saying I'm in an execution state and I need to start counting frames.
I grab the current cFrame, set fCount (count of cFrames) to 1
When I get to fCount = 3 I execute my noteout, check for termination conditions and reset if not done playing

There is a lot to develop here but I think this is a base concept to work from.

Thanks again,

joeb

[axel_liine]

Counting frames would be the way to handle it indeed. Achevieving timing precision better than the "frame" unit (which is 60fps, so 16ms) is something we want to enable at some point, but there's no ETA on this.

[joebataz]

I am so close now it is actually painful!
Attached is a template which has the very basic elements I need to FINALLY get this working. As a matter of fact it's probably 60% there but as usual just when you think it's safe to dive back in you're missing a large chunk of butt. Here's the problem now:
This is an OnFrame script (PlaySet):

if(playing == 1 && curNote < sizeof(NoteSet))
{
if(frameCounter())
{
noteout(0,A_Notes[curNote],127,15);
noteout(0,B_Notes[curNote],127,16);
curNote++;
frameCount = 0;
if(NoteSet[curNote-1] != NoteSet[curNote])playing = 0;
}
}
else if(curNote == sizeof(NoteSet)) playing = 0;

This is another OnFrame script (frameCounter):

if(playing == 1)
{
if(frameCount == delayFrames)
{
return 1;
}
else
{
frameCount++;
return 0;
}
}

delayFrames is the variable to tweak timing

The issue is the 2 noteout lines next to each other. Sometimes they step on each other. I tried doing this inside the if(frameCounter() statement:
if(curChannel == 'B')
{
noteout(0,A_Notes[curNote],127,15);
curChannel = 'P'
frameCount = 0;
}
else
{
noteout(0,B_Notes[curNote],127,16);
curNote++;
frameCount = 0;
if(NoteSet[curNote-1] != NoteSet[curNote])playing = 0;
curChannel = 'B';
}

But all I get is the A_Notes midi getting sent out in a loop and I never seem to hit the else part which makes zero sense to me. I took the advice of ignoring ANY time references and just going by Lemur frame which seems to have gotten me a lot closer.

TIA for any help/ideas. joeb

[bxsj]

Sometimes they step on each other.

Are the notes send out or not? Have you tried a midi monitor to see what gets send out?

Btw, is it really necessary to have multiple "on frame" scripts? When defining two of them (were one even calls the other) they both are called in the "same" Lemur frame. Which can lead to situations were the frame counter is incremented twice in one frame.

B.
One should try avoiding complexity in an already highly complex environment

[joebataz]

OMG!! Could it be??????
Yes, after considerable head banging (as you've all witnessed) and a few temper tantrums. The wise teachings of macciza and axel_line finally got through my thick skull and I have it working, the midi sends at least. I'm now at 95% accuracy (which I can live with) and got the added benefit of being able to control speed for free. Although its a teeny bit slower than I'd like (but I'm a perfectionist) a delay of 6 frames makes everything happy. I totally threw out all the time code and just went with frames. I was pretty DUHHH for awhile but it finally sunk in. I still want to finish the fader based timeline display/controller and want to add back in the sequencer saver (only 12 this time) but I should be able to get a full working version out in time for the May theatre season.

Many thanks to all the forum members who contributed. If you were in AZ we could go shoot scorpions and drink Coronas in the back yard.

Thanks and I'll be less present while I finish up the code!

joeb

[bxsj]

Good luck and watch out for the rattle snakes

[joebataz]

bxsj,

Just saw your post as I was writing the last one. Yes, the notes were getting sent, just too fast for the hardware to process them. I only have 2 OnFrame loops and the entire app is at about 4%. Nothing else is really time based so I think I'll be OK. The proof will come when I go out to scope a couple of gigs. I'll be running a couple of Audio apps as well as the DMX application but that'll pretty much be it.

thanks for the comments and help

[kraftf]

I haven't followed exactly the whole thread.
At some point I read that you need a delay inside the execution of your code.
Have a look at my implementation in Ambivalent beats of presets. The problem I had that was the execution of the script loading/storing the values which had to scroll a 16 pad object was too fast and it did not produce the right results. So I had to delay it. I've put a hidden button which performs the script action with a delay that has been set explicitly.
Here is the thread:
http://liine.net/forum/viewtopic.php?f= ... t&start=10
and the attachment is the Ambivalent Beats-Mod.zip.
I hope it can help you