Commit 2a372bd6 authored by Guerric Chupin's avatar Guerric Chupin

Reorganized file system.

parent dfb4946f
Reactogon Design
================
2016-05-18: INCOMPLETE, but should give an idea. Refine/structure better
as see fit.
Target levels
-------------
1. Baseline: text interface only, not necessarily (very) interactive,
but at the very least able to record a performance as a MIDI file.
2. Basic system with a GUI running on a Linux desktop. At least able
to generate sound
3. Full-featured system with GUI running on a Linux desktop.
4. Mobile version, subject to cooperation with Ivan/Keera Studios
Feature Summary
---------------
* Modelled after the origial Reactogon
* Up to 16 layers. Each layer an extended version of the original Reactogon.
Extensions include:
- Each tile has an associated "repeat count" n. The play head stays
on the title for n clock ticks, repeating any basic action for
each tick, before moving on (possibly in new direction).
Specifically, this means that n = 1 is the normal behaviour and
n = 0 means the play head moves on immediately without performing any
action.
- User-defined "groove" per layer. E.g. every other beat can be delayed for
a swing feel.
- Accented (more strongly played) notes.
- Slide (kind of slide *could* even depend on direction of the play head!)
(not going to work well for polymorphic layers probably. But the MIDI
translator could simply ignore slide messages until the current one is
done. Then everything OK as long as no overlapping slides.)
- MIDI CC/program change can be sent for a note
- Two tempo-synched LFOs per layer
- Bank and Program
- Volume slider
- Pan pot
- Layer transposition
- A layer can be set to be unpitched: the pitch of all output notes
are set to a specific pitch (useful for e.g. rythm layers).
- Muting and Soloing of layers
* MIDI integration
- synchronization to external MIDI clock if selected and available
- start, stop, continue: send and receive
- each layer transposed in response to note on message on designated channel
- designated MIDI channel for each layer for output:
+ note on/off
+ program change
+ volume
+ pan
+ mapping of LFOs to specific MIDI CC (including volume or pan which
overrides the static values).
+ pitch bend
* Dynamic addition/deletion of layers(?) Or simply a fixed number of layers?
* Overall control/performance tab. For ecach layer:
- Volume
- Pan
- Mute (inhibits all MIDI out messages, but layer continues to run)
- Solo (messages from all other layers inhibited, but mute status
preserved; only one layer at a time can be soloed)
These controls duplicated on each layer
* Saving & loading of configurations
* Loading of individual layers from stored configurations.
* Directly recolrding to/generating a MIDI file. Record button?
Clocking
--------
The system beat, relative to which the overall tempo is given (in BPM)
is defined to be one quarter note.
The layer beats is specified separately but defaults to one quarter note.
A beats per par is also specified per layer. Together with the layer beat
this gives the time signature (of sorts) for a layer.
The system tempo is either set internally, in BPM, or synched to an external
MIDI clock.
Sufficiently flexible swing could be specified per layer by specifying
how much earlier or later beats 2, 3 and 4 should be relative to a straight
beat, i.e. three numbers between say -90% and 90%. A standard swing
beat would thus be given by 50, 0 50.
Only beat numbers as defined by the layer's beats per bar would be used,
and beat numbers beyond 4 would be played straight.
Or one might want to allow the number of numbers to be beats per bar minus 1.
Overall Structure
-----------------
------------------
| |
Model <----> GUI <----- |
| | |
|--> Global-+----->| |
| V | V
+------> Layers -----> MIDI translator ---> MIDI Synth
|
MIDI keyboard --
|
(MIDI clock) ---
Gloal, Layers, and MIDI translator are all FRP (Yampa) moduled.
* Global (better name needed!) takes care of system-wide signal
processing, e.g. definition of the system clock, run/stop logic?
* Each Layer is a Reactogon. The core semantics is defined in
BasicSemantics. The intention is to lift (most of) this into
an event-processing signal fnction using "accumBy". Additional
signal functions per layer would be needed to define the
layer clock, layer LFOs, and maybe more.
* The MIDI translator is responsible for translating the collective
output from the layers (high-level MIDI notes, LFO output) into
low level MIDI events. This involves things like ensuring that a
note off event is scheduled for every note on event at the appropriate
time, translating and realising continuous control signals
(from LFOs, slide ornaments) into discrete MIDI messages,
and merging it all into a single sequence of events, taking the
limited capacity of a standard MIDI connection into account
(more corse grained translation of continous control signals
if too busy? dropping notes in case of excessive polyphony per
channel and/or overall?)
* The GUI manipulates a model of the system tailored to the needs of the
GUI. Control signals are derived from this for Global and each
layer (e.g. the configuration of a board, the board transposition).
The GUI also needs to observe the output from Global and Layers
to animate layers as the play heads move around and to display
the system tempo in case this is derived from external MIDI clock.
The GUI also needs to talk to the MIDI translator to send e.g.
configured prgram change, bank, volume and pan messages for each
layer whenever the Reactogon is started.
Muting of layers could also be achived this way by instructing
the translator to temporarily stop listening to a muted layer.
(Muted layers would still run and be animated.)
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment