I have been testing the software for a couple of days now and I really like it, but I'm having trouble getting a scripted chase to work properly. i have followed the sample on the help pages and I can create the chase and it does loop, but I can't get it to stop after a set number of loops.
I've tried using the fx:ifset command and the loop works, but it's perpetual.
Any advice on this would be great. That's the only drawback to integrating this software into our theater right now.
Problem with chase sequence
That appears to be a bug that must have been introduced somewhere in the process of adding the live cue mode to v1.3.
This is now fixed in the latest build 1.3.35.
Thanks for pointing it out.
1.3.x versions contain such a number of changes that the final release will be LXConsole 2.0. The current version is a release candidate. Hopefully, other minor things or problems with this release can be found so that 2.0 can be available in the next month or so
This is now fixed in the latest build 1.3.35.
Thanks for pointing it out.
1.3.x versions contain such a number of changes that the final release will be LXConsole 2.0. The current version is a release candidate. Hopefully, other minor things or problems with this release can be found so that 2.0 can be available in the next month or so
Still no luck
I just downloaded 1.3.35 and tried this again with the same results. The loop never ends. Any other ideas on this?
The cue with the link that conditionally terminates the loop must have the script command: "fx:linkwhile" This script command decrements the counter and is also used to test the counter to see if the link should be followed. So that is the first thing to check.
Does the same thing happen if the counter is set using "fx:set n" and not "fx:ifset n"?
There might be an issue with the execution sequence of multiple threads. Those things are notoriously hard to track down. If this is the case, the 1.3.35 fix may have cured the problem on the test machines used to confirm the fix. But that type of problem can appear random, affecting some circumstances but not all. Also, if you have more than one version of LXConsole on your machine, double-clicking may not necessarily open the last version. If you do have more than one version, it is worth checking which one is actually running.
Does the same thing happen if the counter is set using "fx:set n" and not "fx:ifset n"?
There might be an issue with the execution sequence of multiple threads. Those things are notoriously hard to track down. If this is the case, the 1.3.35 fix may have cured the problem on the test machines used to confirm the fix. But that type of problem can appear random, affecting some circumstances but not all. Also, if you have more than one version of LXConsole on your machine, double-clicking may not necessarily open the last version. If you do have more than one version, it is worth checking which one is actually running.
Still problem
Thanks for the feedback and for being so quick with your responses.
I have definitely set the linked cue to use the "fx:linkwhile" script. I have tried it with both the code string in the script field and also using an external applescript with only that code string.
I have also tested using both the "fx:ifset n" and "fx:set n" commands...again both directly and as an external script.
I have also tried setting a the loop count in an earlier cue to see if the final loop was just resetting the count perpetually, but that also didn't change the result. The loop definitely runs, but it never stops.
I did confirm that this last test was running 1.3.35.
I am running on an Intel MacBook (aluminum) with 4 GB RAM and OS 10.6.x if that helps.
I have definitely set the linked cue to use the "fx:linkwhile" script. I have tried it with both the code string in the script field and also using an external applescript with only that code string.
I have also tested using both the "fx:ifset n" and "fx:set n" commands...again both directly and as an external script.
I have also tried setting a the loop count in an earlier cue to see if the final loop was just resetting the count perpetually, but that also didn't change the result. The loop definitely runs, but it never stops.
I did confirm that this last test was running 1.3.35.
I am running on an Intel MacBook (aluminum) with 4 GB RAM and OS 10.6.x if that helps.