reactive-midyim-0.4: Process MIDI events via reactive-banana

Safe HaskellNone
LanguageHaskell98

Reactive.Banana.MIDI.Process

Synopsis

Documentation

class MomentIO moment where Source #

Minimal complete definition

liftMomentIO

Methods

liftMomentIO :: MomentIO a -> moment a Source #

class (MomentIO reactor, Timed reactor) => Reactor reactor where Source #

Minimal complete definition

reserveSchedule

Methods

reserveSchedule :: reactor ([AbsoluteTicks reactor] -> IO (), IO (), Event (AbsoluteTicks reactor)) Source #

Provide a function for registering future beats and return the reactive event list that results from the sent beats.

scheduleQueue :: Reactor reactor => Behavior (AbsoluteTicks reactor) -> Event (Bundle reactor a) -> reactor (Event a) Source #

initialEvent :: Reactor reactor => a -> reactor (Event a) Source #

Generate an event at the first time point.

beat :: Reactor reactor => Behavior (RelativeTicks reactor) -> reactor (Event (AbsoluteTicks reactor)) Source #

Generate a beat according to the tempo control. The input signal specifies the period between two beats. The output events hold the times, where they occur.

beatQuant :: Reactor reactor => RelativeTicks reactor -> Behavior (RelativeTicks reactor) -> reactor (Event (AbsoluteTicks reactor)) Source #

Similar to beat but warrants a maximum reaction time to tempo changes. This way you can alter slow tempos to faster one more quickly.

beatVar :: Reactor reactor => Behavior (AbsoluteTicks reactor) -> Behavior (RelativeTicks reactor) -> reactor (Event (AbsoluteTicks reactor)) Source #

Similar to beat but it reacts immediately to tempo changes. This requires the ability of the backend (e.g. ALSA) to cancel sent (Echo) messages and it requires to know the precise time points of tempo changes, thus we need the Discrete input instead of Behaviour and we need a behaviour for the current time.

delaySchedule :: Reactor reactor => RelativeTicks reactor -> Behavior (AbsoluteTicks reactor) -> Event a -> reactor (Event a) Source #

Demonstration of scheduleQueue. For real use with ALSA you should prefer delay, since this uses precisely timed delivery by ALSA.

pressed :: (MonadMoment m, C set, Ord key) => set key value -> Event (BoundaryExt key value) -> m (Event [Boundary key value], Behavior (set key value)) Source #

register pressed keys

latch :: (MonadMoment m, Ord key) => Event (Boundary key value) -> m (Event (Boundary key value), Behavior (Map key value)) Source #

controllerExponential :: (MonadMoment m, Floating a, C ev) => Channel -> Controller -> a -> (a, a) -> Event ev -> m (Behavior a) Source #

controllerLinear :: (MonadMoment m, Fractional a, C ev) => Channel -> Controller -> a -> (a, a) -> Event ev -> m (Behavior a) Source #

snapSelect :: (MomentIO moment, C set, C pitch, Eq pitch, Eq value) => Behavior (set pitch value) -> Behavior Int -> moment (Event [Boundary pitch value]) Source #

Use a MIDI controller for selecting a note from a key set. Only the pitch class of the keys is respected. The controller behavior must be in the range 0-127. This way, it accesses the whole range of MIDI notes. The output note is stopped and a new note is played whenever turning the knob alters the note pitch. The advantage of the effect is that the pitch range of the knob does not depend on the number of pressed keys. The disadvantage is that there are distinct distances between the pitches.

uniqueChanges :: (MomentIO moment, Eq a) => Behavior a -> moment (Event a) Source #

sweep :: Reactor reactor => RelativeSeconds reactor -> (Double -> Double) -> Behavior Double -> reactor (Event (AbsoluteTicks reactor), Behavior Double) Source #

cyclePrograms :: (MonadMoment m, C msg, C msg) => [Program] -> Event msg -> m (Event (Maybe msg)) Source #

cycleProgramsDefer :: (MonadMoment m, C msg, C msg) => RelativeTicks m -> [Program] -> Behavior (AbsoluteTicks m) -> Event msg -> m (Event (Maybe msg)) Source #

cycleProgramsDefer t

After a note that triggers a program change, we won't change the program in the next t seconds. This is in order to allow chords being played and in order to skip accidentally played notes.

noteSequence :: RelativeTicks m -> Bool -> [Bool -> msg] -> Bundle m msg Source #

guitar :: (MonadMoment m, C msg, C set) => RelativeTicks m -> Behavior (set PitchChannel Velocity) -> Event Bool -> m (Event (Bundle m msg)) Source #

This process simulates playing chords on a guitar. If you press some keys like C, E, G on the keyboard, then this process figures out what tones would be played on a guitar.

Call it like guitar stepTime chords triggers.

stepTime is the delay between to successive notes. A good value is 0.03 (seconds). The chords to be played are passed in by chords. This should be the output of pressed. Further on the function needs events that trigger playing the chord in trigger argument. The trigger consists of the trigger time and the direction to be played (True = down from high to low pitches, False = up from low to high pitches). The trigger may be derived from a specific key that is pressed and released, or two keys, one for each direction.

trainer :: (Reactor reactor, C msg, C msg, Quantity time) => Channel -> T reactor Relative time -> T reactor Relative time -> [([Pitch], [Pitch])] -> Behavior (AbsoluteTicks reactor) -> Event msg -> reactor (Event (Bundle reactor msg)) Source #

Audio perception trainer

Play sets of notes and let the human player answer to them according to a given scheme. Repeat playing the notes sets until the trainee answers correctly. Then continue with other sequences, maybe more complicated ones.

possible tasks:

  • replay a sequence of pitches on the keyboard: single notes for training abolute pitches, intervals all with the same base notes, intervals with different base notes
  • transpose a set of pitches: tranpose to a certain base note, transpose by a certain interval
  • play a set of pitches in a different order: reversed order, in increasing pitch
  • replay a set of simultaneously pressed keys

The difficulty can be increased by not connecting the keyboard directly with the sound generator. This way, the trainee cannot verify, how the pressed keys differ from the target keys.

Sometimes it seems that you are catched in an infinite loop. This happens if there were too many keys pressed. The trainer collects all key press events, not only the ones that occur after the target set is played. This way you can correct yourself immediately, before the target is repeatedly played. The downside is, that there may be key press events hanging around. You can get rid of them by pressing a key again and again, but slowly, until the target is played, again. Then the queue of registered keys should be empty and you can proceed training.