'Trace'-mode to debug
Posted: Tue Feb 19, 2019 7:24 pm
I'd really would like a debug or trace mode brought in place.
A kind of syslog if you wish..
Every step in a running QLC+ is documented as a text dump?
And most important: who is the caller - callee combination. Which cue / collection / chaser / efx / ... is incontrol of what sent values to where.
something like:
context:
Today I helped a fellow forum user and he had troubles figuring out why this and that...
To help him debugging - it was a kinda big project, with lots and lots of cue's, chasers, sequencers, collections and a show file or 10...
Wisedom helped me more than logic in this 'mess' - you have to explicit reset DMX values if you are expecting that this cue will work in coherence with all the rest going on?
A debug or trace would have showed that 'filtering on 'U2:ch096-000' would have showed that 'Qstep 2' or 'Chaystack' is calling this value.
As far as I can read C## it will be very complex, so ...
I'm one of the, that would spend some $$$ for this feature ... (even a documented dump on the input of an interface 8-/ scary -hihi-)
A kind of syslog if you wish..
Every step in a running QLC+ is documented as a text dump?
And most important: who is the caller - callee combination. Which cue / collection / chaser / efx / ... is incontrol of what sent values to where.
something like:
Code: Select all
17:59:00:120 'button 12' 'Enable' 'Chaystack' '' ''
17:59:00:120 'Chaystack' 'firststep' 'Qstep 1' '' ''
17:59:00:140 'QStep1' 'target' 'Dimmer #1' '' 'U2-ch096-255' ''
17:59:00:140 'Chaystack' 'busy:Fi - 1000ms' 'Qstep 1' '' ''
17:59:00:160 .. [optional] 'Chaystack' 'send:Fi - 20ms' 'Qstep 1' '' 'U2-ch096-004' 'iface:192.168.0.30:6454' -> 20ms times #channels would be absolutely crazy to log IMHO - here you see the fade in (1000ms at end) of Step 1
...
18:00:00:140 .. [optional] 'Chaystack' 'send:Fi - 1000ms' 'Qstep 1' '' 'U2-ch096-255' 'iface:192.168.0.30:6454'
...
18:04:15:840 'signal:U3-midi-08-127' 'nextstep:Chaystack' '' '' ''
18:04:15:840 'Chaystack' 'nextstep' 'Qstep 2' '' ''
18:04:15:840 'Qstep 2' 'target' 'Dimmer #1' 'U2-ch096-000' ''
18:04:15:840 'Qstep 2' 'target' 'Dimmer #2' 'U2-ch097-255' ''
18:04:15:840 'Qstep 2' 'target' 'Wash #1' 'U1-ch020-255' ''
18:04:15:840 'Chaystack' 'busy:Fi 0ms' 'Qstep 2' '' ''
18:04:15:860 'Chaystack' 'send' 'Qstep 2' 'U2-ch096-000' 'iface:192.168.0.30:6454'
18:04:15:860 'Chaystack' 'send' 'Qstep 2' 'U2-ch097-255' 'iface:192.168.0.30:6454'
18:04:15:860 'Chaystack' 'send' 'Qstep 2' 'U1-ch020-255' 'uDMX'
Today I helped a fellow forum user and he had troubles figuring out why this and that...
To help him debugging - it was a kinda big project, with lots and lots of cue's, chasers, sequencers, collections and a show file or 10...
Wisedom helped me more than logic in this 'mess' - you have to explicit reset DMX values if you are expecting that this cue will work in coherence with all the rest going on?
A debug or trace would have showed that 'filtering on 'U2:ch096-000' would have showed that 'Qstep 2' or 'Chaystack' is calling this value.
As far as I can read C## it will be very complex, so ...
I'm one of the, that would spend some $$$ for this feature ... (even a documented dump on the input of an interface 8-/ scary -hihi-)
