Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update changes for upcoming Tidal v1.10 #289

Open
6 tasks
yaxu opened this issue Feb 18, 2025 · 9 comments
Open
6 tasks

Update changes for upcoming Tidal v1.10 #289

yaxu opened this issue Feb 18, 2025 · 9 comments

Comments

@yaxu
Copy link
Member

yaxu commented Feb 18, 2025

Most important things to update in the docs:

BootTidal configuration has changed. Most has moved to Sound.Tidal.Boot (in tidalcycles/Tidal#1081), so BootTidal.hs is now a lot smaller. files to update:

Link clock is now disabled by default. We should add info about how to enable it on-the-fly and permanently (via BootTidal.hs) to

There's a lot of other changes, but maybe better to focus on the upcoming website for other stuff?

@sss-create
Copy link

changing the latency in BootTidal.hs now requires significant more steps than before + the config arguments are reversed. Now it is (config -> osc), before it was (osc -> config):

...
:set -package tidal-link

-- Import all the boot functions and aliases.
import Sound.Tidal.Boot
import qualified Sound.Tidal.Clock as C

...

-- Create a Tidal Stream with the default settings.
-- Use 'mkTidalWith' to customize these settings.
 tidalInst <- mkTidalWith 
   (defaultConfig { cClockConfig = C.defaultConfig { C.cFrameTimespan = 1/20, C.cProcessAhead = 3/10 } }) 
   [(superdirtTarget {oLatency = 0.05}, [superdirtShape])]
...

we should tackle this in the tidal source. Perhaps distributing a configurable defaultClock via BootTidal?

@yaxu
Copy link
Member Author

yaxu commented Feb 19, 2025

Hmm @polymorphicengine last worked on this I think, and might have insights on how things ended up this way..

@polymorphicengine
Copy link
Contributor

polymorphicengine commented Feb 20, 2025

Now it is (config -> osc), before it was (osc -> config)

yes i guess we should reverse arguments in mkTidalWith

Perhaps distributing a configurable defaultClock via BootTidal?

here i'm unsure what you mean, the Clock module already exports a defaultConfig, which is part of the defaultConfig for the stream Config, so to set the latency in your example you could have just:

-- Import all the boot functions and aliases.
import Sound.Tidal.Boot

...

-- Create a Tidal Stream with the default settings.
-- Use 'mkTidalWith' to customize these settings.
 tidalInst <- mkTidalWith defaultConfig
   [(superdirtTarget {oLatency = 0.05}, [superdirtShape])]
...

which is as verbose as it used to be.

anyways, if the user wants to configure the clock then they would be required to import the clock module, which is not great since that would probably require them to additionally cabal install tidal-link. (also :set -package tidal-link, might actually unload the previously imported modules?)

a way to avoid this is if we define a bunch of setters in Sound.Tidal.Stream.Config like

setFrameTimespan :: Double -> Config -> Config etc.

@yaxu
Copy link
Member Author

yaxu commented Feb 20, 2025

I think adding setters is probably the most user friendly approach..

@sss-create
Copy link

@polymorphicengine,
to change the latency in the clock as described in the docs one needs access cFrameTimespan and cProcessAhead. They are part of cClockConfig. Yes, defaultConfig is exported, but not the defaultConfig for the clock, afaict. I might be wrong tho.

(defaultConfig { cClockConfig = C.defaultConfig { C.cFrameTimespan = 1/20, C.cProcessAhead = 3/10 } })

@yaxu
Copy link
Member Author

yaxu commented Feb 20, 2025

This was the case for enabling the link clock too, until ahihi pointed out a shortcut:

tidalcycles/Tidal#1138

@sss-create
Copy link

sss-create commented Feb 20, 2025

ah yeah, I can look into making setters/aliases

@sss-create
Copy link

another thing: there is startTidal, startStream, mkTidal and mkTidalWith. When to use which?
If I want to give a custom OSC latency and try to use superdirtShape with mkTidalWith I get an error, because superdirtShape is only a Target while mkTidalWith expects OscMap, which is [(Target, [OSC])].

startTidal otoh works, as usual.

So what/which method to start Tidal with custom OSC should be described in the docu?

@yaxu
Copy link
Member Author

yaxu commented Feb 21, 2025

If I remember right, the more general startStream was supposed to replace startTidal a long while ago but it somehow never happened. the mkTidal / mkTidalWith are new in 1.10, so no documentation will mention them yet.

I think we should move to use the new mkTidal ones, as that's what the default BootTidal.hs now uses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants