| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The new module "engine" contains everything to do with working out the
final attribute values. This module should be referenced for anything
that needs to register states, get values etc.
Now, "scanout" is only about converting attribute values to DMX values
and sending them to OLA. This module only needs to be referenced by
fixture definitions, and once by the top level program.
|
|
There's a serious problem with the design so far, where symbols are used
for attribute names (intensity, strobe, colour etc), and also for
attribute values (on, off, random etc). There's no way for 'at' to
tell the difference between the two. For example, this form is
ambiguous: (at myfixture 'strobe 'on)
This commit introduces a new class, <starlet-attribute>, to replace the
use of symbols here. The attributes are enumerated in (starlet attributes),
and new ones can be added later. The attribute objects remember their
'canonical' names, to allow states to be printed.
Apart from solving the ambiguity problem, this has two further
advantages. First, attribute names no longer need to be quoted
everywhere. Second, multiple names can be used to refer to the same
attribute. For example: (define color colour).
|
|
Previously, the LED would not be lit until the first playback event
(go/back etc) after startup.
|
|
|
|
This replaces the mess of "list" forms:
(set-midi-control-map! controller
(list
(list 'intensity 'fader 16 '(108 72))
...))
With something a bit clearer:
(set-midi-control-map! controller
(fader 16 'intensity #:congruent 108 #:incongruent 72)
...)
There's a corresponding improvement in the internal code.
|
|
It's not used anywhere, and it doesn't work - there are many other kinds
of update apart from setting an individual value.
|
|
This prevents the other colour channels from getting messed up, when an
individual channel is changed via the controller.
|
|
|
|
|
|
|
|
Use make-sensitivity-knob
|
|
This makes the MIDI controller stay in sync with the programmer state
values. It's kind of a coarse solution, though. It would be better to:
1. Only re-assert the map if the changed parameter currently appears on
the MIDI control surface
2. Only re-assert the part of the map related to the parameter
Almost as a side-effect, this enables switching between multiple control
maps. Just call 'set-midi-control-map!' on the controller with the new
map.
|
|
This includes a "source", intended to be used for avoiding hook users
from responding to their own changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Because we can stop a clock object, but not "gettimeofday".
|
|
This fixes a problem whereby lights couldn't be turned off via the fader
|
|
|
|
|
|
My control surface (A&H Xone:K2) seems to respond badly to being blasted
with note on/off events to turn its LEDs on and off: some of the LEDs
end up in the wrong state. The effect is reproducible using a small
test program using the ALSA API from C, which excludes multi-threading
problems in Starlet and buffer overruns in the ALSA device. The
controller simply doesn't cope well with large numbers of events
arriving in quick succession.
Adding a very small delay seems to completely fix the problem without
causing any noticable flicker.
|
|
|
|
|
|
|
|
|
|
This allows easy re-assignment of faders with state-on-fader
|
|
|
|
|
|
|
|
This is LOADS faster.
|
|
This avoids a deadlock if the midi readout isn't happening for some
reason.
|
|
The "home state" has no reason to exist. The home values are already
stored perfectly well in the attribute lists of the fixtures. Any time
we need to look up a home value, we already have the fixture itself
available.
This also gets rid of any use of <fixture-attribute> in states. This
was confusing me. Better to just pass symbols around and only get the
real attribute objects when needed (which isn't very often).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
More specific name.
|
|
This is a bit nasty, because we might not know what value the fader was
at before it was moved.
|
|
|
|
|
|
There's no reason for this to exist. Just change things directly in
programmer-state.
|
|
|
