6 ms·

Sporth: A small stack-based audio programming language

124 points by erikschoster 7y ago

BubRoss 7y ago
Things like this seem to me to be putting a language where what you really want is just a focused IDE.
- zebproj 7y ago
  Could you elaborate on what you mean by that?
  - BubRoss 7y 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.
    - zebproj 7y ago
      > it seems like the main advantage is the environment that allows for more fluid iteration combined with functions for audio. That's exactly right. Having a terse and precise notation for expressing a patch was originally why it was created. There are indeed lower level libraries in other languages powering this (Soundpipe), but I found working in C to be too slow for creative working. Sporth eliminated some of those keystrokes and enabled me to compose music I wouldn't have been able to do otherwise [0]. 0: http://paulbatchelor.github.io/sporthlings/ http://paulbatchelor.github.io/sporthlings/
      - TylerE 7y ago
        What about a dedicated high-performance audio/DSP langauge like csound?
        zebproj 7y ago
        They are great as well! Especially Csound. That's where I started. In fact, Sporth uses a lot of DSP code adapted from Csound. From a language/syntax standpoint, you're still typing way more keystrokes with Csound to do equivalent things in Sporth. Design philosophies are different as well. Csound is divided up into an orchestra/score, where the orchestra defines the signal flow of an instrument, and the score has instructions on when to play the instruments. Sporth can only define a sound in terms of signal flow, similar to a modular synthesizer. In Csound terms, it's the equivalent of having a single Csound instrument that is always on. Performance-wise, I've found that Csound has a slight edge, but not by that much. Both are mainly written in C, and both perform quite well in real-time. I use low-end hardware, and I almost never have any issues myself. I wouldn't recommend sporth for embedded systems at all, and to be careful when using it on a raspberry pi 1 (but I said the same thing about Csound too). From a code infrastructure standpoint, Sporth is way cleaner. And this is mainly what motivated me to write Soundpipe + Sporth, and the biggest strength. It's a very tiny language... the core of it is only a few thousand lines of reasonably C code, with the rest of it being ugen code, which is repetitive and easy to understand. It is built inside of a POSIX environment using simple Makefiles. Sporth code is pretty portable, and can be trivially dropped into a project (AudioKit does exactly this). Csound, on the other hand, is a massive code base full of very cryptic legacy C code, with bits of C++ thrown in for good measure, and uses CMake. Csound has an amazing collection of opcodes for creating sounds. It's an amazing ecosystem to explore. Sporth has 224 unit generators, which is a lot, but a fraction of what Csound has to offer.
    - pierrec 7y ago
      Not the author, but I'll give my take on this. The Soundpipe library underlying Sporth is ideally suited to doing exactly what you describe. It exports all the required functions in a way that can be easily integrated with any extensible language. So if you want to make a library-for-X version of this, everything is set up for you. Sporth can basically be considered a minimal demonstration of this ability. This minimalism is also one of Sporth's strengths - it made it very easy to port to WebAssembly, for example. Also consider that Sporth is almost like a markup language for audio graphs, where each occurrence of a verb represents a node in the graph. The graph is then initialized and run with minimal overhead over all samples. It's certainly possible to reproduce this in a library, but I suspect it limits your options in terms of target languages.
nexuist 7y ago
In a similar vein I present: http://nexuist.github.io/brainsynth/ 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.
- zebproj 7y 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/ http://paulbatchelor.github.io/proj/spigot/ 1: https://github.com/paulbatchelor/spigot https://github.com/paulbatchelor/spigot
pierrec 7y 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 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.
- jszymborski 7y 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 https://audiomasher.org/patch/WRZXQH
- zebproj 7y ago
  +1 on this. the author also wrote an interactive tutorial here: https://audiomasher.org/learn https://audiomasher.org/learn this is based on the sporth cookbook, found here: http://paulbatchelor.github.io/proj/cook/ http://paulbatchelor.github.io/proj/cook/
  - pierrec 7y 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.
    - zebproj 7y ago
      I agree it would be a cool feature. Unfortunately, you'd have to basically rewrite everything in order to do it. I actually kind of did that. Soundpipe[0], Patchwerk[1], and Runt[2] used together builds something that syntactically resembles Sporth, sounds virtually identical, and is usually way faster. In Runt, you can add new words and build abstractions that way. In practice, I tend to avoid doing this and will tend to generate Runt code using higher level languages like Scheme. 0: http://paulbatchelor.github.io/proj/soundpipe.html http://paulbatchelor.github.io/proj/soundpipe.html 1: http://paulbatchelor.github.io/proj/patchwerk/ http://paulbatchelor.github.io/proj/patchwerk/ 2: http://paulbatchelor.github.io/proj/runt/ http://paulbatchelor.github.io/proj/runt/
anonytrary 7y 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.
- zebproj 7y 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/ http://paulbatchelor.github.io/proj/cook/ An interactive version can be found here: https://audiomasher.org/learn 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_reference.txt 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/ugen_lookup 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/ http://paulbatchelor.github.io/res/soundpipe/docs/
  - clwk 7y 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.
    - clwk 7y ago
      I found the answer: https://github.com/PaulBatchelor/Sporth/issues/23 https://github.com/PaulBatchelor/Sporth/issues/23
  - 7y ago
Aleeshakhan786 7y ago
Good
genedelisa 7y 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 https://audiokitpro.com
- BenGosub 7y ago
  oh that's a nice fact, The Audio Kit project is great!

124 points by erikschoster 7y ago

BubRoss 7y ago

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

zebproj 7y ago
Could you elaborate on what you mean by that?
- BubRoss 7y 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.
  - zebproj 7y ago
    > it seems like the main advantage is the environment that allows for more fluid iteration combined with functions for audio. That's exactly right. Having a terse and precise notation for expressing a patch was originally why it was created. There are indeed lower level libraries in other languages powering this (Soundpipe), but I found working in C to be too slow for creative working. Sporth eliminated some of those keystrokes and enabled me to compose music I wouldn't have been able to do otherwise [0]. 0: http://paulbatchelor.github.io/sporthlings/ http://paulbatchelor.github.io/sporthlings/
    - TylerE 7y ago
      What about a dedicated high-performance audio/DSP langauge like csound?
      - zebproj 7y ago
        They are great as well! Especially Csound. That's where I started. In fact, Sporth uses a lot of DSP code adapted from Csound. From a language/syntax standpoint, you're still typing way more keystrokes with Csound to do equivalent things in Sporth. Design philosophies are different as well. Csound is divided up into an orchestra/score, where the orchestra defines the signal flow of an instrument, and the score has instructions on when to play the instruments. Sporth can only define a sound in terms of signal flow, similar to a modular synthesizer. In Csound terms, it's the equivalent of having a single Csound instrument that is always on. Performance-wise, I've found that Csound has a slight edge, but not by that much. Both are mainly written in C, and both perform quite well in real-time. I use low-end hardware, and I almost never have any issues myself. I wouldn't recommend sporth for embedded systems at all, and to be careful when using it on a raspberry pi 1 (but I said the same thing about Csound too). From a code infrastructure standpoint, Sporth is way cleaner. And this is mainly what motivated me to write Soundpipe + Sporth, and the biggest strength. It's a very tiny language... the core of it is only a few thousand lines of reasonably C code, with the rest of it being ugen code, which is repetitive and easy to understand. It is built inside of a POSIX environment using simple Makefiles. Sporth code is pretty portable, and can be trivially dropped into a project (AudioKit does exactly this). Csound, on the other hand, is a massive code base full of very cryptic legacy C code, with bits of C++ thrown in for good measure, and uses CMake. Csound has an amazing collection of opcodes for creating sounds. It's an amazing ecosystem to explore. Sporth has 224 unit generators, which is a lot, but a fraction of what Csound has to offer.
  - pierrec 7y ago
    Not the author, but I'll give my take on this. The Soundpipe library underlying Sporth is ideally suited to doing exactly what you describe. It exports all the required functions in a way that can be easily integrated with any extensible language. So if you want to make a library-for-X version of this, everything is set up for you. Sporth can basically be considered a minimal demonstration of this ability. This minimalism is also one of Sporth's strengths - it made it very easy to port to WebAssembly, for example. Also consider that Sporth is almost like a markup language for audio graphs, where each occurrence of a verb represents a node in the graph. The graph is then initialized and run with minimal overhead over all samples. It's certainly possible to reproduce this in a library, but I suspect it limits your options in terms of target languages.

nexuist 7y ago

In a similar vein I present: http://nexuist.github.io/brainsynth/ 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.

zebproj 7y 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/ http://paulbatchelor.github.io/proj/spigot/ 1: https://github.com/paulbatchelor/spigot https://github.com/paulbatchelor/spigot

pierrec 7y 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 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.

jszymborski 7y 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 https://audiomasher.org/patch/WRZXQH
zebproj 7y ago
+1 on this. the author also wrote an interactive tutorial here: https://audiomasher.org/learn https://audiomasher.org/learn this is based on the sporth cookbook, found here: http://paulbatchelor.github.io/proj/cook/ http://paulbatchelor.github.io/proj/cook/
- pierrec 7y 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.
  - zebproj 7y ago
    I agree it would be a cool feature. Unfortunately, you'd have to basically rewrite everything in order to do it. I actually kind of did that. Soundpipe[0], Patchwerk[1], and Runt[2] used together builds something that syntactically resembles Sporth, sounds virtually identical, and is usually way faster. In Runt, you can add new words and build abstractions that way. In practice, I tend to avoid doing this and will tend to generate Runt code using higher level languages like Scheme. 0: http://paulbatchelor.github.io/proj/soundpipe.html http://paulbatchelor.github.io/proj/soundpipe.html 1: http://paulbatchelor.github.io/proj/patchwerk/ http://paulbatchelor.github.io/proj/patchwerk/ 2: http://paulbatchelor.github.io/proj/runt/ http://paulbatchelor.github.io/proj/runt/

anonytrary 7y 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.

zebproj 7y 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/ http://paulbatchelor.github.io/proj/cook/ An interactive version can be found here: https://audiomasher.org/learn 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_reference.txt 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/ugen_lookup 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/ http://paulbatchelor.github.io/res/soundpipe/docs/
- clwk 7y 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.
  - clwk 7y ago
    I found the answer: https://github.com/PaulBatchelor/Sporth/issues/23 https://github.com/PaulBatchelor/Sporth/issues/23
- 7y ago

Aleeshakhan786 7y ago

Good

genedelisa 7y 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 https://audiokitpro.com

BenGosub 7y ago
oh that's a nice fact, The Audio Kit project is great!