Live Coding in Sporth: A Stack-Based Language for Audio Synthesis [pdf] (opens in new tab)

I recommend playing with a postscript repl, either ghostscript or couple of the online ones.

http://logand.com/sw/wps/index.html#sec-1

I don't know the best resource, but Thinking in Forth should get you started.

http://thinking-forth.sourceforge.net

Since the others gave you promotional material, I'll give you a write-up that discusses the good and weird sides of it:

https://news.ycombinator.com/item?id=1680149

The weird stuff makes a lot of people decide not to use it. So, they should know ahead of time. I do think there's potential for a Forth with less weird stuff or more compatible with C. There could even be one already given a benefit of Forth is it's easy to write interpreters for it. On that note, here's a tutorial series illustrating that:

http://blog.asrpo.com/forth_tutorial_part_1

I played around with Forth last year and found it very fun. Similar to Lisp it has a simple ruleset with which you can build up abstractions that almost look like a DSL. I'd say it sits somewhere between Assembly and C. It's like writing assembly but you don't have to worry about register assignment.

Was the pun on colorForth intended? Just in case it wasn't, colorForth was also created by the creator of Forth, and color has syntactic significance here.

Can you give an example?

I maintain a fork of Pd, and I'm still not clear what the Sporth author, that Wikipedia article, nor you are talking about.

I think the issue of control rate in PD is often confusing for folks, because there isn’t any “control rate” that is fundamental to the language. There are audio rate signals that are processed every block, and there are messages that get handled ASAP when they are received, and are decoupled from the audio rate graph. These messages could be once an hour or once per millisecond. The control rate thing comes up because most PD objects (e.g. osc~) only update their parameters on block boundaries, which creates timing jitter (variable delay between when a message is received and when it takes effect). You could definitely have an audio-rate object that took into account the precise timing of the messages it received and scheduled the parameter changes a constant amount of time in the future, which eliminates jitter at the expense of a fixed latency. The vline~ object is useful for generalizing this approach to any object that can take audio-rate parameters, but there’s no reason you couldn’t make a vosc~ object that had the functionality built in.

This is different from supercollider (and I think sound), which have an explicit control rate.

> Objects like "mtof" and "stripnote" produce control-rate signals.

A theoretical "control-rate" "mtof" object would take its input value and compute a frequency value once every block when DSP is turned on.

But that's not what "mtof" does. Instead, it computes the frequency for an inputted MIDI value at the time it receives that value. That time could be once every block, once a minute, a single time when I load the program, at random intervals on Tuesday, or even never.

The thin line boxes constitute a kind of visual procedural scripting language. Kind of like shell scripting if pipes could have multiple prongs fanning out into multiple destinations.

Thanks! That's interesting, I've been unsure about the importance of PolySporth. It seems important if you want to create generative compositions in the traditional sense, by which I mean focusing more on the sequence of notes rather than the timbre. But for me, I think I'll always return to manual sequencing if I want to get this kind of traditional result. Whenever notes are generated, I just want to manually re-arrange them. I guess that's one of the reasons I still haven't learned PolySporth.

But if I want to create a piece where timbre is central (or if I want to work on the timbral portion of a piece that has both), then programming is actually a super effective tool, and that's where Sporth nails it for creative exploration.

As for using my examples, yes, you can totally use and modify them with attibution (I should probably add a proper licence :)