Possibility of supporting backward search

[UlyssesZh]

What I refer to by saying backward search is to seek the position in the Alda codes corresponding to a certain point in the music.

This is a natural demand. Music notation software (MuseScore, Overture, Sibelius, etc.) is mostly able to play the score while the user is able to see a cursor moving through the score indicating where in the score it is playing. As for Alda codes, a similar functionality is to backward search. While an Alda score is played, the text editor could select the texts that are being played.
(In most cases there are multiple elements being played at the same time, but it should not be a problem for text editors that support multiple selection (Sublime Text, Vim (with proper plugins).)

Here is an idea about how to implement this functionality.

1. Use alda parse to get all the data: at what time (offset) will a note be played.
2. Run alda play to play the score
3. Noting that there is a latency between the time when we run alda play and the time when the score starts to be actually played, there should be a callback for Alda to let other programmes know when the score is actually played.
4. The text editor start timing when Alda tells it that the score is played, while selecting texts according to the time and the data gotten from the first step.

To make this backward searching possible, Alda should be able to do the two things:

• In the output of alda parse, include the info about where a certain event is in the text (from which line and which column to which line and which column);
• While running alda play, call a callback to indicate when the score is actually played (the callback can be some command that we parse as an argument at command line; in the callback, for example, we can use kill command to send a signal (say, USR2) to notify the other program).

[daveyarwood]

Interesting idea!

One thought that occurred to me: starting a timer when the score is played seems like it might be error-prone, especially if you use alda stop to pause the playback, and then resume it again with alda play. Even without considering pausing and resuming playback, I think the timer approach is error-prone because under heavy CPU usage, there could be jitter in the playback, and the "source" (text editor, etc.) could easily become out of sync with the actual progress/status of the player process. So, it would be useful for the "source" to receive information from the player process about how far it is into the score.

The player process does have a notion of "current offset", that we could perhaps expose somehow. It doesn't exactly map 1-to-1 with the idea of "offset" in an Alda score, but maybe there are some tricks that we could play to get those two things to line up.