can I see debug messages while the player is running?

[holtzermann17]

🔧 Feature request 🔧

Description

E.g., on line 375 of Parser.kt it occurred to me that I could add this:

          log.warn { "Note number: ${noteNumber}" }

However, I'm not sure where these logs can be viewed. In short, I can run a client, server, and player all separately — but how can I control which player the server connects to?

Examples

I'd like to be able to include debug messages in my scores; just echoing the notes that are being played (in text form) would be start.

Motivation

This would be directly useful, but also potentially interesting as the start of a way to send signals to downstream programs!

Alternatives

Not sure.

[daveyarwood]

Hi, thanks for the issue!

Player logs are written into files in a directory whose location varies depending on your OS. To see the location, run alda-player info.

Another thing you can do is run a player process in the foreground like this:

alda-player -v run

-v is for verbose mode. There is also a very verbose mode, -vv.

You can also include -p 12345 to run the player process on a specific port. (By default, a random open port is used.)

When running a player process in the foreground like this, the logs are printed to stdout.

The other piece of the puzzle is to ensure that that player is used, so that you can test what you wanted to test. There are two ways you can do this: one is to specify the port that you started the player on (if you didn't specify a port, you can see what port is used in the player logs):

alda play -p 12345 -c "piano: c8 d e f g a"

The other way is to look at the player logs and note the three-letter ID at the beginning of each line. This is an automatically generated player ID that you can specify instead of the port:

alda play -p xxx -c "piano: c8 d e f g a"

Either way, note that the player process will automatically shut down at the end of the first "play" command it receives. This is by design, to help ensure that fresh players are used and stale players aren't left running forever. The player process will also shut itself down after a period of inactivity, for the same reason.

Does that help?

[daveyarwood]

I'd like to be able to include debug messages in my scores; just echoing the notes that are being played (in text form) would be start.

An old idea that I had, possibly related: https://github.com/alda-lang/alda/discussions/430

[holtzermann17]

Hi, thanks; for example, I can see the output from the existing log.trace { "${address} ${args}" } on line 223 of Parser.tk this way.

Potentially clarifying my initial question: I had been wondering about how to get player messages to appear alongside interactions on a REPL. Indeed, #430 would be an example feature of broader debugging suite, maybe adjusting the syntax there to (debug 'offset) and also accommodating (debug "message"). These could print out on the REPL rather than in the log we were talking about here.

[daveyarwood]

That's an interesting idea! I think it could be implemented in a way that would also allow us to do things like what @UlyssesZh was talking about in https://github.com/alda-lang/alda/discussions/451, where you could write an editor plugin that moves your cursor to the note in the score that was just played.

The thing that makes this challenging right now is that all of the communication is unidirectional from the client to the player. Aside from tailing logs, we don't have any way of receiving updates from player processes in real time. But we could add a separate stream of updates coming from the player, and build tooling to do all kinds of interesting things with that data, including debugging.

Because latency is important, and we're already using OSC for the client -> player communication, I think it would make sense for the player to broadcast OSC messages for this.

Hopefully there is some way to do this without a lot of performance overhead that would affect playback :thinking: I don't know off-hand that perf would be a problem, but it's something we should watch out for when implementing this.