daveyarwood
commented
3 years ago Hi @UlyssesZh - I'm sorry that I caught you off-guard with this change!
This sort of client/server relationship is still possible in Alda 2, but the details have changed a little.
Alda 1 had a thin client that did none of the work. The server is doing everything, including parsing the source code, evaluating it into a score and doing all of the playback.
In Alda 2, the client does everything except for playback. Playback is handled by "player" processes that the client spawns in the background.
However, in Alda 2, we have also given the Alda REPL networking capabilities. You can run an Alda server with alda repl --server (starts a server only), or simply alda repl (starts both a server and a client session connected to it). Then, you can use the Alda CLI to either send low-level messages to the server, or to start an Alda REPL session connected to that server. This works even if the server is on another machine, in a VM, etc.
I've adjusted the guide to implementing an Alda library to account for this new architecture. Have a look at this part, in particular. I'm curious if that is helpful for getting your workflow up and running with Alda 2.
Alda 2 seems to have dropped the support for the
--hostoption in command line. When I was using Alda 1, I heavily used the--hostoption. I used to use a virtual Linux machine on my Windows device so that I could develop alda-rb in a Linux environment. However, playing audio in the virtual machine proved to be a bad experience. Fortunately, I found a workaround that I could run the Alda server in Windows with--host 0.0.0.0to make the server open to other devices in the network. In this way, I could let the Alda client in Linux to utilize the Alda server in Windows to play the audio. However, when I wanted to start continuing developing alda-rb to make it suitable for Alda 2, I found that the--hostoption seems to have been dropped, so I felt lost.