Score debugging function in alda.lisp

[daveyarwood]

When working on an Alda score with multiple parts, you can sometimes run into problems where you accidentally make a note in one part slightly longer or shorter than you think it is, leading to timing issues between the two parts.

To assist in debugging this issues, it might be beneficial if we had an alda.lisp function that, when called, prints out the current offset of the current instrument(s).

e.g. something like:

piano: c8 d e f
bassoon: c8 d e

piano/bassoon: (debug-offset)

piano: g a b > c
bassoon: g a b > c

The above score might print something like:

piano-L5S9Z: 1000ms
bassoon-2wKf3: 750ms

Which would make it obvious that the bassoon part is ahead of the piano by 250 ms, and suggest that there's a timing issue on the previous line.

[daveyarwood]

debug-offset could be implemented as a scheduled function.

Incidentally, I've been thinking about extending the usefulness of scheduled functions by allowing them to take an optional argument that is the context of the current score/instrument. If we added this ability to scheduled functions, then debug-offset could perhaps be implemented something like this:

(defn debug-offset []
  (schedule (fn [{:keys [score instrument]}]
              (let [{:keys [id current-offset]} instrument]
                (println (format "%s: %dms" id (:offset current-offset)))))))

EDIT 6/22/18: Scheduled functions will be removed soon -- see alda-lang/alda-core#65. However, I think we can do something similar to this without scheduled functions.

[elydpg]

Wait; each instrument has its own offset?

[daveyarwood]

Yes. For example, in the following score:

oboe: c c c c c c c c c c c
bassoon: c

At the end of the score, the oboe has an offset of 5500 ms (i.e. it's 5500 ms into the score) and the bassoon has an offset of 500 ms.

[daveyarwood]

You can think of the offset as "how far into the score the next note that instrument plays will be."