search

alda-lang / alda

A music programming language for musicians. :notes:
https://alda.io
Eclipse Public License 2.0
5.62k stars 289 forks source link

Alda REPL: "Play right away" offset calculation doesn't work with voices #415

Open daveyarwood opened 2 years ago

daveyarwood commented 2 years ago

🐞 Bug report 🐞

Description

In the Alda REPL use case, the user is appending additional events to the score, and as they're doing that, we want to play the new notes immediately, not wait until they would come up in the score. There shouldn't be any delay between entering a line of code in the REPL and hearing it.

To support this use case, we play some tricks in the note scheduling code, where the caller can pass in a map of "sync offsets" for each part, and we will subtract the offset for each part from all of its notes. As a result, we end up with notes that would be played right away, not however far into the score they would be if this were an Alda score file and not a REPL session.

This has been working great, but I just noticed that for some reason, it doesn't seem to work if you use voices.

Steps to Reproduce

  1. Start a REPL session (alda repl)
  2. Type in piano: V1: o4 c d e V2: o5 c d e and press Enter.
  3. Press the Up arrow to recall the previous line and press Enter to run it again.
  4. Repeat step 3 several times.

Expected Behavior

Every time you enter this line of code in the REPL, you hear the result immediately.

Actual Behavior

The first time, you hear the result immediately.

The second time, the result is delayed by 3 beats.

The third time, the result is delayed by 6 beats, etc.

Environment

Operating system and version: Ubuntu 20.04

Alda version:

$ alda version
alda 2.2.1
$ alda-player info
alda-player 2.2.1
log path: /home/dave/.cache/alda/logs

Health check:

$ alda doctor
(all passing)

Logs: not relevant here

daveyarwood commented 2 years ago

My hunch is that this has something to do with the way Part instances are cloned in the voices implementation.

On this line could maybe try using Part.origin instead of Part. May need to make origin public, except that that might have unintended consequences, but we could add an Origin() getter method to get around that. Assuming that I'm even on the right track with this.

(In the "sync offsets" we are passing into the transmitter, I see that we are using part.origin already, which I think is correct.)