# Tidal 2.0?

**URL:** <https://uzu.lurk.org/t/tidal-2-0/4247>\
**Category:** TidalCycles\
**Tags:** innards\
**Created:** [31 August 2022 13:44 UTC](https://uzu.lurk.org/t/tidal-2-0/4247 "2022-08-31T13:44:53Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [31 August 2022 13:44 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/1 "2022-08-31T13:44:53Z")

</div>

I know we're still [working towards 1.9.0](https://club.tidalcycles.org/t/releasing-tidal-1-9-0/4241) but I thought it would be good to start a thread about Tidal 2.0, which would be more of a rewrite (like 1.0 was).

[Aravind's great work on South Indian rhythms](https://club.tidalcycles.org/t/formalising-konnakol-haskell-summer-of-code-update/4170) and integrating beat-based patterns into Tidal is fundamental enough to trigger this rewrite.

We've made a start here: [https://github.com/tidalcycles/Tidal/tree/cycseq/tidal-cycseq/src/Sound/Tidal2](https://github.com/tidalcycles/Tidal/tree/cycseq/tidal-cycseq/src/Sound/Tidal2)

The big change is that a `Pattern` is [now an abstract class](https://github.com/tidalcycles/Tidal/blob/cycseq/tidal-cycseq/src/Sound/Tidal2/Pattern.hs). The 'old' pattern type is [now renamed `Signal`](https://github.com/tidalcycles/Tidal/blob/cycseq/tidal-cycseq/src/Sound/Tidal2/Signal.hs), and is defined as an instance of a `Pattern`. This is to make room for [the new `Sequence` class](https://github.com/tidalcycles/Tidal/blob/cycseq/tidal-cycseq/src/Sound/Tidal2/Sequence.hs), as a second instance of `Pattern`.

This is all very experimental, based on my earlier 'remake' of Tidal. It's not actually plumbed in to the scheduler yet so you can't make music with it! Also Aravind is still to integrate the latest version of his Sequence type. It's really exciting though I think, opening up a whole new way of using Tidal, creating a lot of creative ground to explore.

Anyway still doing some groundwork, but would be happy to hear from people who'd be up for contributing to this, whether working on the Haskell or documentation etc as we go.. It'd be good to take the opportunity to take on some of the shortcomings on the current codebase and remove barriers to taking contributions where possible. If you have ideas for how to make it easier to contribute to Tidal please shout!

---

<div class="post-metadata">

**Author:** ![polymorphic.engine](https://uzu.lurk.org/user_avatar/uzu.lurk.org/polymorphic.engine/32/30_2.png) [@polymorphic.engine](https://uzu.lurk.org/u/polymorphic.engine)\
**Post date:** [31 August 2022 14:22 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/2 "2022-08-31T14:22:21Z")

</div>

it would be really cool to give a formal specification of the mini-notation, i think there are still some open issues all related to parsing and it would make it easier to fix them once we have a clear definition of the mini-notation

---

<div class="post-metadata">

**Author:** ![Jalex](https://uzu.lurk.org/user_avatar/uzu.lurk.org/jalex/32/2069_2.png) [@Jalex](https://uzu.lurk.org/u/Jalex)\
**Post date:** [1 September 2022 06:10 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/3 "2022-09-01T06:10:03Z")

</div>

a very stupid and naive question: are there any plans to make new tidal cycles into a separate independent application? just the accumulated base and tools deserve to be put into something more independent and not be a supercollider add-on. I'm exactly saying that this will allow you to concentrate more on ideas than to catch bugs due to such a large interaction of different applications.

ps

sorry if I offended anyone. I just keep getting excited about tidal cycles. It remains for me an abyss of new knowledge and which deserves a separate ecosystem in the form of a standalone application.

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [1 September 2022 10:16 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/4 "2022-09-01T10:16:11Z")

</div>

@polymorphic.engine Yes true. That would also make implementing/testing against the strudel/vortex implementations easier I guess. Also with the new additional beat-oriented sequence representation, the mininotation should be a much more straightforward mapping to Haskell. This is also an opportunity to make breaking changes in the mininotation. For example now that \_ and @ are aliases, we could repurpose @ for ties. We can also make sure that everything is patternable in the mininotation that could be.

@jalex Yes that would be so good, and I share your frustration with this aspect and the difficulty of installing etc. See [Releasing Tidal 1.9.0](https://club.tidalcycles.org/t/releasing-tidal-1-9-0/4241) for steps towards this. It does need a lot of help though to get it working cross-platform.

---

<div class="post-metadata">

**Author:** ![mvdirty](https://uzu.lurk.org/user_avatar/uzu.lurk.org/mvdirty/32/2179_2.png) [@mvdirty](https://uzu.lurk.org/u/mvdirty)\
**Post date:** [1 September 2022 15:30 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/5 "2022-09-01T15:30:42Z")

</div>

Just so this opinion does not go unstated:

Some of us use Tidal very specifically because of the ecosystem it _already_ integrates into.

If 2.0 broke from that, someone would surely fork away from 1.9 or whatever recent version was necessary in order to continue leveraging that integration. Hopefully 2.0 (and 1.9 too) can continue to support things like SC (and SuperDirt & friends,) normal GHCI, etc.

---

<div class="post-metadata">

**Author:** ![geikha](https://uzu.lurk.org/user_avatar/uzu.lurk.org/geikha/32/2701_2.png) [@geikha](https://uzu.lurk.org/u/geikha)\
**Post date:** [1 September 2022 20:05 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/6 "2022-09-01T20:05:26Z")

</div>

i get why you chose that word but i feel like Signal is a bit off... matter of fact i feel they should be inverted? i mean english is not my mother tongue of course but:

i feel like signal makes sense as the name for the abstract class instead of pattern. like, a sequence is a signal as much as a pattern (in the current tidal sense) is. the signal consisting of information about events in time to be played, which can either be defined in terms of sequences or patterns.

not to be nit picky just wanted to give my thoughts

---

<div class="post-metadata">

**Author:** ![Jalex](https://uzu.lurk.org/user_avatar/uzu.lurk.org/jalex/32/2069_2.png) [@Jalex](https://uzu.lurk.org/u/Jalex)\
**Post date:** [2 September 2022 05:37 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/7 "2022-09-02T05:37:07Z")

</div>

you are absolutely right in your reasoning, but I see the strudel project and similar thoughts arose from here. with all this, I believe that the vanilla version of the tide should be used as a testing ground for testing and searching for innovations, although, of course, completely different resources are needed here. according to the results, I am still at the beginning of the journey and it is quite possible that I simply do not have enough experience and in the future my opinion may change.

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [2 September 2022 09:26 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/8 "2022-09-02T09:26:54Z")

</div>

Yes agreed! We are just talking about something like a packaged version, which would probably include supercollider internally as well as an editor, binary version of a Tidal interpreter etc.

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [2 September 2022 09:28 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/9 "2022-09-02T09:28:58Z")

</div>

It works for me because a signal is about continuous time, a sequence is about discrete time, and both can be patterns.

---

<div class="post-metadata">

**Author:** ![mvdirty](https://uzu.lurk.org/user_avatar/uzu.lurk.org/mvdirty/32/2179_2.png) [@mvdirty](https://uzu.lurk.org/u/mvdirty)\
**Post date:** [3 September 2022 16:13 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/10 "2022-09-03T16:13:32Z")

</div>

When you say “We are just talking about something like a packaged version”, I assume that is instead in reference to 1.9, yes?

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [4 September 2022 22:24 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/11 "2022-09-04T22:24:21Z")

</div>

Yes, we've got a bit sidetracked.. 1.9 will hopefully take steps towards a more easily installed binary distribution of Tidal.

---

<div class="post-metadata">

**Author:** ![archaic.tech](https://uzu.lurk.org/user_avatar/uzu.lurk.org/archaic.tech/32/2965_2.png) [@archaic.tech](https://uzu.lurk.org/u/archaic.tech)\
**Post date:** [11 September 2022 20:29 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/12 "2022-09-11T20:29:13Z")

</div>

I'd be interested in contributing, [particularly to implement some of the ideas I sketched out here and have never fully implemented](https://club.tidalcycles.org/t/rfc-improving-the-interface-for-interacting-with-tidal-streams/3528). The general philosophy here would be a fully-mutable Tidal engine, where it's possible to add/remove/reconfigure OSC targets, and define custom OSC control functions live. This would make it easier for boot code to come from multiple sources.

I really like the idea of an abstract `Pattern`! I'd suggest a special-case `Silence` pattern, that could also implement `eq` and such. Currently, there's no way to determine which patterns are silent/hushed, which I've wanted an editor to display.

I'm also very interested in helping figure out better editor integration. The work that's been done in Strudel with AST-based tagging of mininotation events is awesome, and it would be great to figure out how this type of metadata could also be passed into Tidal!

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [12 September 2022 11:53 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/13 "2022-09-12T11:53:34Z")

</div>

> [@archaic.tech](#):
>
> I'd be interested in contributing, [particularly to implement some of the ideas I sketched out here and have never fully implemented](https://club.tidalcycles.org/t/rfc-improving-the-interface-for-interacting-with-tidal-streams/3528). The general philosophy here would be a fully-mutable Tidal engine, where it's possible to add/remove/reconfigure OSC targets, and define custom OSC control functions live. This would make it easier for boot code to come from multiple sources.

That sounds great!

> [@archaic.tech](#):
>
> I really like the idea of an abstract `Pattern`! I'd suggest a special-case `Silence` pattern, that could also implement `eq` and such. Currently, there's no way to determine which patterns are silent/hushed, which I've wanted an editor to display.

Feedforward shows which patterns are silenced. I don't think it needs to be part of the core representation of a pattern, it feels more like a user interface concern. It could be something that tidal-listener could take care of though.

> [@archaic.tech](#):
>
> I'm also very interested in helping figure out better editor integration. The work that's been done in Strudel with AST-based tagging of mininotation events is awesome, and it would be great to figure out how this type of metadata could also be passed into Tidal!

Again this is working to a large extent in the experimental feedforward editor, with some way to exposing this info via [tidal-listener](https://github.com/tidalcycles/Tidal/tree/main/tidal-listener) as 'highlights'.

---

<div class="post-metadata">

**Author:** ![archaic.tech](https://uzu.lurk.org/user_avatar/uzu.lurk.org/archaic.tech/32/2965_2.png) [@archaic.tech](https://uzu.lurk.org/u/archaic.tech)\
**Post date:** [12 September 2022 13:18 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/14 "2022-09-12T13:18:35Z")

</div>

That makes sense—some of these are really requests for tidal-listener 2.0 (which I hope would be part of a tidal 2.0 release). I've had some difficulty porting the feedforward/tidal-listener highlight features to a more general GHCI-like idiom, where the user is sending over arbitrary lines of code, rather than patterns labeled at the OSC-level. But I'm happy to keep tinkering and make more specific suggestions as things come up!

---

<div class="post-metadata">

**Author:** ![ninioArtillero](https://uzu.lurk.org/user_avatar/uzu.lurk.org/ninioartillero/32/2749_2.png) [@ninioArtillero](https://uzu.lurk.org/u/ninioArtillero)\
**Post date:** [21 September 2022 03:04 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/15 "2022-09-21T03:04:25Z")

</div>

I'll like to contribute, but gotta figure out how. I'm learning Haskell and would like to use this codebase development as a case study of sorts. May be I could help with documentation as I figure things out? Is there a particular channel or platform for the discussion and developmento of 2.0?

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [21 September 2022 08:09 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/16 "2022-09-21T08:09:54Z")

</div>

Yes would be great to have you involved. Currently it's all in pieces though so a bit hard to jump in!

I'm working on rewriting the innards on the tidal-cycseq branch, nothing really works yet, but @ARAVIND_MOHANDAS is working on Sound.Tidal.Sequence, and I'm working on Sound.Tidal.Signal.\*, with Sound.Tidal.Pattern bringing them together as a typeclass.

> **[Tidal/src/Sound/Tidal at cycseq · tidalcycles/Tidal](https://github.com/tidalcycles/Tidal/tree/cycseq/src/Sound/Tidal)**
>
> cycseq/src/Sound/Tidal

It's too in flux at the moment but hopefully soon I'll reach 'gabba zero' at the point where it's possible to trigger distorted kicks, and then it'd be great to have additional eyes, help with documentation etc.

There's some discussion about syntax etc here:

[https://club.tidalcycles.org/t/rfc-syntax-for-combining-patterns/4296/17](https://club.tidalcycles.org/t/rfc-syntax-for-combining-patterns/4296/17)

We could also make a channel on the tidal discord if you use that?

---

<div class="post-metadata">

**Author:** ![ninioArtillero](https://uzu.lurk.org/user_avatar/uzu.lurk.org/ninioartillero/32/2749_2.png) [@ninioArtillero](https://uzu.lurk.org/u/ninioArtillero)\
**Post date:** [21 September 2022 17:39 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/17 "2022-09-21T17:39:38Z")

</div>

I usually don´t, but every now and then I use discord and I'm confortable with the platform. If that's convenient to you and the others involved I'll gladly join the discussion there.

I think this rewrite/refactor is really exciting, and I'm in for putting those extra eyes and will to understand deeply and document. Thanks!

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [22 September 2022 09:39 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/18 "2022-09-22T09:39:41Z")

</div>

Cool I think ongoing work will include rationalising the sequence and signal types and the pattern instance.. The old Pattern type is renamed to Signal, and it'll be fun going through all the signal functions and seeing which ones should either be

a) implemented on the more general Pattern class so that they apply both to signals and sequences  
b) added to the Pattern class declaration but not implemented there, so that they are implemented differently for Sequence and Signal but with the same type signature  
c) kept in the Signal class because the function doesn't apply to sequences

---

<div class="post-metadata">

**Author:** ![polymorphic.engine](https://uzu.lurk.org/user_avatar/uzu.lurk.org/polymorphic.engine/32/30_2.png) [@polymorphic.engine](https://uzu.lurk.org/u/polymorphic.engine)\
**Post date:** [24 September 2022 16:08 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/19 "2022-09-24T16:08:20Z")

</div>

had a bit of time to work on the parser:

> <https://github.com/tidalcycles/Tidal/pull/952>
>
> while i was working on the parser for chords i saw that the code of the parser w…as overall a bit messy and hard to understand
> so i decided to clean the code up and make it generally more like a parser combinator, writing more basic parsers and combining them all together in the end
> there were also too many parsers 'eating' whitespace.. i think it would be generally a bit better to be not so liberal about whitespace in mininotation anymore (for example allowing patterns like \`"1 \* 5 \[4 5\] !!"\`) 
> i'm open to discussing this point a bit more though, since there might be examples where more whitespace will increase readability, as i implemented it now it is very strict (see the examples that fail in the test)
> so this would actually be a breaking change 
> it would be good to sort this out until the release of 2.0
> 
> while this is mostly just a refactoring / rewriting i think this is a good step towards new mini-notation features

i also thought a bit about a formalisation of the mini-notation with something like the extended [backus-naur form](https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form) but it seems tricky because of the types.. maybe someone has encountered a formal language specification that would be suitable for mini notation?

---

<div class="post-metadata">

**Author:** ![yaxu](https://uzu.lurk.org/user_avatar/uzu.lurk.org/yaxu/32/2_2.png) [@yaxu](https://uzu.lurk.org/u/yaxu)\
**Post date:** [25 September 2022 13:54 UTC](https://uzu.lurk.org/t/tidal-2-0/4247/20 "2022-09-25T13:54:10Z")

</div>

I did kind of formalise an early version of the mininotation in [my PhD thesis](https://slab.org/2012/02/22/thesis/) using EBNF. I remember struggling with types, and ended up parameterising the rules to allow for them:

```nohighlight
colourRhythm = rhythm(colourname) ;
doubleRhythm = rhythm(double) ;
stringRhythm = rhythm(string) ;
intRhythm = rhythm(int) ;
boolRhythm = rhythm(bool) ;
colourname = "blue" | "red" | "green" | ... ;
bool = "t" | "1" | "f" | "0" ;
rhythm(atom) = whitespace, sequence(atom) ;
sequence(atom) = { part(atom) } ;
whitespace = { " " } ;
part(atom) = atom | "~" | poly(atom) | polypad(atom) | sequenceParens(atom) ;
sequenceParens(atom) = "(", sequence(atom) , ")" ;
poly(atom) = "[", rhythm(atom), {",", rhythm(atom)}, "]" ;
polypad(atom) = "{", rhythm(atom), {",", rhythm(atom)}, "}" ;

```

Is that helpful?

I should add that this was the first and last time I dealt with EBNF, and didn't really have a use in mind apart from being encouraged by my supervisor to do it..

[Next page](https://uzu.lurk.org/t/tidal-2-0/4247.md?page=2)