Forked from the comments of https://github.com/alda-lang/alda/issues/266#issuecomment-248302194

Since upgrading to rc41 from rc31, alda doesn't spawn workers on my windows machine:

λ alda up
[27713] Starting Alda server...
[27713] Server up ?
[27713] Starting worker processes...
[ this hangs, I waited for 5 minutes ]
^C

λ alda status
[27713] Server up (0/2 workers available)

Consider the following code:

piano:
piano "piano1":

piano: o4 c d e f g a b > c
piano1: o4 e f g a b > c d e

When played, it plays normally. However, if I switch the declaration of the instruments at the top

piano "piano1":
piano:

piano: o4 c d e f g a b > c
piano1: o4 e f g a b > c d e

piano1 does not start playing until piano has finished its melody. The order of the melodies at the bottom does not matter, so

piano "piano1":
piano:

piano1: o4 e f g a b > c d e
piano: o4 c d e f g a b > c

will play piano1 first and then play piano.

And if they're both named, there is no problem. both of the scores below play normally.

piano "piano1":
piano "piano2":

piano1: o4 c d e f g a b > c
piano2: o4 e f g a b > c d e

piano "piano2":
piano "piano1":

piano1: o4 c d e f g a b > c
piano2: o4 e f g a b > c d e

I am loosely aware of the ability, via clojurescript, to get clojure running in native javascript. If it's possible for the parser to be ported to javascript I would be happy to build the website that surrounds it and plug in the web audio API so folks can aldajam in the browser.

Any idea what would be involved in porting the parser to JS?

I noticed that variables were finally implemented in the latest release of alda. However with the new note spacing rules I find that writing is much more restrictive. Thus, I suggest a literal for variables; that way the note spacing rules can be more relaxed, however variables would still be clearly marked. A single quote literal '<variable>' is a possibility, as well as having something like a character before a variable '<variable> to indicate that it is one (similar to markers), however I would like to hear other suggestions.

A large handful of people have noted experiencing problems installing and running Alda in a Windows environment. #47 is a good example of an error that at least 2 other people have noted running into.

Open questions:

• Is it possible to run a standalone executable Boot script in Windows?

  The alda executable does start with #!/usr/bin/env boot. On OS X, I am able to run alda globally by making this file executable and copying it a directory in my $PATH. I am also able to run it by running boot ~/Code/alda/bin/alda. I can reproduce the "No such task (alda)" issue by cd-ing into ~/Code/alda/bin and trying to run boot alda, probably because Boot can't know if alda is supposed to be a task or a file. Clarifying that it's a file by running boot ./alda fixes it.

• Can a Windows user simply copy the alda executable script into a directory in their path and be able to run alda from any directory?

  Subquestion: Does a file need to be a .exe in order to be added to the path?

• Why doesn't running boot D:\path\to\alda (with boot.exe on the user's path) work?

  ... Does it work?

Would greatly appreciate any insight from Windows power users, or better yet, Windows users familiar with running Boot. I am a Windows n00b.

My primary motivation is to have a "Try It" area on the Alda website, similar to what you find on the Haskell website, where you can enter snippets of Alda code, press a "play" button and hear the result.

There was also a request (#391) for playable demos of the example code in the Alda documentation, which I think is a great idea.

I've been thinking about either compiling the Alda client (written in Go) to WebAssembly, or using GopherJS to compile it to JavaScript. That should allow us to parse Alda scores in the browser and hopefully send OSC messages.

We'll also need to implement the player process (written in Kotlin) in the browser. It looks like it's possible to compile Kotlin to JavaScript, so maybe that will help. Although, I used Java inter-op quite heavily, both to use the JVM MIDI synthesizer/sequencer and to do sophisticated things with concurrency. So, I suspect that it might be challenging to try to reuse the same code base to generate a player process in JS. We might end up needing to write a port in JavaScript from scratch instead, which wouldn't be the end of the world. Ideally, we could use the same code base, though, so that we can avoid the two implementations drifting apart over time.

I tried the latest version of alda today (alda update), and found that running alda up maxed out my machine's CPU and basically locked it up with loadaverages over 80(!).

Here are the offending threads:

What's happened in the last 10 days? My machine is very powerful, and more importantly didn't used to have this problem.

My version:

$ alda repl
Sep 16, 2016 1:25:00 PM com.jsyn.engine.SynthesisEngine start
INFO: Pure Java JSyn from www.softsynth.com, rate = 44100, RT, V16.7.3 (build 457, 2014-12-25)
Preparing MIDI system... done.

 █████╗ ██╗     ██████╗  █████╗ 
██╔══██╗██║     ██╔══██╗██╔══██╗
███████║██║     ██║  ██║███████║
██╔══██║██║     ██║  ██║██╔══██║
██║  ██║███████╗██████╔╝██║  ██║
╚═╝  ╚═╝╚══════╝╚═════╝ ╚═╝  ╚═╝

            v1.0.0-rc38
         repl session

My machine:

$ uname -a
Linux T420 4.7.2-1-ARCH #1 SMP PREEMPT Sat Aug 20 23:02:56 CEST 2016 x86_64 GNU/Linux

My jvm:

$ java -version
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

I get pretty much immediate responses from the server* after first running it, but after leaving the server running for a while (e.g. if I leave my computer and come back hours later), it may take several seconds or more before I hear anything. Restarting the server fixes it.

*meaning, if I run alda play -r -c 'piano: c', I hear the note immediately

No idea what the issue is at this point, but figured I would report it in case anyone has any ideas.

Closes #94.

This introduces a major change to alda.parser -- anything between parentheses is now interpreted as a Clojure expression and evaluated with the help of a custom reader that will attempt to resolve symbols in the alda.lisp namespace whenever possible. There is also some regex hackery that allows things like (volume 50, tempo 120) to still work by splitting on commas and semicolons (intelligently*) and turning them into separate S-expressions like (do (volume 50) (tempo 120)).

*Commas and semicolons inside strings and as character literals still function as they normally do in Clojure.

As a side effect of this, (* the old (and not so great) long comment syntax *) had to be deprecated. R.I.P.

For full backwards compatibility, I've also extended the defattribute macro so that it defines more functions for use in the alda.lisp namespace (and by extension, in Alda code) -- you can now call any alias of an attribute as a function (e.g. (vol 50) instead of having to do (set-attribute :vol 50)), and you can set global attributes by appending a ! after the function name (e.g. (vol! 50) instead of (global-attribute :vol 50))

I also happened to notice a bug with the :play function not fully resetting instruments' attributes (octave, volume, etc.) before playing a score from the beginning, leading to inconsistent playback. I'm including a fix for that in this PR as well.

Not quite done with this yet, but perhaps ready for feedback.

There are some performance-oriented things here, like making some functions lazy, a lower-overhead trick than (doall (pmap ..)) and using transducers in some places.

Will be back this evening to finish this off - supporting labels, typing in with CLI and REPL commands, and adding tests

I added boot.properties before Clojure 1.7.0 became the default Clojure version in Boot 2.2.0, as a way of enforcing that Clojure 1.7.0 be used when running Alda boot tasks, which used to be how you would run alda's play, parse and repl tasks, pre-alda.cli (i.e. instead of using the alda executable, you would cd into the Alda project directory and run boot play --file /some/file.alda, or boot alda-repl, etc.)

Since then, the latest versions of Boot (since 2.2.0) have made Clojure 1.7.0 the default BOOT_CLOJURE_VERSION, and the usage instructions for Alda has moved from cloning the repo and running Boot tasks to copying a provided executable Boot script (bin/alda) to your $PATH and using the alda command as an entrypoint into the tasks defined in the alda.cli namespace.

Bearing this in mind, does it make sense for us to still have a boot.properties file? With Boot steadily evolving and improving, I'm not sure I like the idea of pinning the Alda project to a specific version of Boot, when really all we want to enforce is Clojure 1.7.0 as a dependency.

Patch to fix issue #421 . Checks the ending duration of what is sent to the client matches the PartOffset in the Score object. If there is a mismatch (as in the case with a trailing rest), extra duration is appended to the last note.

🐞 Bug report 🐞

Description

Fresh download, new user. After problems with the 101 tutorial (alda repl), I tried alda doctor. It errs out at "Export score as MIDI" after hanging a couple of seconds, and after it errs out, I hear an upward broken major chord and see a persisting java process of alda-player.

Steps to Reproduce

1. Download current alda and alda-player, make executable and put on PATH
2. Execute alda doctor

I am using Gentoo Linux an a laptop with an external soundcard (USB) that does not seem to be used. I have both Pipewire and ALSA installed.

Expected Behavior

I would hope that the self-test passes. Furthermore, I would not expect remaining Java background processes after exit of the command I launched.

Actual Behavior

It errs out at "Export score as MIDI" after hanging a couple of seconds, and after it errs out, I hear an upward broken major chord and see a persisting java process of alda-player.

Environment

Operating system and version: Gentoo Linux, rolling.

Alda version:

$ alda version
alda 2.2.3

$ alda-player info
alda-player 2.2.3
log path: /home/seb/.cache/alda/logs

Health check:

$ alda doctor
OK  Parse source code
OK  Generate score model
OK  Ensure that there are no stale player processes
OK  Find an open port
OK  Send and receive OSC messages
OK  Locate alda-player executable on PATH
OK  Check alda-player version
OK  Spawn a player process
OK  Ping player process
OK  Play score
ERR Export score as MIDI

---

Oops! Something went wrong:
  open /tmp/alda-doctor1917232005/1666820313.mid: no such file or directory

This might be a bug. For help, consider filing an issue at:
  https://github.com/alda-lang/alda/issues/new/choose

Or come chat with us on Slack:
  https://slack.alda.io

Logs:

gip INFO  2022-10-26 23:38:33 StateManager.cleanUpStaleStateFiles:72 - Cleaning up stale files in /home/seb/.cache/alda/state/players...
gip INFO  2022-10-26 23:38:33 StateManager.cleanUpStaleStateFiles:72 - Cleaning up stale files in /home/seb/.cache/alda/state/repl-servers...
gip INFO  2022-10-26 23:38:33 Main.run:77 - Starting receiver, listening on port 37209...
gip INFO  2022-10-26 23:38:54 MidiEngine.<init>:276 - Initializing MIDI sequencer...
gip INFO  2022-10-26 23:38:54 MidiEngine.<init>:281 - Initializing MIDI synthesizer...
gip INFO  2022-10-26 23:38:56 Main.run:90 - Starting player...
gip DEBUG 2022-10-26 23:38:56 Parser.parse:238 - received ping
gip DEBUG 2022-10-26 23:38:56 Player.invoke:346 - TRACK 1: startOffset is 0
gip DEBUG 2022-10-26 23:38:56 Player.invoke:349 - eraBefore: 0; eraAfter: 0
gip DEBUG 2022-10-26 23:38:57 MidiEngine.meta:334 - Received Set Tempo meta event
gip DEBUG 2022-10-26 23:38:59 MidiEngine.meta:291 - Received CONTINUE meta event
gip DEBUG 2022-10-26 23:39:00 MidiEngine.meta:291 - Received CONTINUE meta event
gip DEBUG 2022-10-26 23:39:01 MidiEngine.meta:291 - Received CONTINUE meta event
gip DEBUG 2022-10-26 23:39:02 MidiEngine.meta:291 - Received CONTINUE meta event
gip DEBUG 2022-10-26 23:39:03 MidiEngine.meta:291 - Received CONTINUE meta event

Afterwards:

$ ps aux | grep alda
seb      20347 10.3  0.6 4566324 106200 pts/2  Sl   23:38   0:02 /usr/lib64/icedtea8/bin/java -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -Xmx1024m -Xms256m -DlogPath=tmplog -jar /home/seb/bin/alda-player -v run -p 37209
seb      20387  0.0  0.0   7648  2284 pts/2    S+   23:38   0:00 grep --colour=auto alda

🐞 Bug report 🐞

Description

@litan on Alda Slack observed that if you run the following command twice in succession:

alda repl \
  --client \
  --port 43009 \
  --message '{"op": "eval-and-play", "code": "percussion: o2 (tempo 240) c4 r4 c4 r4 | c4 r4 c4 r4 | c4 r4 c4 r4 | c4 r4 d4 r4"}'

It appends the two together as expected, however, the r4 at the end gets stripped off, so the c4 at the beginning of the second command ends up happening a quarter note too soon.

I was also able to reproduce this in an interactive Alda REPL session.

Steps to Reproduce

1. Run alda repl to start a REPL session.
2. Enter percussion: o2 (tempo 240) c4 r4 c4 r4 | c4 r4 c4 r4 | c4 r4 c4 r4 | c4 r4 d4 r4 and press Enter.
3. Before that line finishes playing, press Up arrow, Enter to enter the same line again.

Expected Behavior

The notes you hear are all spaced apart by quarter note rests.

Actual Behavior

It sounds like the r4 quarter note rest at the end of the first line is omitted, and there is a "hiccup" where the second line starts a quarter note too early.

Environment

Operating system and version: Ubuntu 20.04

Alda version: 2.2.3

Reference Issues/PRs

Addresses #405

What does this implement/fix? Explain your changes.

• Changed the color library for client to support windows by using the "github.com/gookit/color" library
• Changed the readline library for client to support windows and prevent background changes, replaced with "github.com/peterh/liner"
• Added tempfile ".alda_history" in temp directory for handling previous inputs, and reverseSearch added.

TODO:

• need to connect zerolog with the new liner library to handle Stderrs
• need to test multiLine mode, and to understand how it works ... to make playing instruments easier.

🐞 Bug report 🐞

Description

Player processes are supposed to outlive the execution of the Alda client, and they generally do, except, for some reason, in the case of running an Alda REPL in "server only" mode.

Steps to Reproduce

1. In a separate terminal, monitor the state of the player processes by running watch alda ps.
2. Start from a clean state by running alda shutdown to shut down all current player processes.
3. Run alda repl -s to start a REPL server.
4. Interrupt the process.

Expected Behavior

• The REPL server process disappears from the alda ps output.
• The player processes remain alive and continue to be present in the alda ps output.

Actual Behavior

All of the processes die and disappear from the alda ps output.

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)

🐞 Bug report 🐞

Description

When starting an Alda REPL session, the REPL server finds an available player process (i.e. one in the "ready" state) and "claims" it by sending it a ping message. This puts the player process into the "active" state, which makes Alda more eager to spawn new player processes in order to have them readily available.

This works reliably, but it seems to be a little too reliable in that, for some reason, two player processes seem to go from "ready" to "active" when the REPL server starts.

Steps to Reproduce

1. In a separate terminal, monitor the state of the player processes by running watch alda ps.
2. Start from a clean state by running alda shutdown to shut down all current player processes.
3. Run alda -v2 repl to start a REPL session in verbose mode.
4. Exit the session and start a new one.
5. Repeat step 4.

Expected Behavior

Each time a REPL session is started, only 1 of the players in the "ready" state goes into the "active" state.

Alda spawns more player processes as needed, but it shouldn't need to do that too much, because only one process becomes unavailable for each REPL session.

Actual Behavior

The first time I start a REPL server session, I see 5 players in the "ready" state and 1 player in the "active" state. The REPL server output shows that it is using the 1 player in the "active" state.

When I exit that session and start another one, 2 of the players that were in the "ready" state go into the "active" state. One of them is the one that this new REPL session is using. We are now down to 3 players in the "ready" state.

If I keep going, exiting and starting new REPL sessions, more and more player processes are spawned to ensure that there are always player processes available in the "ready" state.

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)