Extend pattern language

[pdcawley]

The commit messages have most of what this is about. Basically it's to enabled dotted notes and shortened notes within the pattern language. For an example of what sort of thing it enables, try the following:

(:| pat-1 96 0 (play syn1 @1 (cosr (cosr 75 2 1/2) 1 1) (* 0.95 dur)) (g3 + a3 - b3 b3 c4 b3 a3 c4 b3 a3 g3 f#3 e3 | d3 |
g3 + a3 - b3 b3 c4 b3 a3 c4 b3 g3 g3 f#3 g3 | g3 |
d4 (c4 b3) a3 (a3 b3) c4 (b3 a3) g3 b3 a3 g3 f#3 g3 a3 | a3 |
d4 (c4 b3) a3 (a3 b3) c4 (b3 a3) g3 b3 a3 g3 g3 f#3 g3 | g3 |
bb3 (a3 g3) bb3 (a3 g3) f#3 g3 a3 | d3 e3 f#3 g3 a3 bb3 a3 g3
bb3 (a3 g3) bb3 (a3 g3) f#3 g3 a3 | d3 e3 f#3 g3 g3 f#3 g3 |))`

with a 180 bpm tempo

[benswift]

Hey, thanks for the contribution - things are a bit hectic here rn but I'll look at it asap.

[pdcawley]

No rush. Hope the jet lag isn’t hammering you too hard

[benswift]

yep, soz - still on the todo list (and climbing)

[benswift]

hey @pdcawley I've had a chance to have a look. cool! nice work getting it going, as you (now) know the guts of the pattern language stuff could do with some re-factoring.

My thoughts on this PR at the moment are:

1. I like the idea of having multiple "pluggable" pattern languages, so there'd be the default one, your abc one, etc.

2. we need a more disciplined way of defining the "special bindings" for use within the pattern languages (e.g. defining global functions for each note name as in this PR is just going to trip folks up who accidentally shadow/re-define those things, and then

3. I personally don't love the fact that symbols in the pattern list are 'eagerly' evaluated (so that e.g. you can't currently pass in symbols like i or v7 for use in chord functions through the pattern list), so it's worth thinking about how we want this to work as well (which relates to 2.)

Overall, I think the best way forward is

1. define a nicer "base representation" for a pattern, including full info about the values in the pattern list and the time that they should be eval'ed (can/should be verbose, not meant to be written by humans)

2. every different pattern language is therefore just a mapping from pattern->"base representation" (which includes local bindings for any relevant symbols, e.g. a, b, g)

3. there's a nice method for creating a new pattern language runner (like :>) from (2), and perhaps we could pre-bind a few by default (e.g. :> is the original, :abc> is the abc one, etc).

I think that's a more principled way to go forward. So I think I won't merge this just yet. I don't suppose you'd be interested in helping out with some of the above work? Obviously it's open source, so I have no coercive power, but the more the merrier with implementation, and I'm happy to help out as well.

Thoughts?

[benswift]

One more thing, in terms of not breaking the existing stuff, not many folks are using this at present, so as long as the examples in examples/sharedsystem all stay working then I think we're all good (and we can even modify them if necessary).

[pdcawley]

That sounds like a way forward, certainly; I think it should be possible to do a lot of the symbol interpretation by having a per-interpreter environment that can be passed as the second argument to eval, but I'm not entirely sure where that needs to happen. If it's not done pretty eagerly, it's hard to get the duration modifiers to work. Maybe that aspect of any pattern language needs to be eagerly interpreted, and have everything else be evaluated as late as possible.

I have time on my hands with the lock down, so I think I'll start by trying to encapsulate an :abc> interpreter, and break it down into a macro-like step that fiddles with an entire pattern and an environment that means the looper will do something like (eval play-form interpreter-env) for each event in the pattern.

[benswift]

Hey @pdcawley that sounds like a solid approach. The other idea I'd had (a bit less clean than using different environments) was basically to have the pattern eval machinery macroexpand a big (let ((c4 60)) ... with all the necessary let-bindings around each invocation of the pattern expression; so that each new "mini language" defines both a list of bindings (to be provided to the aforementioned let and a mapping function to map the input pattern to the internal "base representation").

But I must confess I haven't thought about it deeply, so whichever approach seems best would be welcome. The main criteria is that the "original" language still works, and (ideally) that the internals of the pattern language stuff are a bit more modular and easier to reason about and modify. So I think you're well placed to help with that :)

Re: the early/late eval, my preference is also for it to be late wherever possible, but in some cases it's going to have to be eager, and I think that's ok as well.