Not enough room for a descriptive subject line, sorry.
Trying to programmatically (script) "press & release" a pad that has scripts attached to it's rising and falling x values. Not working. I've isolated the behavior in the very simple attached template. I'd be grateful if someone smarter than me would have a quick look.
Description: You have a 1x3 Pad object that has scripts on the rising and falling x values which trip the WasPressed & WasReleased monitors.
The RESET button resets the monitors.
The Press button "presses" Pad1 by changing its x to '1'
The Release button 'releases" Pad1 by changing its x to '0'
The Both button simply combines the two commands above into one script.
IT DOESN'T WORK. If you comment out either of the lines it will either 'press' or 'release' Pad1 (if you already set WasPressed w/ the Press button, etc) BUT NOT BOTH.
I thought it was a timing issue, I put a "count to 1000' loop between the x=1 x=0 commands, no good. Set x=1 a thousand times before setting it back to zero, no good. What works is the Hack, which sets Pads.x[1] =0, then 'presses' the Release button by setting its x to 1.
Why doesn't the 'Both" script work?
Thanks greatly for any help.
This HAS to be a bug...
This HAS to be a bug...
- Attachments
-
- nn_PadPressBug.jzml
- (18.83 KiB) Downloaded 95 times
-
- Regular
- Posts: 315
- Joined: 02 Nov 2013 11:19
Re: This HAS to be a bug...
Since you are setting x to both 1 and 0 in the same frame, only the last value will apply.
I attached a modified version that does (I think) what you want.
The way Lemur processes scripts is slightly non-obvious. You think it's linear, but it's not really. Nick promised me a year or so ago he'd write up a "how Lemur internals work" document, but that hasn't materialized yet.
I attached a modified version that does (I think) what you want.
The way Lemur processes scripts is slightly non-obvious. You think it's linear, but it's not really. Nick promised me a year or so ago he'd write up a "how Lemur internals work" document, but that hasn't materialized yet.
- Attachments
-
- nn_PadPress_fixed.jzml
- (16.12 KiB) Downloaded 116 times
Re: This HAS to be a bug...
Thank you! I'll have a look.
Question re: "same frame"
Script()
doSomething;
for(i==0;i<10000;i++)
{
}
doSomethingElse
Are something and somethingElse still executed in the same 'frame'????
BTW, there is NOTHING I can do to have this forum s/w notify me of replies to my threads. I'm on dozens of phpBB forums, I know the settings...
Question re: "same frame"
Script()
doSomething;
for(i==0;i<10000;i++)
{
}
doSomethingElse
Are something and somethingElse still executed in the same 'frame'????
BTW, there is NOTHING I can do to have this forum s/w notify me of replies to my threads. I'm on dozens of phpBB forums, I know the settings...
-
- Regular
- Posts: 315
- Joined: 02 Nov 2013 11:19
Re: This HAS to be a bug...
short answer is yes. Additionally, in Lemur, a FOR loop is not a good wait to introduce a delay to let one thing finish before another starts.
What happens in your script is that Pad[0].x is set to 1 and then immediately set to 0 and after the script finishes, the UI is updated so it always looks 'off'.
There's other issues accessing global variables versus local variables in a script and when they are instantiated (especially important when using an INIT script) and probably 100 other conditions that I'm forgetting now. I know I ended up working around them (or implementing techniques to solve the problem) in my editors, but it's been a long time since I had any desire to even open the code up again.
When I was coding the TX-802 editor, I needed to wait a bit of time so that I did not overrun the TX-802 internal sysex buffer with data. I came up with a way to do that, but part of the solution involved using one of the internal clocks and triggering events based on that.
The other thing to keep in mind is that if you directly set the value of x on an object, then any scripts attached to that object that trigger on x might get started. Of course, that may be the desired effect, but it's something to consider.
What happens in your script is that Pad[0].x is set to 1 and then immediately set to 0 and after the script finishes, the UI is updated so it always looks 'off'.
There's other issues accessing global variables versus local variables in a script and when they are instantiated (especially important when using an INIT script) and probably 100 other conditions that I'm forgetting now. I know I ended up working around them (or implementing techniques to solve the problem) in my editors, but it's been a long time since I had any desire to even open the code up again.
When I was coding the TX-802 editor, I needed to wait a bit of time so that I did not overrun the TX-802 internal sysex buffer with data. I came up with a way to do that, but part of the solution involved using one of the internal clocks and triggering events based on that.
The other thing to keep in mind is that if you directly set the value of x on an object, then any scripts attached to that object that trigger on x might get started. Of course, that may be the desired effect, but it's something to consider.