aboutsummaryrefslogtreecommitdiff
path: root/examples
AgeCommit message (Collapse)Author
2021-09-11Re-assert MIDI control map on parameter changeThomas White
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.
2021-08-08Make each MIDI controller into its own objectThomas White
2021-07-03Add example of loading cue lists from fileThomas White
2021-07-03Rename demo.scm to conjure-demo.scmThomas White
2021-07-03Add option to store cue list in a file, and reload itThomas White
2021-06-03Update demo.scm to show off patch-manyThomas White
2021-05-29Split fixture library down to one file per fixture typeThomas White
Perhaps different personalities could be combined for each fixture, but I don't think I'd go further than that.
2021-05-22Add missing use-modules to demo.scmThomas White
2021-05-22Update demo.scmThomas White
2021-05-22Add make-back-buttonThomas White
2021-05-16Restore effects using clocksThomas White
2021-05-16Get rid of time parameter and use clock objects for cross-fadesThomas White
Because we can stop a clock object, but not "gettimeofday".
2021-05-10Start OLA scanout automaticallyThomas White
2021-05-10Split 'base' module up into 'fixture', 'state' and 'scanout'Thomas White
2021-04-18Update MIDI buttonsThomas White
2021-04-18Update demo fileThomas White
- Add Arduino fixture - Add ltruss group - Add more MIDI buttons
2021-04-07Convert everything else to use <colour>Thomas White
2021-04-06Initial abstraction layer for coloursThomas White
2021-04-03New state-on-faderThomas White
2021-03-31Update demo.scmThomas White
2021-03-13Store the real states in a cue list, not the functionsThomas White
This shouldn't be a big memory burden, even lots of large states. It also makes for a more consistent language by allow lighting-state to be used in cue lists, rather than cue-state.
2021-03-07Update README.md and add demo fileThomas White
2020-12-29Remove old examples/demo.scmThomas White
2020-11-18Improve syntax for cue partsThomas White
2020-10-24Update demo.scmThomas White
2020-10-23fade-up -> up-time, fade-down -> down-timeThomas White
This makes everything consistent: {up,down}-{time,delay}
2020-10-23Plumbing for cue partsThomas White
2020-10-13New way of doing cross-fadesThomas White
2020-09-09Update demo.scmThomas White
2020-09-06Make cue 0 implicitThomas White
2020-09-06Add a blackout stateThomas White
2020-09-06Rearrange for trackingThomas White
2020-09-04Move cue list stuff to playback moduleThomas White
Also, sketch out new way of doing cue lists
2020-08-30cue-state and apply-stateThomas White
2020-08-30(define-state a ...) -> (define a (lighting-state ...))Thomas White
2020-08-22Factor out common code in demoThomas White
2020-08-21Fix explicit fader valuesThomas White
2020-08-21Get rid of 'expand-state'Thomas White
From now on, states will always be real states (not functions evaluating to states). Cues, however, contain functions evaluating to states.
2020-08-21Add 'at' macroThomas White
2020-08-21Add current-state parameter and define-state macroThomas White
2020-08-20Add a moving light to the demoThomas White
2020-08-20More cuesThomas White
2020-08-20More LEDsThomas White
2020-08-19Set all notes (LEDs) off at startThomas White
2020-08-19Add lots more side-effectsThomas White
2020-08-18Add MIDI note callbacksThomas White
2020-08-17Implement 'go'Thomas White
2020-08-16Add blackout to demoThomas White
2020-08-16Split playbacks into separate moduleThomas White
2020-08-16Cross-fade machineryThomas White