Sporth: A small stack-based audio programming language

https://paulbatchelor.github.io/proj/sporth

by erikschoster • 7 years ago

124 33 7 years ago

paulbatchelor.github.io

BubRoss2• 7 years ago

Things like this seem to me to be putting a language where what you really want is just a focused IDE.

zebproj11• 7 years ago

Could you elaborate on what you mean by that?

BubRoss2• 7 years ago

I don't think there is anything that a different language here is going to accomplish that a library couldn't, it seems like the main advantage is the environment that allows for more fluid iteration combined with functions for audio.

nexuist• 7 years ago

In a similar vein I present: http://nexuist.github.io/brainsynth/

I want to eventually rewrite it in Svelte because React is too slow (probably my own fault) to play notes and update the UI at the same time. I think I should have used PureComponents or something.

zebproj11• 7 years ago

Thank you for sharing. It's always fun to see the ways BF can be used to make music.

I really like the way the editor visually shows where you are. It would be really neat to get it controlling some synths in an Ableton live session or something. You'll get the notation system AND the great sounds that way.

At one point, I wrote a little BF sequencer for Sporth [0]. The nice thing about it was it just output a signal which could be mapped to literally any sound parameter at audio-rate. If the project still builds [1], there's a single demo that I made of it.

0: http://paulbatchelor.github.io/proj/spigot/

1: https://github.com/paulbatchelor/spigot

pierrec4• 7 years ago

If you're thinking of compiling this to webassembly and making an online Sporth playground... It's already done! Works pretty well, too. You can browse a bunch of Sporth scripts and play with them here: https://audiomasher.org/browse

I found the stack-based, Forth style syntax works like magic for a lot of creative audio DSP tasks. Blocks of code are like little signal chains, but denser and easier to manage than traditional spaghetti graphs (like in Reaktor, PureData, etc.) though I believe spaghetti graphs are more approachable at first.

zebproj11• 7 years ago

+1 on this.

the author also wrote an interactive tutorial here:

https://audiomasher.org/learn

this is based on the sporth cookbook, found here:

http://paulbatchelor.github.io/proj/cook/

pierrec4• 7 years ago

Thanks :D

Since you're here, I would love to know what you think of adding function definition as a language feature to Sporth (in the style of Forth, or even better, Joy). As you know I've used Sporth a lot, and I think it would be pretty useful to have this kind of feature, but perhaps implementation would be a bit challenging right now.

mntmoss• 7 years ago

The thing I think the spaghetti visual graphs get wrong is a lack of adherence to the structured programming theorem. Most data flows are mostly linear/sequential, and DAGs - which also can be expressed linearly as "send/jump ahead but not backwards", cover most of the rest. Complex structures that need to describe comprehensive fanin/fanout/feedback functionality are exceptions, and as with uses of "goto" in structured languages, most can be reduced to an implementation detail of a single node. So presenting all the options on every node, every time, with cable wiring going everywhere, is a very cluttered syntax for something that could usually be a "Lego brick" expression.

The beauty of stack languages is shared with that of RPN calculators and their postfix syntax model: You can enter the expression very quickly and precisely. Parens and operators don't "get in the way". Names aren't needed for temporary values. Small modifications don't require a rewrite. They feel mostly linear when "in their wheelhouse."

Where postfix starts losing to prefix and infix is when you have something that requires a lot of scanning back and forth to determine state. Function arguments lack clarity. Stack underflow becomes a real failure case. The scaling in terms of readability isn't very good, so "don't write large words" becomes an imperative when it's a generalized programming syntax as in Forth.

The language I'm working on right now currently uses RPN for single-line, compile-time expressions, while runtime evaluation is vertical and operates entirely in terms of keyword prefix + memory addresses, like an assembler. This constrains the scope in two ways, giving it a "twice linear" feel since left-to-right is the compile-time world while top-to-bottom is the runtime world, and those worlds only really cross over in terms of referring to compile-time identifiers(e.g. label and variable declarations, type evaluation). Since left to right is all compile-time, the meaning of an expression can vary a lot depending on the keyword, and so to expand the language I also have the option of adding original single-line DSLs to target specific runtime expressions, if I can't get what I want by adding more types to the RPN system. This is intended for small inline programs called from scripting so the at-scale view of composability isn't the main priority. It's still early, though, so I'll see how that all works out in practice.

zebproj11• 7 years ago

Very well said. I've come to similar conclusions working with the postfix syntax of Sporth.

Is your language public at all?

Aleeshakhan7862• 7 years ago

Yes

jszymborski• 7 years ago

Some of these comments are great

  # the lord saw how wicked man's sawtooth had become,
  # and it was phat

  # "yea," sayth the lord, "i will uphold your snares
  # and your hi-hats with my righteous filters"

  # and gave unto man a sine wave,
  # that he may craft a kick drum,
  # and bob his head in green pastures

https://audiomasher.org/patch/WRZXQH

skybrian• 7 years ago

It seems like the parentheses could do a bit more work, instead of just being ignored. Suppose that at compile time, the language computes the expected stack size after each word? Then the close-parenthesis could be a compile-time assertion that the stack size matches the open paren, plus the number of arguments left on the stack by the previous word.

anonytrary• 7 years ago

This sounds really cool, but could use better docs. As someone who is new to programmatic music composition, I'm not sure what the value proposition here is.

zebproj11• 7 years ago

This sounds really cool, but could use better docs.

I agree. As the creator, it can be hard to write documentation for a beginner audience, so I'd be great to hear your input. What would you suggest?

Right now, here is the documentation that exists now:

Some intro tutorials can be found in the Sporth cookbook:

http://paulbatchelor.github.io/proj/cook/

An interactive version can be found here:

https://audiomasher.org/learn

Once you understand the syntax fundamentals, most of the work is just remembering all the ugens and the argument order. For this, there's a reference guide:

https://github.com/PaulBatchelor/Sporth/blob/master/ugen_ref...

There's a command line utility that comes with sporth called "ugen_lookup" that allows you to look up entries from here:

https://github.com/PaulBatchelor/Sporth/blob/master/util/uge...

Most Sporth ugens are wrappers around Soundpipe modules, for which there is also a reference manual for. It also provides more information about what the module does:

http://paulbatchelor.github.io/res/soundpipe/docs/

clwk2• 7 years ago

Since you're here… This looks really cool. I installed, but running the demo produced no sound (but a pause). Any thoughts? I did seemingly install the dev branch of SoundPipe first. Please feel free to redirect me to a more appropriate support channel if available.

pathsjs2• 7 years ago

I am a programmer and a musician. For me, syntax is easy, and understanding stack languages is easy as well (for instance I authored a long tutorial on Factor).

What is difficult for me is to understand:

* what kind of objects are available (generators and filters, I guess, anything more?)

* what generators are available, and what is their effect

* what are triggers. This sentence doesn't explain much "A single trigger is exactly one sample that is a non-zero value (typically, this value is just a '1')"

and so on. In general, much of the terminology is alien, for instance "Since everything in Sporth is sample accurate, triggers are sample accurate and can work at audio rate." or "This creates a gate signal which is then fed into the portamento filter, whose half time value is 10ms. The portamento filter (a simple one pole smoothing filter), creates the ideal exponential curves for envelope, with a convex exponential slope on the attack, and a concave exponential slope on the release."

I just do not understand half of the words in the above sentences.

What does it mean to be sample accurate? What is a portamento filter? Why there should be a convex exponential slope on the attack? By the way, what is the attack? (I know, but it wasn't explained earlier).

This looks like a tutorial written for people who are already programming audio, and only need to understand Sporth. What is missing is a tutorial for people that are programmers and musicians, but are using Sporth to start programming audio.

Aleeshakhan7862• 7 years ago

Good

genedelisa• 7 years ago

The AudioKit project uses Soundpipe/Sporth under the hood if you'd like to see another example of it in use. https://audiokitpro.com

BenGosub• 7 years ago

oh that's a nice fact, The Audio Kit project is great!

Sporth: A small stack-based audio programming language

Related Stories