3 ms·

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

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/
    - pierrec 7y ago
      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/examples/ 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.
      - zebproj 7y ago
        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.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...
mntmoss 7y 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.
- zebproj 7y ago
  Very well said. I've come to similar conclusions working with the postfix syntax of Sporth. Is your language public at all?
skybrian 7y 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.

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/
  - pierrec 7y ago
    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/examples/ 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.
    - zebproj 7y ago
      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.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w...

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

zebproj 7y ago
Very well said. I've come to similar conclusions working with the postfix syntax of Sporth. Is your language public at all?

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