General
Potential Bug regarding MIDI Clock Executed Scripts
Started by Traxus on .
Sign in or create an account to join the conversation.
I have a script in my Traktor template that listens for midi clock, and refuses to let the user proceed past setup without proper midi clock...
This by far is the most common hang up people have (although trouble shooting this is easier than explaning why other parts of the template that rely on clock are not working)
Many times the users fail to wire everything together correctly.
However I had noticed that sometimes I was not detecting clock in the template, even though i was receiving it (checked in different templates).
I had some free time today and decided to re investigate.
The jist of the logic was:
Script A: Listen for clock
I am now monitoring the step variable on a step switch object slaved to clock 0, instead of an actual Clock script; but this is beside the point.
You may or may not be aware that scripts retain the attributes of their execution type even if you change them. So, if I initially made Script A to execute on the change of variable "xyz" from 0 to 1, and then later decided to change it to fire on MIDI clock, it will retain the attributes of executing on variable "xyz" from 0 to 1... Even if I come back 6 months later (the actual XML attributes are stored in the file).
This is of course, exactly what I did. I cannot help but wonder whether some of these retained attributes were causing occasional conflict with the execution of the on midi clock script.
This by far is the most common hang up people have (although trouble shooting this is easier than explaning why other parts of the template that rely on clock are not working)
Many times the users fail to wire everything together correctly.
However I had noticed that sometimes I was not detecting clock in the template, even though i was receiving it (checked in different templates).
I had some free time today and decided to re investigate.
The jist of the logic was:
Script A: Listen for clock
On Midi Clock 0, for every 1/64th beat:
Set the variable "step_time" to the current timeOn Frame Execution
If variable "step_time" plus 2 seconds is greater than current time:
Clock is working
Else
Clock is not workingI am now monitoring the step variable on a step switch object slaved to clock 0, instead of an actual Clock script; but this is beside the point.
You may or may not be aware that scripts retain the attributes of their execution type even if you change them. So, if I initially made Script A to execute on the change of variable "xyz" from 0 to 1, and then later decided to change it to fire on MIDI clock, it will retain the attributes of executing on variable "xyz" from 0 to 1... Even if I come back 6 months later (the actual XML attributes are stored in the file).
This is of course, exactly what I did. I cannot help but wonder whether some of these retained attributes were causing occasional conflict with the execution of the on midi clock script.
Hi!
One of the ways to control these inconsistencies is to run an init script that forces variables to default values, stops the clock and starts it, but not an 'onload'. I've found an onload doesn't always work as expected and re-runs every time the template is saved in the editor which can be very annoying during development.
What I do is run one 'on frame' script that checks to see if the template has been init'd, and if not does so in stages until everything completes, because it is not certain that one frame is enough to get everything done with various speeds of devices out there and things can hang which means functions don't work consistently.
That one script kicks off everything else and manages occasional tasks that do not need to be run every frame.
1/64th can be faster than a frame, so try to stick with simple tasks in whatever you do with that time, and avoid declaring any variables.
Sometimes the on-clock simply hangs and things don't run, and I have no idea why. I put a reset template button in a debug window to re-init, but that doesn't always work.
Happy debugging!
cheers
J
One of the ways to control these inconsistencies is to run an init script that forces variables to default values, stops the clock and starts it, but not an 'onload'. I've found an onload doesn't always work as expected and re-runs every time the template is saved in the editor which can be very annoying during development.
What I do is run one 'on frame' script that checks to see if the template has been init'd, and if not does so in stages until everything completes, because it is not certain that one frame is enough to get everything done with various speeds of devices out there and things can hang which means functions don't work consistently.
That one script kicks off everything else and manages occasional tasks that do not need to be run every frame.
1/64th can be faster than a frame, so try to stick with simple tasks in whatever you do with that time, and avoid declaring any variables.
Sometimes the on-clock simply hangs and things don't run, and I have no idea why. I put a reset template button in a debug window to re-init, but that doesn't always work.
Happy debugging!
cheers
J
what is your syntax for stopping and restarting midi clock in lemur?
...this must be a clock crash as I can't seem to reproduce the issue with any consistency.
...this must be a clock crash as I can't seem to reproduce the issue with any consistency.
Just the usual for(x=0;x<MAXCLOCKS;x++) { clock_stop(x); }
Followed by a single clock_start(0);
Followed by a single clock_start(0);
Oh, must have missed clock_start and clock_stop in the v 5 documentation