Closed polymorphicengine closed 5 months ago
Btw, can you update the BootTidal.hs file so that it's easier to test this branch?
i got around to the restructuring of the stream module now. it is seperated into 7 sub-modules now all of which are re-exported by the old Sound.Tidal.Stream
module. They are:
Config
, basically as before containing the config of the clock and the control listenerTypes
, basically the module StreamTypes
, but including the Stream
and Target
definitionsTarget
, contains logic for creating targets, and sending messages to targets, aswell as the default dirt/superdirt targetsProcess
, defines doTick
, which is the core logic of querying patterns at an arc and processing it's events into OSC messages which are then sent out to the tragetsUI
, the exposed user interface into the stream logic, contains all functions for interacting with a given streamListen
, function for interacting with the stream from outside via OSCMain
, brings the Process
and Listen
modules together to definestartStream
, aswell as startTidal
i didn't make any changes to the code yet, it was just a matter of copy and pasting things into the right places. hope this makes sense to you, let me know what you think! @mindofmatthew @yaxu @Zalastax
This reorganization makes sense to me!
I was curious: are you thinking of doing a major restructuring of the Stream code in this PR? I could see it getting unwieldy, but since there are only a couple of us who will likely comment, I think it's manageable. If that's the case, would you mind if I submitted pull requests against your branch? I have some ideas of my own (eg #1051), and would generally be interested in helping out with the effort!
are you thinking of doing a major restructuring of the Stream code in this PR?
i thought about it, but i think we could actually close this PR if everyone is happy with it and then work on a new, seperate PR to actually make some changes to the code, aswell as add some things etc. maybe that would make it a bit cleaner. what do you think?
That sounds good with me, although I'd wait to merge it in until we can get a 1.9.5 release out.
Unless @yaxu objects, then I'm going to look into merging the build fixes (#1062) and then releasing 1.9.5 later this week! In the meantime, I think you're safe to treat this PR as approved and start a new branch off of this one for a future Stream PR
Hi sorry I'm still away from things until next week, but had a quick look and can't see anything controversial so please go ahead @mindofmatthew !
Shall we merge this now?
@yaxu Sounds great! Go ahead and do this before you do your branch tidying
to make tidal-link and tidals clock functionality more widely useable (i.e. not dependend on types from tidal) i decided to reimplement the Tempo.hs module in a new module Sound.Tidal.Clock, that is part of tidal-link. The functionality is still the same, but i rewrote the code to make the clock independed of tidal and added an API so it can be used more easily.
i also restructured the code into a Clock monad, which is essentialy just the IO monad with some read-only memory for the configuration and mutable state, imo this makes the code much easier to comprehend and maintain.
i also rewrote some of the Stream and Transition modules to use the Clock instead of Tempo.hs, here i tried to make as little changes as possible, most of the code is exactly the same. the most notable changes are
streamReplace
:updatePattern
is no longer handled by the clock, it was only that way to tag the patterns with the time of evaluation, this time can be gotten from the clock through the APIstreamFirst
:onSingleTick
is also no longer handled by the clock, the zeroedLinkOperations needed for the action can also be gotten through the clock APItransiton
: also this function is no longer handled directly by the clockthe next step would be to restructure the Stream module, possibly splitting it into a couple of modules, maybe also rewriting Stream as an IO based monad.
what do you think @yaxu @Zalastax @mindofmatthew ?