Drone spirit - code (this one has comments): https://gist.github.com/pac-dev/af6f7b7b1786bf102c88592183de...
Harmo - code: https://gist.github.com/pac-dev/f4c4cfdb1fb03bf6ede81aac4087...
Monk voice - code: https://gist.github.com/pac-dev/76660a90406c4d8fe923fbb03094...
To be honest, you're not missing too much with PolySporth. Actually, you're better off pretending it doesn't exist for now ;) It was an experiment that tried to add concepts like polyphony and note events in time. Despite the serious time investments I put into it, I have never seriously used it. Maybe someday I'll re-examine it and do something interesting with it.
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 :)
Here are some Sporth links, for those interested:
The main Sporth project page:
Sporthlings: a collection of Sporth compositional etudes:
Sporthlings audio as a youtube playlist:
The Sporth Cookbook: documentation on Sporth, as well as some analysis of Sporth patches:
He has some more excellent work here: https://github.com/PaulBatchelor
A see also: https://github.com/mollerse/ait-lang
Recommend this talk that made Music 'click' for me. Also fun if you are trying to read GEB and generate cannons.
fnal.gov is the largest, most complete trove of postscript language material on the net.
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:
Hm... what is a control rate signal in Pd?
This is actually kind of annoying with Pd as it's not always clear what rate an object is running at.
I maintain a fork of Pd, and I'm still not clear what the Sporth author, that Wikipedia article, nor you are talking about.
There are indeed a handful of classes-- some in d_ctl.c-- (and probably externals, too) which take signal input and output some message like "bang" on block boundaries (by using a clock callback). Still, there's no "control rate"-- "threshold~" doesn't output data every block. It outputs data only when the threshold value is exceeded, quantized to block boundaries.
At least in my fork (Purr Data), the control outlets are visually distinct from signal outlets. So upon instantiating [threshold~] you can immediately see that it doesn't output signal data.
For example, when you make a signal connection (thick wires) in Pd you immediately get a signal "flowing" through that part of the diagram. It is similar to making a connection between two modules on a Buchla synthesizer. That is very useful for prototyping because you immediately get aural feedback as you connect things together. (It's also efficient because you are doing computation on vectors of data.)
That doesn't happen with control objects in Pd. When you make a control connection (thin wires) no function gets called until you somehow trigger an event that causes the object to output some data. That is very useful for prototyping because you can make arbitrary turing-complete scripts full of branches of heterogeneous data which only get computed sporadically.
I guess someone could write a library cloning the core DSP objects and have them do "control rate" computations. That is, have them do a single computation per block, and copy that value for the remaining samples of the block. I imagine no one has done that for the same reason Pd only has a single numeric (float) type-- it's good enough as is.
This is different from supercollider (and I think sound), which have an explicit control rate.
Just to reiterate so that people don't get confused:
If you give signal input to "osc~"-- let's say `[noise~]--[osc~]`, then "osc~" will update its frequency parameter every sample. If "osc~" didn't do that it would be a lot cheaper (because you'd only need to do one calculation and copy it 64 times at default blocksize), but you would of course immediately hear the loss in quality.
What you are describing is what happens when you send a message containing a single floating point number payload to the input of "osc~." In that case Pd treats that number as if it were a vector of samples all with that same value. That's fast and cheap.
> there’s no reason you couldn’t make a vosc~ object that had the functionality built in.
You can do that. But it's interesting to dissect it a bit:
* "vosc~" would only see a performance bump over `[vline~]--[osc~]` in cases where you aren't sending a signal to the input. (Because if you are sending input, the code that does precision timing of control messages is wasted cycles.) So you'd probably want to make the input a control input that can't take signals.
* With "vline~", users can control the ramp by putting more objects in between "vline~" and "osc~". But with "vosc~" they'd be stuck either with the default linear interpolation, or a selection of interpolation schemes that you code into the object. In other words, potential functionality moves from userspace to compiled classspace.
Edit: remove duplicated thingy
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.
In Sporth, the "mtof" unit-generator does a MIDI to frequency conversion for every audio sample, thus making it audio rate.
Perhaps it is better to think of control-rate signals as input signals rather than output signals. The "osc~" object, for instance, will update the frequency at every audio block. This would be the control rate. In Sporth, oscillator frequency values are updated every sample inside the audio block.
> 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 important distinction here is that the resolution can't be smaller than the audio-block size, which in turn defines the control-rate.
You're just talking about sending a float from a control object to "osc~", right?
To be clear:
If "osc~" is receiving a float atom from a control object (thin line), then yes, it will implicitly convert that float to an input vector on block boundaries.
If "osc~" is receiving signal data from a DSP object (thick line), every sample of the input is used to calculate every sample of the output.
If "osc~" is receiving signal data from "vline~", the user can supple subsample accurate frequency changes to "osc~" bound by the precision of float precision, at the expense of performance.