Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sporth: A small stack-based audio programming language

paulbatchelor.github.io

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Sporth: A small stack-based audio programming language

#11

Post by pierrec »

zebproj wrote: post #9
pierrec wrote: post #8

Earlier quoted context omitted.

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.

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 te…

That definitely looks cool. I remember looking at these when you mentioned them before, but then I got lost looking for example audio scripts. I just looked a bit harder and I think I found them:

https://github.com/PaulBatchelor/Patchwerk/blob/master/runt/...

I guess the documentations is in-progress, but the language seems like it has exactly the improvements over Sporth I was thinking of. Compared to Sporth, though, the development model seems less open to community involvement. It would be great to have a "contributing" guide of some sort, or a repo open to pull requests.

Re: Sporth: A small stack-based audio programming language

#13

Post by mntmoss »

pierrec wrote: post #5

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 tra…

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.

Re: Sporth: A small stack-based audio programming language

#14

Post by zebproj »

BubRoss wrote: post #10
zebproj wrote: post #4

Earlier quoted context omitted.

Could you elaborate on what you mean by that?

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.

> 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/

Re: Sporth: A small stack-based audio programming language

#15

Post by zebproj »

anonytrary wrote: post #12

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.

> 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/

Re: Sporth: A small stack-based audio programming language

#16

Post by jszymborski »

pierrec wrote: post #5

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 tra…

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

Re: Sporth: A small stack-based audio programming language

#17

Post by zebproj »

pierrec wrote: post #11
zebproj wrote: post #9

Earlier quoted context omitted.

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 te…

That definitely looks cool. I remember looking at these when you mentioned them before, but then I got lost looking for example audio scripts. I just looked a bit harder and I think I found them: https://github.com/PaulBatchelor/Patchwerk/blob/master/runt/... I guess the documentations is in-progress, but the language seems like it has exactly the improvements over Sporth I was thinking of. Compared to Sporth, though…

Due to life circumstances, I have been unable to write any real intro documentation.

> Compared to Sporth, though, the development model seems less open to community involvement

The biggest reason for this is because I'm actually using Fossil for source control instead of git, and this is a git export for visibility and convenience. Fossil also is built around a cathedral model rather than the bazaar model [0], so it it indeed harder to make one-off commits to the repo. It should be possible to have bidirectional git/fossil support, but I haven't explored it for now.

> It would be great to have a "contributing" guide of some sort, or a repo open to pull requests.

There's no guide yet because I'm not ready for any random stranger to be able to make a contribution.

However, if you (or anyone reading) are interested in using developing Patchwerk, please email me at this is paul batchelor at gmail dot com (no spaces).

0: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...

Re: Sporth: A small stack-based audio programming language

#18

Post by pierrec »

BubRoss wrote: post #10
zebproj wrote: post #4

Earlier quoted context omitted.

Could you elaborate on what you mean by that?

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.

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.

Re: Sporth: A small stack-based audio programming language

#19

Post by TylerE »

zebproj wrote: post #14
BubRoss wrote: post #10

Earlier quoted context omitted.

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.

> 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…

What about a dedicated high-performance audio/DSP langauge like csound?

Re: Sporth: A small stack-based audio programming language

#20

Post by zebproj »

TylerE wrote: post #19
zebproj wrote: post #14

Earlier quoted context omitted.

> 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…

What about a dedicated high-performance audio/DSP langauge like csound?

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.

Post reply on HN