Nowadays audio synths and effects are most commonly represented as interactive spaghetti diagrams connecting basic DSP blocks together into directed graphs determining the signal flow. To make a good audio programming language, the question then becomes: is there a nice textual representation for this kind of graph? And Forth is a great answer to that question.
I had so much fun with Sporth that I ported it to the browser and made an online playground for it: https://audiomasher.org/ with some examples: https://audiomasher.org/browse and a tutorial: https://audiomasher.org/learn
You kind learn more about Sporth here: https://pbat.ch/proj/sporth.html and the code can be downloaded here: https://www.github.com/paulbatchelor/sporth.git
Little bit of feedback: it only plays when the tab has focus - is that a browser thing, or something could theoretically be overridden?
EDIT: Opening the tab in a separate window keeps the sound running even when alt-tabbing away
EDIT2: The interactive cook book environment are missing a previous and next link at the top/end of each chapter, clicking back and finding which chapter is next is a little bit tedious.
As for playing audio from a background tab, I believe browsers actually allow it, but for some reason, audio played though emscripten's APIs seems to stutter or stop when the tab is backgrounded. It might not be hard to fix, but I haven't really looked into it.
Unfortunately and thanks to many misusing auto-playing ads - it is. Sounds can only start playing if the tab is the active one.
The thing about all this that I find interesting in describing these situations, design-theories are leveraging human language skills. The big thing is taking a customer's narrative of what they want to have accomplished and turning this into the exact, machine-implemented series of instruction. You are talking about a human-being using the language-facility to construct something exact. And well, I don't know if the structure of human-generated language for problem solving has been investigated that much by linguists but it would be interesting to see an investigation of this in relation to program design.
The local water board paid me to write a records-management program, for which Forth was a good way to access machine-level stuff. The biggest obstacle came from British Telecom, where we wanted to push voice data from the water flow meters over phone lines, and BT took a very long bureaucratic time to decide whether that should be permitted as speech or data.
more here https://www.youtube.com/results?search_query=greenarray
I have no idea why sellers are asking the prices they are.
I'm not sure really what to call this other than something along the lines of can't see the forest for the trees. Its the opposite of having functions so large it takes hours to figure out what they do. In this case you have words that you can't figure out what they do for days because the call graphs step across 300 different modules and 10k other words all of which are like "update-pie-with-apples" and comprise two other words "dup pie, apple-pie-update" or something.
The original article is by Leo Brodie. I bought his book Starting FORTH (which is now available online) shortly after reading a 1980 Byte Magazine article on FORTH.
It's not hard to implement FORTH. I found that R. G. Loeliger's book Threaded Interpretive Languages: Their Design and Implementation allowed me to easily build my own FORTH inspired system.
Only when I learned about Mathematica I found something more powerful in 1988.
Back then they used a variant of Lisp: RPL (Reverse Polish Lisp)
I went from Forth to Ruby, from a notorious write-only language to a language that's a joy to read & write.
I occasionally wonder about the possibility of a forth/ruby hybrid, stack-based interpreter/compiler with the readability of ruby.
Ruby's OO is based on message passing. A message-passing OO is something that could potentially be implemented elegantly in Forth.
The approach I'm using in Snigl  is to start with Forth and add more elaborate features as optional/gradual layers. As long as you don't use variables and closures you get to enjoy more raw speed etc.
100 CALL CHAR(96, "995A3C3C3C3C2221")
110 CALL CHAR(97, "1899FF3C3C3C4484")
The cartoons are brilliant - I often think of the universal processor (p82) "word, food, data" when designing something that doesn't have a clear purpose.
The main limitation is the interaction with the JS world, which is limited to textual I/O, but it's enough to run an interactive REPL.
Once I got my hands on a tutorial, I quickly realized it was the perfect foundation for the language  I've been designing in my mind.
From 2011: https://news.ycombinator.com/item?id=3389286