"Repeat until" function

[daveyarwood]

Moved from #126.

Quoting @MillerMark from that issue:

Repeat Until allows you to repeat a sequence or a variable holding a note sequence until a particular marker or time is reached. It looks something like this:

# repeats until the lastNote marker is reached:
repeat [o4 a4 b c] until %lastNote

# repeats for 30 beats:
repeat [o4 a4 b c] until 30

# repeats for 500 milliseconds:
repeat [o4 a4 b c] until 500ms

The sequence would be repeated until the specified time marker is reached. If the sequence is midway through, that sequence would finish (continue playing until its end). To truncate (immediately stop playing) a sequence when the time marker is reached, we could use the "!" character to indicate a hard stop:

# repeats until the lastNote marker is reached:
repeat [o4 a4 b c] until %lastNote!

# repeats for 30 beats:
repeat [o4 a4 b c] until 30!

# repeats for 500 milliseconds:
repeat [o4 a4 b c] until 500ms!

He also proposed a built-in @endOfScore marker, which would allow us to repeat musical phrases until the end of a score.

[daveyarwood]

We should consider whether this should be implemented as an alda.lisp (inline Clojure code) function rather than as a new operator. This is an overall design goal of mine.

[daveyarwood]

I'd love to implement this at some point, but it needs some more thought in design.

Jotting down some initial thoughts here:

I think a loop-until function could be implemented in alda.lisp, usage might look something like:

foo = a8 b > c+ d e

piano:
  (loop-until "someMarker"
    (get-variable :foo))

But there would be some trouble there, due to the way Alda evaluates a score. For one thing, someMarker would need to have already been defined previously in the score, which might be annoying for a lot of use cases. Like, imagine if you wanted to write a score where the piano starts vamping on those 5 notes until some marker that you will define later in the score. Then, further down in the score, you define another instrument, say an upright bass, to do some solo stuff while the piano vamps, and then place a marker when the solo is done so that the piano vamp stops. That would not be possible, unless you defined the bass part above the piano part.

That's not even considering how we might have an event sequence "loop until the score ends." Ideally we could add a special :end marker that will always correspond to the end of the score, but the problem is that Alda evaluates scores from top to bottom and updates the current state of the score. At the point in time where you say you want something to loop until the "end" of the score, the "end" of the score is much earlier than it's going to be later in the score, after more notes have been added.

I guess the overall problem here can be summarized as: the Alda score evaluator is a single thread that parses and evaluates tokens of Alda code from top to bottom and builds up the score events as it goes. The whole thing is very much inspired by the concept of immutability in functional programming.

Meanwhile, someone who wants to do music composition in a live-coding context will be expecting each instrument part (or even just a sample of an instrument to use as a layer) to be its own "thread," looping in tempo sync with all the other parts. The live-coder will want to alter the way the threads behave as the piece is being performed. This is more analogous to mutability and imperative programming. Which is not necessarily a bad thing, just a different way to program. I think in this case, it's actually a more appropriate model when thinking about live-coding.

But this is fundamentally not how Alda works today. I sort of wonder if it would be feasible to convert the underlying mechanism into a new one that lends itself better toward live-coding and performance contexts, where you can have ideas looping and interacting with the state of a context that can change in real-time. If it worked like that, then you could actually start playing an Alda score, and then start feeding it additional lines of input to "patch" the score while it's playing -- changing the notes in a variable that's being looped, etc.

I find this idea really compelling. Will have to explore it when I have time.

At the moment, I'm thinking that this will be such a big change that I'd like to plan it for a new major version release, e.g. 2.0.0 after 1.0.0 has stabilized. But there's no reason we can't start experimenting now.