[QLab] Debounce

[Rich Walsh]

I like to have my MIDI GO box trigger the Main Cue List, regardless of which cue list I happen to be viewing at the time. Hence, I use a trigger on the Main Cue List itself, and not the GO control in the Remote Control preferences. The fact that it is then unprotected by the global Double GO Protection is not normally an issue as I am usually using a CueOne CMX8, which is self-debouncing. However, I'm using something else this time - so what is the most elegant way of creating a debounce? (This is coincidental to the recent thread...)

The best I've come up with is a separate cuelist ("Debounce"), which is triggered by the MIDI message and looks like this:

[Andy Leviss]

On Thu, Oct 21, 2010 at 8:36 PM, Rich Walsh <rich...@mac.com> wrote:
> what is the most elegant way of creating a debounce? (This is coincidental to the recent thread...)
>
> The best I've come up with is a separate cuelist ("Debounce"), which is triggered by the MIDI message and looks like this:

--snip--
> Is this true? Is there an easier way?

What I've done in the past is this:

1 <Start Cue> "Main Cue List Go" Target= Main Cue List; Trigger=MIDI
message from your "Go" button [LINK]
2 <Disarm Cue> "Disarm Trigger" Target=Cue 1 [LINK]
3 <Arm Cue> "Debounce then Rearm" Target=Cue 1; Pre-wait=desired debounce time

The only potential problem I now see is that in your example of four
bounces, this could multiply the debounce time by 4. (The times I had
to use this, I was worried more about double Go than about debounce.)
Is there a way to pop a script cue in there between 2 and 3 to not
re-trigger the Arm cue if it's already currently running? An "If Arm
Cue != already running, start Arm Cue" sort of thing? AppleScript is
next on my list to crack, but I'm already floating between Mac OS X
Support Essentials to work on becoming an ACSP and learning Objective
C/Cocoa, on top of reading a novel, LOL, so I haven't made it there
yet!

--Andy
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

[Rich Walsh]

On 22 Oct 2010, at 05:38, Andy Leviss wrote:

> What I've done in the past is this:
>
> 1 <Start Cue> "Main Cue List Go" Target= Main Cue List; Trigger=MIDI
> message from your "Go" button [LINK]
> 2 <Disarm Cue> "Disarm Trigger" Target=Cue 1 [LINK]
> 3 <Arm Cue> "Debounce then Rearm" Target=Cue 1; Pre-wait=desired debounce time
>
> The only potential problem I now see is that in your example of four
> bounces, this could multiply the debounce time by 4. (The times I had
> to use this, I was worried more about double Go than about debounce.)
> Is there a way to pop a script cue in there between 2 and 3 to not
> re-trigger the Arm cue if it's already currently running? An "If Arm
> Cue != already running, start Arm Cue" sort of thing?

You can't re-trigger a cue if it's running, so I don't see the problem. If you set your debounce time to something absurd (like 10s) you can see that your version is apparently immune to any number of GOs during the debounce period.

Rich

[Rich Walsh]

On 25 Oct 2010, at 02:31, I wrote:

> You can't re-trigger a cue if it's running

I realised that this means that the most elegant solution is probably this, in a separate cuelist:

A single Start Cue, targeting Main Cue List, triggered via MIDI; the Post Wait sets the debounce

Andy's Arming & Disarming appears to be unnecessary, and anything that relies on triggering a cuelist breaks every time you press Esc!

Provisional testing seems OK. What have I missed?

Thanks.