Think about full DSL / "maxi notation"

[felixroos]

Some time ago, I stumbled across Alternate Timelines for TidalCycles, where this snippet of pseudo code is shown:

jux <(rev) (iter 4)> $ sound [bd (every 3 (fast 4) [sn])]

I really like the idea of having a single language that combines terseness and functionality.
From my perception, this looks like the logical continuation of the Tidal language:

1. Haskell Tidal
2. Mini Notation
3. Ports to Python / Javascript
4. Custom DSL?

Having a DSL would allow Tidal to mature from a loosely consistent multi language implementation, to a real language specification, allowing to implement it in different languages with a clearly defined feature set.

I don't know if strudel is the right place to approach this, but we could try out different ideas based on the strudel peg grammar for the mini notation, which also contains some haskelly type syntax.

I wonder how much effort has already put into this idea, and if there are more concrete ideas on the syntax

For alternatives to "maxi notation", check out https://www.wordhippo.com/what-is/the-opposite-of/mini.html :)
Some of my "favorites"

• mega notation
• jumbo notation
• mondo notation
• a whale of a notation 🐳

[yaxu]

Yes it'd be great to make progress on this!

As I think I describe in that paper, a tricky bit is formalising sequences, and how they relate to patterns as functions of time, so sequences can be embedded in patterns (as with the mininotation in haskell) and vice-versa (as with embedding named patterns in the mininotation with ^) in a flexible way. I got some way towards sketching that out, but not as far as a working prototype. https://github.com/yaxu/remake/blob/main/src/Sound/Tidal2/Types.hs

I think it'd be difficult to get right in javascript without getting a prototype running in a more strongly typed language like Haskell first. I have in mind to look into it this summer.

[omicron321]

Macro Notation or Tidal Macro Notation ?
There exists Music Macro Language (Music Markup Language).

A DSL without $ and % but with >> (à la glicol) would eventually help reading notation and direction of execution flow.

[felixroos]

Related https://github.com/polymorphicengine/minilambda/

[neo451]

@felixroos @yaxu
hi, I recently did some experiments in my lua port, and got some progress on this, did a little writing here: https://github.com/noearc/modal/wiki
most stuff described is working, including embeding named patterns.

I am basically converting "maxi notation" strings into lua ASTs(see metalua-AST) and turning them valid lua source strings (even bytecode is possible after some research) and loading them on the fly. The parser is basically my mini-notation one added with some function calling syntax.
the implementation is mostly here: https://github.com/noearc/modal/blob/main/src/core/maxi.lua

lua is maybe not the best language to design a new language in, but it could be quick and easy to explore in it.

[yaxu]

Oh have only just seen this, nice work! Is it fun to use?

[yaxu]

Just wondering how a javascript-based mondo notation would look

sound([bd sd]).every(<3 4>, fast([3 4]))

sound([bd <sd bd>.every(3, fast(2))])

sound([bd - cp [- cp]]).chop(<8 4>)
  .[crush(<3 4>)|hurry(0.5)]
  .jux(<rev|press|iter(4)>)

[yaxu]

Compare and contrast:

sound([bd - cp [- cp]])
  .chop(<8 4>)
  .[crush(<3 4>)|hurry(0.5)]
  .jux(<rev|press|iter(4)>)

jux [rev|press|iter 4]
  $ chop <8 4> 
  $ sound [bd - cp [- cp]] 
  # [crush <3 4>|hurry 0.5]

Which one's easier? more parenthesis, vs more operators..

I guess we could make the () optional when wrapping around brackets..

sound [bd - cp [- cp]]
  .chop <8 4>
  .[crush <3 4> | hurry(0.5)]
  .jux <rev|press|iter(4)>

[yaxu]

As @felixroos pointed out on discord, making () optional is problematic for functions with multiple arguments..

[yaxu]

One issue is whether to keep the world of functions separate from the world of sequences.. Where [] <> and {} denote sequences and () denotes functions. This was the maxinotation idea - fast 2 [bd (fast 2 [sd cp])]. This idea seems elegant, but works less well with js-style syntax because it already uses () to group function arguments together.

Instead we could continue the method chaining tradition:

• [bd [sd cp].fast(2)].fast(2)
• sound(bd - sd.fast(<2 4>) sd).every(3, rev fast(2))

In the above, comma is used to delimit function arguments, meaning we can't use it for stacking (unless the function is stack). Perhaps ; could be used for stacking

• sound(bd sd bd; cp mt)

There's also the long-running issue around lambdas. It would be nice to have this sort of thing:

• sound(bd sd).every(3, .speed(2))

But that's a bit ambiguous, e.g.:

• sound(bd sd).every(3, fast(2) .speed(2))

Is that trying to do function composition or make a pattern of functions?

[yaxu]

Probably latter.. But then would it be better to require explicit lambdas, e.g.

• sound(bd sd).every(3, .fast(2) .speed(2)) // (with . in front of fast)

We could then do without currying.. But curried functions are handy