Currently, embedded in the type of Signal is a free monoid:

newtype Signal a = mkSignal { signal :: Interval -> [a] }

This means we have all the means to defer monoidal operations until we actually process the data.

I can think of two solutions:

• 24 samples per beat might be too much?
• try invoke ghci programmatically, like hylide?

The best solution in my mind is to use a PRNG. Then we can build deterministic "coin flip" signals, without losing out on referential transparency (and therefore the ability to extract events at different sample rates in parallel, etc)

We need a way to use ghcid and preserve the event loop.

Probably use foreign-store

Syzygy backends should be nicely composable.

One way is to define a shared datatype for all backends (Map String (Float | String | Int)), and have each backend know how to consume that datatype.

We should start with a test that for a continuously running signal querying process, there is no clock drift.

TODO:

• Write a way to test clock drift
• implement clock drift correcting mechanism
• figure out what happens when bpm changes
• investigate if now absolute timestamps are better than relative timestamps for the MIDI backend

Output

• Support basic MIDI out
• Support sending NoteOn and NoteOff
• Support sending Control messages
• Support multiple channels
• Allow sub midi clock tick precision.

Input

• Support MIDI in (dynamic patterns!)

• Connect to SuperDirt
• Support sound
• Absolute Timestamps
• Support n
• Support speed

Right now our monoid instance works as a functor in the category of monoids that maps a monoid m to m x (℘(ℝ), ∩, ℝ) x m, modulo lots of handwaving.

Instead we want the resulting monoid to be m x (℘(ℝ), U, ∅).

This will involve using combineEvent instead of combineEventOverlap

Pathological case:

Given the following code, sig1 will have audio for the entire beat, while sig2 will "blip" mometarily. That is because in sig2, the NoteOff of the short event fires right after the second NoteOn fires.

sig1 :: Signal Word8
sig1 = mconcat
  [ embed 60 
  ]

sig2 :: Signal Word8
sig2 = mconcat
  [ embed 60
  , shift (-0.01) $ nest [ embed 60, mempty, mempty, mempty, mempty, mempty, mempty, mempty ]
  ]

The desired behavior of sig2 is the sound that gets drawn out for the entire beat, i.e. that the early NoteOff gets cancelled.

Otherwise, brief events will be penalize the user by interrupting their long events.

pure

Do we really want pure to be a periodic embedding in time?
ec6f2b8#diff-1dac8f014dcbad886e10623e125742adR16

If it is a single-time event, then

• what is its support?
  • [0, 1]? Why?
  • [0, infinity]? How do we encode that?

<*>

I'm not really comfortable with the current semantics of ap to be the applicative binary operator.

Example: ec6f2b8#diff-0951c5a3c5a6aa64b078d2fd55e035b6R110

ap right now throws out the temporal structure of the left signal, in favor of the right one. That is, we toss out the time data associated with the events of the left signal. The only
thing we keep from the left signal is the multiplicity of events, simply captured in a list.

https://en.wikibooks.org/wiki/Haskell/Applicative_functors#ZipList comes to mind as a lawful applicative instance that is what we're looking for, since pure is a periodic lifting.

So the focus instead should be on defining a zip :: Signal a -> Signal b -> Signal (a, b) instead.

Originally posed as a solution to #14

In order to embed IO actions that affect the actual signal graph, i.e. aleatoric signal transformers, we need to make our signal type monadic. This approach deviates from Tidal in that we introduce a new type parameter, rather than riding on top of the Event type parameter.

Pros:

• dynamic signal transformers

Cons:

• event extraction is no longer guaranteed deterministic, if the underlying monad is non-deterministic.
• this means if IO is somewhere in the base monad, we can only extract events once.
  • No concurrent backends for different render targets.
  • No non-realtime event visualization

This is how the type change would look like:

Current implementation

type Signal e = (Rational, Rational) -> [Event e]

Proposed implementation

type Signal e a = (Rational, Rational) -> ([Event e], a)

or

type Signal e m a = (Rational, Rational) -> ([Event e], m a)

Do we use mtl, and get something like the following?

type Signal e m a = ReaderT (Rational, Rational) (WriterT ([Event e]) m) a