olofson
commented
10 years ago Maybe we could implement this as a voice unit that accepts A2_TSTRING object handles and parses the strings at run time?
This unit would only ever send events to subvoices, so it's not an issue that units (currently; see #51) cannot send timestamped events to each other.
MML is a widely known and relatively effective way of entering music as text. (Unlike coding it in A2S, which wasn't really designed for that at all...)
The most basic implementation would simply translate monophonic MML into the same type of VM code we're currently using for controlling subvoices. However, that means an MML statement can control only a single subvoice, and completely occupies the host voice while playing.
We could work around that by actually spawning a subvoice for each MML statement, playing the notes on a subvoice of its own, leaving the host voice free to do other things - like playing other MML statements. This has the problem of detaching MML timing from the host voice, forcing the author to rely on explicit delay statements if the program is to do anything more than just starting a bunch of MML statements and then end.
Another option would be to make the MML statement itself polyphonic and/or support actual polyphonic MML. (Syntax?) That would result in VM code being generated for all channels in one go, interleaving the code as needed, so we can inline it directly in the host voice and get synchronized timing as well as polyphony.