Tidal 2.0?

Innards
1

I know we're still working towards 1.9.0 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 and integrating beat-based patterns into Tidal is fundamental enough to trigger this rewrite.

We've made a start here: Tidal/tidal-cycseq/src/Sound/Tidal2 at cycseq · tidalcycles/Tidal · GitHub

The big change is that a Pattern is now an abstract class. The 'old' pattern type is now renamed Signal, and is defined as an instance of a Pattern. This is to make room for the new Sequence class, 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!

10 Likes
2

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

6 Likes
3

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.

2 Likes
4

@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 for steps towards this. It does need a lot of help though to get it working cross-platform.

1 Like
5

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.

1 Like
6

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

7

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.

8

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.

1 Like
9

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

2 Likes
10

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

11

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

2 Likes
12

I'd be interested in contributing, particularly to implement some of the ideas I sketched out here and have never fully implemented. 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!

13

That sounds great!

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.

Again this is working to a large extent in the experimental feedforward editor, with some way to exposing this info via tidal-listener as 'highlights'.

14

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!

15

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?

16

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.

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

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

1 Like
17

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!

18

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

2 Likes
19

had a bit of time to work on the parser:

i also thought a bit about a formalisation of the mini-notation with something like the extended backus-naur form but it seems tricky because of the types.. maybe someone has encountered a formal language specification that would be suitable for mini notation?

20

I did kind of formalise an early version of the mininotation in my PhD thesis using EBNF. I remember struggling with types, and ended up parameterising the rules to allow for them:

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..