Midiout delay?

[kraftf]

The idea is the same, if you have a tempo of 100 bpm this means that a beat is played every 0.6 sec (60/100) and as a 1/16 is a quarter of a beat your delay is then 0.15 sec.

The other option is to sync to an external midi clock, in this case you need to watch incoming midi clock values. I made a small template that shows how it works somewhere in this forum. As there are 24 midi ticks per beat, trigger a note every 6 ticks for 1/16 th. Note that this method is not very good due to midi jitter, normally a sequencer will use it's internal clock and adjust smoothly to the incomming midi clocks.

To trigger notes only when you press a button, in the on frame script check the state of your button, if it's value is one then send the note(s), otherwise just leave the procedure. But don't forget to send note off or you may have hanging notes.

Thabks again for your help.
I have to get myself a little more clear.
I have aready dane what you suggest regarding the on/switch.
I have ascript running on Frame which sends a midi noteon and off and I have set a delay time set to 60/BPM
value for generating delayed 1/4 notes as long as the pad is held. It is working but the timing of the second is not correct because it is generated according to the fixed xlock of Lemur. How can I extrapolate the internal timing to start from the time I press the button. Tried using new time variables with no success. There should be a similar way to do this like when constructing a sequencer start stop but I can't connect them.
I also don't want to sync to a midi clock.

[mbncp]

Not sure I get this right, but when you hit the button you should set some variable to the current time as you probably want the first note right away.

triggertime = time;

Given that the function is called every 1/60 sec, to compensate, you could write:

triggertime = time-1/120;


Then, in the on frame scrip:

if(mybutton.x == 0) return;
if(triggertime > time) return;

// send your note

triggertime+=60/BPM;

[kraftf]

Not sure I get this right, but when you hit the button you should set some variable to the current time as you probably want the first note right away.

triggertime = time;

Given that the function is called every 1/60 sec, to compensate, you could write:

triggertime = time-1/120;


Then, in the on frame scrip:

if(mybutton.x == 0) return;
if(triggertime > time) return;

// send your note

triggertime+=60/BPM;

No its not working like the way you suggest. However I am not sure where you put the triggertime variable inside or outside the script.
Also I think that time is returning ms and not second as you suggest. Still trying but no success.
My problem is how to define the limited conditions. Its nit vflear for me yet.

[mbncp]

NoteOnTime.jzml.zip

(886Bytes)Downloaded 202 times

It's working here, the triggertime variable has to be outside the script as I assume local variables get cleared. Also yo wouldn't be able to access a variable declared in another script.
And the time is indeed in seconds.

[kraftf]

Well yes its working!!
I didn't put the "triggertime = time-1/120;" in another script!It was not clear from your message.
I tried all combinations except that.
Thanks a lot. Your help is valuable!

[Macciza]

Hi
I have not had much time to look into this but have given it some thought and a possible solution . .
I don't think 'On Frame' is the best way to go -due to jitter and granularity, frame rate can possibly vary depending on graphic complexity and 16.66r msec frame rate . . .

The time() function actually returns time to microsecond resolution (with precision set to 6) not that we need delays that fine-grained . .
time%1 will give a 0 -.999999 second ramp from which you can capture the press time=now which becomes the 'offset' within any given second . . .
1/4 note delay @60bpm = .25 sec, therefore the note and delayed notes equals 'now' (offset), (offset+.25)%1, (offset+.5)%1, (offset+.75)%1,
Of course the BPMs etc would do with numeric representations linked to time definitions for programmatic ease of use by calculating mSec delay value

Hope that explains it well enough, have not had time to code up solid examples but the principle is sound imho

Cheers
MM

[kraftf]

Hi
I have not had much time to look into this but have given it some thought and a possible solution . .
I don't think 'On Frame' is the best way to go -due to jitter and granularity, frame rate can possibly vary depending on graphic complexity and 16.66r msec frame rate . . .

The time() function actually returns time to microsecond resolution (with precision set to 6) not that we need delays that fine-grained . .
time%1 will give a 0 -.999999 second ramp from which you can capture the press time=now which becomes the 'offset' within any given second . . .
1/4 note delay @60bpm = .25 sec, therefore the note and delayed notes equals 'now' (offset), (offset+.25)%1, (offset+.5)%1, (offset+.75)%1,
Of course the BPMs etc would do with numeric representations linked to time definitions for programmatic ease of use by calculating mSec delay value

Hope that explains it well enough, have not had time to code up solid examples but the principle is sound imho

Cheers
MM

Sounds good and indeed there is jitter with the onframe approach.
Anyway I have completely no idea on how to use in a script the time values produced in by the time%1 expression.
I can understand the approach with the offset but have no idea how to speak to Lemur!
Help needed.

[mbncp]

@Macciza

??? I don't see a time() function, there is a time in-built variable, which I use in the example above.

triggertime = time-1/120;
...
if(triggertime > time) return;
...
triggertime+=60/BPM;

The OnFrame is not used to calculate the timing, it's just there to trigger the event as I don't see a better way to do it as there is no way to send a midi event at a specific time.

Off course there will be some jitter due to the OnFrame lack of precision (not even speaking about midi over wifi), but globally things should stay in (internal) sync over time.

[kraftf]

@Macciza

??? I don't see a time() function, there is a time in-built variable, which I use in the example above.

triggertime = time-1/120;
...
if(triggertime > time) return;
...
triggertime+=60/BPM;

The OnFrame is not used to calculate the timing, it's just there to trigger the event as I don't see a better way to do it as there is no way to send a midi event at a specific time.

Off course there will be some jitter due to the OnFrame lack of precision (not even speaking about midi over wifi), but globally things should stay in (internal) sync over time.

I tried the time%1 option and put it in the trigger of a custom midi message in the form of x*time%1. It produces the time varying triggers of the midi message but again it's fixed on the Lemur internal timing. I can't think of a way to set repeating triggers of a midi message relative to the time variable.
I have to study the sequencer start/stop that are available. Maybe the answer is there.

[analog604]

Thanks for this, I've been working on output timing as well.

AFAIK there is no sleep function in Lemur.
The only option I see as I stated before is to use an OnFrame script. You can use it together with the time function.
So instead of having your for loop, create a variable and set it to 16 when you need to send your sysex.
Decrease this value by one each time until it reaches 0.

Actually instaed of using the on expression trigger it's better to do everything in the on frame script taking care yourself of what has changed.