This HAS to be a bug...

Discuss problems and solutions.
Post Reply
ForestCat
Regular
Posts:59
Joined:02 Mar 2012 21:00
This HAS to be a bug...

Post by ForestCat » 16 Mar 2016 04:03

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.
Attachments
nn_PadPressBug.jzml
(18.83KiB)Downloaded 106 times

oldgearguy
Regular
Posts:315
Joined:02 Nov 2013 11:19

Re: This HAS to be a bug...

Post by oldgearguy » 17 Mar 2016 22:53

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.
Attachments
nn_PadPress_fixed.jzml
(16.12KiB)Downloaded 126 times

ForestCat
Regular
Posts:59
Joined:02 Mar 2012 21:00

Re: This HAS to be a bug...

Post by ForestCat » 18 Mar 2016 14:28

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...

oldgearguy
Regular
Posts:315
Joined:02 Nov 2013 11:19

Re: This HAS to be a bug...

Post by oldgearguy » 18 Mar 2016 17:29

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.

Post Reply