Usability of switching Tidal versions

[jarmitage]

Since breaking changes are now occurring, existing Tidal code will in future not run as originally intended. It would be good to think about how to avoid marginalising/deleting Tidal's musical history as the source evolves.

From a usability perspective, challenges might be to:

• Tie a version of your Tidal code to a version of Tidal source
• Run your Tidal code with the correct source version
• As a new user with a clean install, pick up a piece of old Tidal code and run it with the correct version

Or perhaps other approaches altogether. How have other live coding languages/communities dealt with this (or not)? Could there be a YAML file or block comment at the top of the file with version information?

Or... d1 $ s "bd" # version "0.9.5 0.9.4 0.9.7" ?! I'm sure this is the killer feature we didn't know we needed.

[cannc4]

Hah, nice one.

d1 $ s "bd" # version "0.9.5 0.9.4 0.9.7" ?! I'm sure this is the killer feature we didn't know we needed.

do we really want to do this ?

#version (slow 4 $ sine)

[yaxu]

We could e.g. document a way to make isolated environments with stack, or implement something in a text editor, but I think this is probably not an issue for the tidal library

[jarmitage]

I agree that it might not be solvable at the library level, it’s just that there’s no equivalent for raising an issue on a github organisation page.

Both your ideas sound good. Maybe another first step is to document on the website how to do this the current way and see what opportunities there are to reduce friction.

[yaxu]

You could post a how-to on the blog?

…

On Thu, 27 Sep 2018, 10:54 Jack Armitage, ***@***.***> wrote: I agree that it might not be solvable at the library level, it’s just that there’s no equivalent for raising an issue on a github organisation page. Both your ideas sound good. Maybe another first step is to document on the website how to do this the current way and see what opportunities there are to reduce friction. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#349 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABtJApl9950JYIkS6MeYFvWHx-y56_rks5ufKA_gaJpZM4W6Vec> .

[OscarSouth]

I've found that it's pretty easy to build TidalCycles with the dependencies of a stack project and then refer to that project's exe in the 'ghci path'. For example I load TidalCycles with my 'The Harmonic Algorithm' module like this: stack ghci --main-is theHarmonicAlgorithm:exe:theHarmonicAlgorithm-exe. That allows easy specification of the desired Tidal version in the package.yaml for that project.

It's a workflow that might not work well (or be obvious) for those not accustomed to Haskell's toolchain though. Before getting to grips with stack, this would not have been something that I'd have been able to approach comfortably without a pretty detailed step by step walkthough.

[yaxu]

All versions of tidal are still installable (I think with thanks to @hvr):
https://matrix.hackage.haskell.org/#/package/tidal

[hvr]

Just for the record, by keeping tidal's metadata accurate, we don't need the extra complexity of Stack atop Cabal; one can also simply use self-contained cabal scripts ala

#!/usr/bin/env cabal

{- cabal:
build-depends: base, tidal ^>= 0.9.9
-}

import Tidal...

main :: IO ()
main = do
   -- ...

See also #405 (comment) for more details

[yaxu]

The newer cabal stuff seems that it would help with this.
It's not really a tidal dev issue, perhaps this would be better as a forum discussion, closing this?

[jarmitage]

Okidoke 🙂