Related necessary REPL changes:
* In normal REPL usage, suppress tempo messages because they complicate things
and we don't need them.
* When exporting a score via the REPL, we reload the score into a fresh player
process first, then we _do_ include the tempo messages because we need the
exported MIDI to contain tempo messages.
With the previous settings, I was finding it too easy during regular REPL usage
to end up with no players available and have to wait for a new one to spawn.
Increasing the number of desired players from 2 to 3 also helps a lot to ensure
that enough players are available when playing a bunch of score files in rapid
succession with `alda play`. With these new settings, I was able to go through
all of the example scores in the repo one by one and play them (overlapping)
with `alda play` and it worked out great!
Emitter always sounded weird to me the way I've been using it. I looked up the
difference in the definitions and Transmit definitely makes more sense, not to
mention it sounds better.
There's lots of work yet to be done here, this is just the basic scaffolding,
including:
* readline emulation / history file support, via a good library
* basic client/server interaction, all within a single process
* the REPL server keeps track of input and a score object and uses them to apply
successive updates within the context of the existing score
Not yet implemented:
* The various REPL commands, for parity with v1.
* Client/server communication via some sort of network protocol (maybe nREPL?)
* Better player management (see comments in the code)
* Command line options to optionally start client only or server only.
