There exists a linear interpolation buffer in FRP.Rhine.ResamplingBuffer.Interpolation. There are other methods of interpolation, e.g. cubic interpolation or sinc interpolation, which should be implemented as well.

Renames

renames we would like to have:

• TimeDomainOf -> Time
• SyncSF -> ClSF
• SF -> SN ("signal network")
• td -> time
• arrMSync_ :: m a -> SyncSF m cl arbitrary a to constMSync, and then to constMCl

Renames we have to think about once more:

• Step ->FixedStep?
• CycleClock -> Periodic?
• theTag :: SyncSF m cl a (Tag cl) -> tagS?
• sinceStart -> sinceInit? And:
  • startClock -> initClock
  • startSchedule -> initSchedule
• sinceSimStart -> ? (#30 )

Won't rename

• KeepLast -> ZeroOrderHold
• ResamplingBuffer.put -> ResamplingBuffer.input
• ResamplingBuffer.get -> ResamplingBuffer.output

Aliases to add

• ResBuf
• ParClock
• SeqClock
• absoluteS = timeInfoOf absolute, sinceStartS = timeInfoOf sinceStart, sinceTickS = timeInfoOf sinceTick

ToDo

Consistency checks

• Haddock errors
• Skim through code in PR in order to find alignment mistakes

Changes in other places (immediate)

• Article

Changes in other places (whenever they update to rhine-0.5)

• sonnendemo
• tutorial

Most modules have no top level documentation.

The FRP.Rhine.Cycle clocks give an implementation of pure, cyclically repeating clocks:
CycleClock '[500, 1000] would tick at 500, 1500, 2000, 3000, 3500 and so on. (See the CycleClock example in rhine-examples.)

In principle, the clock Step n is nothing else than CycleClock '[n], so this should be a type synonym.

But there exists a schedule for Step n clocks which doesn't exist yet for CycleClocks, so it should be generalised to CycleClock and then Step n refactored as a synonym.

(Also note #45 )

I'm getting the following:

src/FRP/Rhine/Clock/Select.hs:30:37:
    Wildcard not allowed
    In type family instance equation of ‘TimeDomainOf’:
      TimeDomainOf (SelectClock cl _)
cabal: Leaving directory '/tmp/cabal-tmp-14310/rhine-0.1.1.0'
Updating documentation index
/home/dash/tmp/rhine-tutorial/.cabal-sandbox/share/doc/x86_64-linux-ghc-7.10.3/index.html
cabal: Error: some packages failed to install:
rhine-0.1.1.0 failed during the building phase. The exception was:
ExitFailure 1

Maybe this need for GHC 8.2 can be specified in the cabal file somehow.

To do

Change from

{-# LANGUAGE SomeExtension      #-}
{-# LANGUAGE SomeOtherExtension #-}

to

{-# LANGUAGE SomeExtension #-}
{-# LANGUAGE SomeOtherExtension #-}

Reason

• It's not much uglier
• Only O(1) change when adding or removing an extension
• Much git-friendlier

@ivanperez-keera which SDL bindings are the best to work with for us?

It's restrictive to use Behaviour as a function argument, since it imposes a universal quantification on the clock, which often cannot be supplied.

• Choose the same stack resolvers on all projects (ideally the newest that works)
• If necessary, update dependency versions

Use the MonadConc class from concurrency to generalise the type signature of the concurrently schedule. Find out whether it overlaps with the Reader and Writer schedules.

Often we have to connect to external frameworks with callbacks, e.g. OpenGL. What are general purpose utilities to connect to them? It's a bit like dunai's ReactHandles for some parts of the signal network.

Currently, FRP.Rhine exports everything about SyncSFs, the definition of the Clock type class and the Schedule and ResamplingBuffer types. But it would be better and without disadvantage to export all clocks, schedules and buffers as well. Ideally, when creating a rhine project, you just need to import FRP.Rhine, and that's it.

In some places, I've accidentally used pipes in documentation instead of '.

There should be a minimal implementation of sprites, which are basically pictures, with the following features:

• They should contain a picture and a position
• They should be clickable (i.e. there is an event clock (subclock of the main event clock) that ticks on sprite click events)

sinceSimStart is an unsuggestive name. Possibly, sinceInit would be better.

Implement a clock in a special monad m (or monad transformer) that ticks upon a particular side effect in m (depending on the clock value).
Other parts of the signal network that are also in m can then trigger events on this clock.

One crude implementation could go roughly like:

data MVarEventClock a = MVarEventClock (MVar a)

instance Clock IO MVarEventClock where
  startClock (MVarEventClock var) = arrM_ getCurrentTime &&& arrM_ (takeMVar var)

triggerEvent :: MVarEventClock a -> a -> IO ()
triggerEvent (MVarEventClock var) = putMVar var

Care needs to be taken that triggerEvent does not lead to deadlocks when called from a signal on the same clock. Possibly, Chan or STM.TChan will give a more robust implementation.

Is it possible to implement such a clock purely?

There should be a ResamplingBuffer that collects the incoming data, which has to be a monoid, via mappend.

https://github.com/turion/rhine-tutorial should be part of this repo.

Advantages

• Track all issues here
• Have documentation closer together
• Travis integration of everything in one place
• Coherent version updates for main library and all subprojects

ToDo

• Decide whether we need the version history of the other repo (No.)
• Decide what to do with the initial and final status (Separate files, both compilable and executable.)
• Merge the files in here
• Merge issues here and convert any TODOs and problems to issues
• Add the tutorial to travis
• Close the other repo and add info to the Readme there

@ivanperez-keera, this is another issue you raised:

src/FRP/Rhine/Clock.hs:135:8: error:
    • Type indexes must match class instance head
      Expected: TimeDomainOf (HoistClock m1 m2 a)
        Actual: TimeDomainOf (HoistClock m1 m2 cl)
    • In the type instance declaration for ‘TimeDomainOf’
      In the instance declaration for ‘Clock m2 (HoistClock m1 m2 a)’
    |
135 |   type TimeDomainOf (HoistClock m1 m2 cl) = TimeDomainOf cl
    |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/FRP/Rhine/Clock.hs:136:8: error:
    • Type indexes must match class instance head
      Expected: Tag (HoistClock m1 m2 a)
        Actual: Tag (HoistClock m1 m2 cl)
    • In the type instance declaration for ‘Tag’
      In the instance declaration for ‘Clock m2 (HoistClock m1 m2 a)’
    |
136 |   type Tag          (HoistClock m1 m2 cl) = Tag          cl
    |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

Rhine should support GHC 8.4.
Subissues: #32 #42
Open PR: #41

All FIFO buffers can also exist in a LIFO variant.

The following wouldn't type check:

clocks = [Millisecond 10, Millisecond 100]

But it would be practical, e.g. to fold a large number of behaviours over several clocks etc.

In dunai there are

infixr 4 <-<
infixr 4 >->

while in rhine the same operators (with identical semantics) are defined as

infixl 6 <-<
infixr 6 >->

This can be maximally confusing. Any idea which side should change?

(Time-unaware) resampling buffers are roughly:

data ResBuf m a b = ResBuf
  { get :: m (b, ResBuf m a b)
  , put :: a -> m (ResBuf m a b)
  }

This is a final coalgebra, a general coalgebra is something like:

data ResBuf m a b s = ResBuf
  { get :: StateT s m b
  , put :: a -> StateT s m ()
  }

This must be related to lenses somehow, although it is unclear to me right now how precisely. Hints and ideas welcome. This is not an urgent issue, but an open question.

Keera hails reactive values are somehow related, except they work without state/continuations but just IO.

It's possible to build an unintended space leak in a resampling buffer if data is produced very quickly and accumulates on the buffer. So far that's not surprising, for some buffers (i.e. collect, unbounded queues), that's what has to be expected.

I'm annoyed that it's also possible to create space leaks unintentionally. There is an example in https://github.com/turion/rhine/tree/dev_spaceleak. On one clock, a lot of numbers are produced, and sent to the buffer in order to be added there. On the other clock, the current sum is retrieved. In principle, it should be possible to just add the numbers up strictly, but it's not obvious to me how to achieve that.

Standard practice in Haskell seems to be to call the empty type Void, as in https://hackage.haskell.org/package/void.

• FixedRate is against the Rhine philosophy that sample rates should be type-level. There are better alternatives now (Step/FixedStep), and it should be removed.
• Count is just Step 1/FixedStep 1. Should be a type synonym, and moved into the FixedStep module.

sinceTick is the record selector of TimeInfo that selects the time difference since the last tick. Should it be renamed to sinceLast? Or another name? @ivanperez-keera, opinions?

Currently, the ADSR example is a behaviour, which means that it can run on any clock. It would be nice to have an audio clock on which it runs, and a user interface (console is ok) so one can actually hear what's going on.

For the fifo and lifo buffers, implement a bounded version that forgets the oldest values when the size is above a given threshold.

Right now, rhine-gloss apps have to have a rigid clock topology. The advantage is a completely side-effect free framework, but the disadvantage is that they have to be basically synchronous.

It should be easy to use playIO from gloss and wormhole (or event) clocks in IO that communicate with gloss. They can then be incorporated in an app with a completely free clock topology.

It might be a good idea to have forkOS versions of the concurrent schedules.
This probably has benefits e.g. for OpenGL, but needs testing.

Another possibility would be to just use forkOS instead of forkIO directly. The overhead shouldn't be so high since only a handful are created at the beginning of the program, and never during the flow.

The formula should be more likely (v ^* (1 - exp (-sinceTick / t)) ^+^ vAvg ^* exp (-sinceTick / t) or so.

Dunai's exception handling has been ported to Rhine's SyncSFs with some boiler plate code. This is still missing for most other transformers (e.g. #13 is a subissue of this).

The main issue is always that one can't directly apply the functions from Dunai's Control.Monad.Trans.MSF.*, since in a SyncSF, the outermost monad layer is ReaderT.
So one needs to commute some transformer past the outermost ReaderT layer of SyncSF,
then handle it, and possibly commute it back.
Doing this in a systematic way (e.g. a type class) would maybe clean up code and simplify progress.

In FRP.Rhine.ClSF.Util, timers throw () as an exception when the time is up. But for undersampling, this is sometimes not ideal, as the exception might get thrown long after the time is up. So the timer should raise the overdue time as an exception, which can then be handled further.

With GHC 8.4, Semigroups become more of a thing, so it's time to relax the type signature of schedSelectClock to requiring cl only to be a Semigroup.

Quite a few functions that exist in the corresponding dunai module (to be found here) have not been translated yet to SyncSFs. It's mostly about pushing the top ReaderT layer around to access the ExceptT layer beneath, and plenty of working examples exist.

• reactimate
• timeInfo

This is necessary to use SyncSF's DSP out of the box. But note ivanperez-keera/dunai#13.

Looking at http://hackage.haskell.org/package/clash-prelude-0.99/docs/Clash-Tutorial.html,
I think there should be a way to implement something like compileToClash :: SF Identity ClashClock (Signed n) (Signed m) -> Clock System Source -> Signal System (Signed n) -> Signal System (Signed m), and this could be used to compile some Rhine programs to Clash.

• Wormholes have to be cleaned up (just code on my machine) and tested
• A completely strict deepseq wormhole has to be written (so you can do heavy calculations in a separate thread). This is actually a dunai issue, but I'm not touching dunai's wormholes because of ivanperez-keera/dunai#100

In FRP.Rhine.Clock.Select, there is a schedule for two SelectClocks of the same main clock, schedSelectClocks. There should be a schedule for a SelectClock and its main clock.

Currently, Data.MonadicStreamFunction.Util from Dunai exports fifo, but FRP.Rhine.ResamplingBuffer.FIFO does as well.

3 options:

• Don't reexport Dunai's fifo. Maybe leave a note in the docs?
• Rename Dunai's fifo. Probably unmotivated from upstream perspective.
• Rename Rhine's fifo, maybe to fifoUnbounded. Whatever decision, propagate it to lifo.

Whenever I publish a package
on the packages server, called hackage,
then, for rhine to shine brightly,
I'll commit unto nightly,
the package on hackage to stackage.

There are some examples in https://github.com/turion/rhine/tree/dev_spaceleak that show how to fix the leaks. It would be great to look at them closely and rewrite/document the example in an educational way. Then the branch can be merged.

There are some places where info about Rhine should be posted in a few months:

• The Haskell wiki
  • The FRP page
  • Other pages
• Mailinglists (which? Yampa, ...)
• Add the article to this repository

If you know about other places where such info should appear, comment here.

Random generators have been added to dunai. There should be an interface for SyncSFs as well, once this issue is resolved.

Generalise #62 in such a way that arbitrary clock trees can be hoisted. Two problems occur:

• This changes the type of the clock, which suggests a type family type HoistedClock SequentialClock cl1 cl2 = SequentialClock (HoistedClock cl1) (HoistedClock cl2).
• It's hard to define functions on type families, i.e. see https://github.com/turion/rhine/pull/61/files#r190572641 . It seems there can't be a function hoistedClock :: (forall a . m a -> m' a) -> cl -> HoistedClock m m' cl with a type family as described above.

Possibly the types SequentialClock and ParallelClock and the whole type family business should be given up in favour of a data kind representing clock trees. (I have some notes in that direction which don't compile fully yet.)

Right now, it is possible to escape transformers in SyncSFs, e.g. given syncSF :: SyncSF (ExceptT e m) a b, we can use FRP.Rhine.SyncSF.Except to handle the exceptions and remove the ExceptT layer. Solving #14, this can be done for other transformers as well.

But there is no such utility to do so for Rhines, although it is conceivable to do this for several monad transformers such as ReaderT. For example, we'd like a type signature like this:

runReaderR :: Rhine (ReaderT r m) cl a b -> r -> Rhine m cl a b

It's a bit unclear what happens to cl, i.e. whether its type needs to be transformed as well. This depends on whether cl is polymorphic in m or whether it depends on a particular type. In the latter case, we'd have to have a HoistedClock or similar.

It's harder to say how exception handling would work on whole Rhines, since one would have to decide whether to restart the clock upon handling the exception, with the new clock.