Why alda-player has an expiry ? And Why Shutdown alda-player when finish play a *.alda file ?

[yueyoum]

Q1: Why alda-player has an expiry and will stop its self ?

I run a player process by

$ alda-player -v run -p 9909
uwg INFO  2024-03-23 11:31:31 StateManager.cleanUpStaleStateFiles:88 - Cleaning up stale files in C:\Use
rs\wang\AppData\Local\alda\cache\state\players...
uwg INFO  2024-03-23 11:31:31 StateManager.cleanUpStaleStateFiles:88 - Cleaning up stale files in C:\Use
rs\wang\AppData\Local\alda\cache\state\repl-servers...
uwg DEBUG 2024-03-23 11:31:31 StateManager.cleanUpStaleStateFiles:107 - Deleting empty directory C:\User
s\wang\AppData\Local\alda\cache\state\repl-servers
uwg INFO  2024-03-23 11:31:31 Main.run:77 - Starting receiver, listening on port 9909...
uwg INFO  2024-03-23 11:31:31 MidiEngine.<init>:276 - Initializing MIDI sequencer...
uwg INFO  2024-03-23 11:31:31 MidiEngine.<init>:281 - Initializing MIDI synthesizer...
uwg INFO  2024-03-23 11:31:35 Main.run:90 - Starting player...

Then alda ps show the player processes:

$ alda ps
id      port    state   expiry  type    pid
uwg     9909    ready   5 minutes from now      player  1936

I noticed there has a expiry columu

5 minutes later

the alda player process will exit its self

uwg INFO  2024-03-23 11:37:27 Main.run:104 - Shutting down due to inactivity.
uwg INFO  2024-03-23 11:37:27 Main.invoke:95 - Stopping receiver...

---

Q2: Why shutdown alda-player when finish play a *.alda file ?

$ alda play -f test.alda -p 9909

the alda-player process show this log and exit its self

fqc DEBUG 2024-03-23 11:41:27 MidiEngine._init_$lambda$5:291 - Received CONTINUE meta event
fqc DEBUG 2024-03-23 11:41:27 MidiEngine._init_$lambda$5:321 - Received SHUTDOWN meta event
fqc INFO  2024-03-23 11:41:27 Main.invoke:95 - Stopping receiver...

Why this?

I wanna a long life time running alda-player process, like a background service

I can run many times of alda play -p 9909

[daveyarwood]

The alda client manages player processes in the background, and the player processes ensure that they won't keep running and using up resources when they aren't needed anymore. The idea is that a player process is responsible for playing one score and then shutting itself down.

In normal use of Alda, you should never need to start a player process yourself via alda-player. Simply run commands like alda play -c 'piano: c d e' and alda will spawn player processes as needed to play your scores. The client also sends a "shutdown" message to the player process to schedule a shutdown immediately after the score is finished playing.

[yueyoum]

Yes. I understand and totally agree your design:

1. keep it simple. (just run alda play or alda repl , it will spawn player process automatically)
2. gool computer resources management (shutdown when not using)

BUT in my usecase:

1. a mini pc as a dedicated player server. with a professional HiFi system attached.
2. I use a laptop to run alda client ( alda play -f xxx -p )

this usecase has two problems right now :

1. alda only support -p port argument, which means, the client and server process must running in same computer.
2. the alda-player, server process will exit its self

Can alda add two feature for support this usecase

1. add an argument (--host , or --listen, or --ip ) for specific the server listen address, and client connect target address
2. add an argument for server process running forever

example:

on server pc:

alda-player run --host 0.0.0.0 --port 9999 --forever

on client pc

alda play -f xxx --host 192.168.1.2 --port 9999

with this feature, I can run a cronjob in linux system, to make HiFi pc play alda songs

If you agree add this feature, I will do this and submit a pull request that you can review the code.

[daveyarwood]

Player processes are not intended to be long-lived, and you'll run into trouble if you try to use the same player process to play multiple scores. Once a player has played a score, it has that MIDI sequence "loaded" into its internal sequencer, and you could think of it as being in a "dirty" state.

What you're describing is a little involved, but it's actually already possible without needing to make any changes to Alda. Alda's REPL has a client/server architecture, which allows you to run a server on one machine, and send over the code you want to play from another machine.

Ordinarily, when you run alda repl, it starts a REPL server in the background, and it presents you with a REPL client session in the foreground. In the client session, you can enter code, as well as other commands, such as :new to clear out the REPL server state and initialize a new score. That's all assuming that you want to run everything in one terminal window.

But you can also run an Alda REPL server and client separate from each other, even on different machines. (See alda repl --help for options and examples.)

To start just a REPL server, on a specific port, you can run:

alda repl --server --port 9999

You can then use alda repl --host 1.2.3.4 --port 9999 --message "..." to send messages to the REPL server. A message is a JSON object with an operation and other data. (There is comprehensive documentation about this API here, if you're curious.)

To play a string of Alda code, you can run a command like this on another machine:

alda repl \
  --host 192.168.1.2 \
  --port 36521 \
  --message '{"op": "eval-and-play", "code": "piano: c d e"}'

There is not an "eval-and-play-filecommand (i.e. something analogous toalda play --file ..., because of the possibility that the client and server could be running on different hosts. So you would need to send the entire score through as a string in the code` field, and make sure you properly escape double quotes, etc. One way to do this is to use the JSON utility jo, which allows you to insert content from a file, and automatically escapes characters like double quotes:

cat /tmp/quotes.txt 
#=> This is a string with "quotes"

jo normal=string file_contents=@/tmp/quotes.txt
#=> {"normal":"string","file_contents":"This is a string with \"quotes\""}

# Read an Alda source file (this one happens to contain double quotes) and
# insert its contents into the "code" field in the JSON
alda repl \
  --host 192.168.1.2 \
  --port 36521 \
  --message "$(jo op="eval-and-play" code=@/home/dave/code/alda/examples/alternate-endings.alda)"

You should be aware that this approach has the same problem as the problem you would have if there were an option to run the same Alda player process "forever" and reuse it to play different scores. The REPL server builds up state over time, so after you use it to play one score, it will interpret any subsequent scores within the context of that original score, which could lead to scores sounding subtly different/wrong.

To solve that problem, you could run the following command to clear out the previous score state and ensure that your next score will be played with a fresh context:

alda repl \
  --host 192.168.1.2 \
  --port 9999 \
  --message '{"op": "new-score"}'

Note that under the hood, the Alda REPL server maintains a small pool of player processes and constantly keeps them alive. When you issue the "new-score" command, it kills the player process that it was using for the previous score and selects a new player from the pool. So it really works almost exactly like alda play. But the difference is that the Alda REPL server has an API that is designed for the kind of thing you're doing - networking multiple computers together and controlling playback on one of them.

[daveyarwood]

As an alternative solution, you could have your client machine connect via SSH, transfer the score file over, and execute alda play -f /path/to/the/file.alda on the server machine. That might actually be a better solution for your simple use case of remotely playing Alda scores.

You could do something like this:

scp my-score.alda 192.168.1.2:/tmp/my-score.alda
ssh 192.168.1.2 "alda play -f /tmp/my-score.alda"

[yueyoum]

Thank you for your patience.

I think you have fixed my trouble.

Once a player has played a score, it has that MIDI sequence "loaded" into its internal sequencer,

I'm lack of MIDI technology. I don't know MIDI player process has this behavior . ( Is this a limitation ? )

So, It looks like a player process ONLY for one *.alda file is a simplest solution .

BUT I still have other trouble, help me in the new question

[daveyarwood]

It's not really a limitation of MIDI. I think if we wanted to, we could throw away the sequence and initialize a new one. But the player processes have other state, and I designed them to be disposed after playing one score, just to avoid unexpected issues with playback.

[yueyoum]

By the way,

If the alda-player process running a thread pool,

one thread - one midi sequence / midi state

the main thread do the following loop:

1. accept client request
2. get or create a fresh thread
3. dispatch the reqeust to that thread. and that thread do the actual work.
4. destory that thread when work finished

MIDI State located in thread, NOT entire process

SO ONLY thread need to shutdown, NOT the process,

Is this will be a forever running process ?