Wow, I totally butchered the rhythms in the first line! I thought it sounded outlandish, even for Debussy... Sounds much better now.
I added the 2nd and 3rd stanzas, made a bunch of miscellaneous fixes, and added some dynamics.
= is being used now for variable definition, which makes '=' as a natural syntax a little confusing.
_ can also be used in variable names, but variable names must start with at least two letters, so there is no conflict, grammar-wise.
With the changes I just made to alda.lisp, score evaluation is now a self-contained process. This allows us to be flexible in the way we use alda.now.
I've adjusted things so that the `play!` function by default will start up a new score and evaluate the events in its body within that context. It actually uses *current-score* as the context, but when that's nil, it starts a new score and uses that.
Scores are represented as atoms referencing Alda score maps.
*current-score* can be manipulated via the `with-score` and `with-new-score` macros, which bind *current-score* to a particular score or a new score, respectively, and then both modify *current-score* and return the modified score.
There's also `play-score!`, which will play an entire score, given the score map or an atom referencing it.
Lots of changes and refactorings here. I think I might write a blog post about it.
To briefly summarize this commit:
- BEFORE:
- There were a bunch of top-level dynamic vars like *current-instruments* and *events* and a bunch of others.
- We were alter-var-root'ing and binding'ing things all over the place.
- Because of this, only one score evaluation context could exist at a time; loading a new score into a server, for example, would necessarily have to interact with or overrwrite any existing score evaluation context. One-off evaluation of a score (without affecting the current score in progress) was not possible.
- Score evaluation relied on mutable state over time as the score got evaluated. For example, evaluating (note (pitch :c)) would alter-var-root on *events* and *instruments* to update the state of those things.
- AFTER:
- No more top-level vars.
- A score is a map containing a bunch of data about the current state of the evaluation context. Because immutable data is awesome, the current state of a score can easily be stored in a symbol or an atom or be let-bound or whatever.
- This makes it easy to evaluate multiple scores (with different evaluation contexts) at the same time, and each score evaluation context is a totally isolated environment.
- This will make it possible for the server to parse, evaluate and play Alda scores in isolation from one another, solving many bugs and generally making life easier.
- Incidentally, fixed issue #199. Local attributes occurring at the same time as global attributes will now override the global attributes.
- alda.lisp event functions like `note` and `chord` no longer work via side effects. Instead, each event function returns a map containing all the necessary information about that event.
- The score function basically reduces through the events of the score, starting with a fresh score context map and updating it for each event in the score.
- There is a function called `continue` which will take a score context map and continue evaluating further events. This is what we're going to use to "update" a score a little at a time via the Alda REPL, server and command-line client.
- Because event functions no longer work via side effects, inline Clojure code will work a little differently. Basically, you'll just write code that returns one or more Alda events, instead of code that produces side effects and returns nil.
I had negative lookaheads like `!("[" | "]") events` in the rules for event sequences and cram expressions, but they weren't really doing anything (apart from disallowing event sequences/crams in the initial position) because the rule wasn't being used recursively.
I tried simply removing the negative lookaheads and it seems to work fine! ¯\_(ツ)_/¯
In the future, we will hopefully have a plug-in that will make writing percussion parts much nicer. Perhaps the plug-in could map ASCII characters to different percussion sounds, and then you could write your percussion parts using a drum tab-like syntax.
For now, we can at least make percussion available, and it can be used just like any other MIDI instrument.
This commit changes Alda's parsing process from using a single, monolithic grammar to parse an entire score in one pass, to parsing a score in several discrete steps, using a separate grammar/parser for each phase.
The perks of doing it this way:
- It will give us greater flexibility with syntax features. For example, this will make it a lot easier (maybe even possible to begin with) to implement inline variable definitions which terminate in a newline -- we can just parse them after comments and Clojure expressions, but before everything else.
- We can leverage more of Instaparse's built-in optimizations for parallelizing work. Each instrument part will be parsed concurrently, for example.
- Because we'll be feeding each parser smaller bodies of text, performance will improve significantly. I tested at least one score that took ~6 seconds to parse before, but now takes ~600-700 ms.
The downsides:
- There is no longer a single parse tree for an entire score.
- Parsing errors will be harder to understand from the stacktrace alone. Line/column numbers will no longer refer to the entire score file, but rather the small section of the score that is being parsed.
- We'll need to rewrite/rethink `parse-with-context`, which the Alda REPL uses to determine the context of a snippet of Alda code. Currently this works by doing a series of partial parses using the single alda.bnf grammar.
I think these are hardships worth enduring for the benefits we'll gain, especially in light of the poor performance we're dealing with with the current single-grammar system, and the need to pave the way forward for advanced syntactical features as the language's grammar grows in complexity.
