Module file formats [0] have been around since the 80s, and they can kind of be thought of as MIDI files with sound samples embedded in them. You can get some very impressive sounding full-length tracks in only a few kilobytes.
Are you asking for library recommendations for a simple standard used extensively for the last 35 years when there are already 6 libraries linked in the wikipedia page you were given?
I used to use a live-coding setup with Sporth centered around Vim, though it has never been added to the codebase. If anyone is interested in this, please feel free to email me at thisispaulbatchelor at gmail dot com.
When I was pursuing Forth, and about to give up on doing anything beyond a file munger I wrote, I discovered Sporth, and had a blast for at least two or three weeks and kept Forth on my radar! A lot of complexity from a few lines of Sporth! What are you up to nowadays?
These days, I'm so steeped in experimental music, that I was expecting something a bit more "out there" [0]. This feels quite tame by comparison.
I like the idea of a chromatic staff. Making notes visually more evenly spaced would probably make certain things clearer, and probably would provide some interesting insights from a musical analysis point of view. The fact that it still uses the same 5-line staff would make it easier to adopt. It's familiar, and you can use existing staff paper.
However, speaking as a reasonably proficient sight reader, I don't know how much more improvement this adds. From a readability point of view, this looks about the same to me (which I suppose is half the point). Maybe I'm just a jaded musician, but I just don't find music notation that hard to pick up.
Reading music is very similar mental process to reading text. Your brain quickly learns to chunk notes into patterns rather than individual groups, similar to how in reading you don't actually parse out every single letter.
"One reason why none of these alternative notations has caught on is presumably that it takes a lot of time and effort to learn a new notation system. Not only professional musicians, but also musicologists (including music psychologists and music theorists) invest enormous amounts of time learning to read conventional music notation. Understandably, they don’t want to have to start again from scratch. So they tend to avoid the problem of conventional notation’s shortcomings and the evaluation of alternatives by regarding the problem either as irrelevant (“conventional notation obviously cannot be improved”) or impossible to solve (“it is clearly impossible to decide among the many possible alternatives”)"
Whenever I see products on instagram or wherever that say things like "now anyone can play guitar!" I get annoyed. It's not that I don't want people to learn guitar—hell yes learn guitar!! But you can't skip the hard part. You can NEVER skip the hard part.
I suspect the authors of this idea know what they're doing better than I do, and I don't have a strong specific opinion on it. But when I see attempts at 'improving' well-established systems it makes me wonder if it's just someone who hasn't learned WHY the 'hard' thing is designed the way it is. Again—I am absolutely all for experimenting with every conceivable way of doing something, as this is how progress is made.
In this case, the first thing I thought of is that diatonic staves are the way they are because most (traditional 'western') music is in a single key. So it shouldn't be surprising that the notation optimizes for that. And if you change key, you just write down the new key and continue along. I don't personally see much need for a chromatic scale unless you were, I guess, writing 12-tone music ;)
I'm also a big fan of experimental musical notation and, googling around, it seems there isn't a single database of them. Shit, I already have too many side projects......
Bringing up 12 tone, when first exposed to this music, the first thing I did is rewrite it on a rearranged chromatic staff. It is so clear that it belongs that way. But it certainly isn't easier to play that way.
So I feel a "new" notation system that is easier to read, not that interesting, nor that helpful. But an "alternative" system that is optimized around composing in a certain way is interesting, and helpful, but when you're done it probably makes sense to write it in traditional notation if you are going to write it down.
I'm slowly learning to play the guitar. I'm at the level of enthusiastic beginner and my main issue is finding time to practice (without my children joining in). With that said, reading the music never struck me as one of the difficulties. Building an understanding and intuition of how different notes and chords relate to one another however...
The hard part I'm referring to is the work of training your ears and fingers to do what you want them to do. Similarly, learning an entirely new orthography or notation is always going to involve training yourself, and you can't skip it. There are absolutely ways of making things easier on yourself: books, videos, gadgets, etc., but you still can't just bypass it. At least until we can learn kung fu via direct brain interface ;)
Csound is a fantastic sound design tool. It was my main composition tool for many years, before I started building my own system. The score/orchestra paradigm is incredibly powerful. It's something I miss quite often in my current system. When I was in music school, I learned how to program by writing programs in Python to generate scores that could then be played by Csound. Scores are so trivial to generate, that you actually don't need to learn that much programming to generating very satisfying algorithmic compositions.
I appreciate that the title of this post calls it a "sound and music computing system" rather than a "musical programming language". In truth, Csound is more of a text-based modular synthesis environment than a programming language.
As others have said, the orchestra syntax is a bit strange at first, but you do get used to it. Writing Csound code feels more like patching a modular synthesizer rather than writing a computer program. It's basically a DSL for connecting small sound/signal modules (called opcodes) together. Most of the time one thinks about things in terms of signal flow and not computer logic. A common mistake I see new Csounders make is to immediately reach for the conditional statements and loops. They often don't behave the way you expect, so people get frustrated.
The Csound dev team has a very strong emphasis on backwards compatibility, to the point where the older opcodes do not get bugfixes in case someone is exploiting the bug in the compositions. The programmer in me groans a little bit, but the composer takes great comfort in the fact that pieces I write now will be playable for many years or even decades (some of the Csound test pieces, like Trapped In Convert by Richard Boulanger or Xanadu by Joeseph Kung, are over 30 years old and still run).
I've been told that many works written in MusicN languages (a precursor to Csound) have been ported to run in Csound, which means that the legacy of Csound includes computer music written in the 60s! I wish I knew where to find those, as I quite enjoy computer music history.
> Writing Csound code feels more like patching a modular synthesizer rather than writing a computer program.
I agree with this point. I am using Csound for creating VST plugins (with Cabbage framework[1]) for which is Csound extremely productive. I can have working prototype (which I can actually play on my keyboard) ready in something like 15 minutes.
Once you get over somewhat strange syntax[2] and understand difference between k-time and i-time[3] you can do any DSP processing without actually diving into hard math.
Cabbage has nice beginner documentation on Csound[4].
Yeah this piece was a huge piece of inspiration for me when I was learning Csound. I actually had a chance to ask BT about this particular piece once and if the rumors were true about it being all done in Csound. The guitar riff you hear halfway through the piece is actually sampled and played via the diskin opcode. Other than that, all Csound. Still a very impressive feat, especially considering the fact that the piece itself was originally mixed in 5.1.
Nice! I'd wondered about that guitar, it sounds impossibly real to be pure Csound. Thanks for the insight. And yes, I had the opportunity to listen to the whole album on a decent 5.1 system at uni a while back and it's pretty spectacular.
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:
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:
I am a programmer and a musician. For me, syntax is easy, and understanding stack languages is easy as well (for instance I authored a long tutorial on Factor).
What is difficult for me is to understand:
* what kind of objects are available (generators and filters, I guess, anything more?)
* what generators are available, and what is their effect
* what are triggers. This sentence doesn't explain much "A single trigger is exactly one sample that is a non-zero value (typically, this value is just a '1')"
and so on. In general, much of the terminology is alien, for instance "Since everything in Sporth is sample accurate, triggers are sample accurate and can work at audio rate." or "This creates a gate signal which is then fed into the portamento filter, whose half time value is 10ms. The portamento filter (a simple one pole smoothing filter), creates the ideal exponential curves for envelope, with a convex exponential slope on the attack, and a concave exponential slope on the release."
I just do not understand half of the words in the above sentences.
What does it mean to be sample accurate? What is a portamento filter? Why there should be a convex exponential slope on the attack? By the way, what is the attack? (I know, but it wasn't explained earlier).
This looks like a tutorial written for people who are already programming audio, and only need to understand Sporth. What is missing is a tutorial for people that are programmers and musicians, but are using Sporth to start programming audio.
Good questions. My background is in computer music, and I do use a lot of jargon. A good chunk of them probably come from Csound (and, by extension, the MUSIC N family of languages). Sporth also expects a certain familiarity with modular synthesis, and digital audio systems in general.
> what kind of objects are available (generators and filters, I guess, anything more?)
In Sporth, "objects" are referred to as things called unit generators, or "ugens" for short. These things can take in signals as input, and write signals as output. Signals are all audio rate. Even a constant value is an audio-rate signal.
As you mentioned, effects and signal generators are two kinds of unit generators. Another important one are control-signal generator, which include things like low-frequency oscillators (LFOs), or envelopes. These things generally produce signals designed control parameters of other things.
There are also things called ftables (short for function tables I think? another term borrowed from Csound). These things are more or less floating point arrays. Usually they are used for sequences, storing wavetables for table-lookup oscillators, or loading audio samples. An ftable is an ftable, so if you wanted to take a loaded snare sample and use it inside of a sequencer ugen, there's nothing stopping you from that.
> what generators are available, and what is their effect
Hard to answer that one concisely. There are approximately 220 unit generators in Sporth right now. Some of them do simple things like addition and multiplication. Others do more complicated things. Some make sound, some process sound, some do a combination of both. The art of composing with Sporth is building an intuition for how these modules will sound together. Admittedly, there is no documentation for all of this in Sporth. There's no time for that. BUT! If you study highly modular computer music systems like Csound or Supercollider, you'll learn concepts that can be applicable to Sporth.
> what are triggers. This sentence doesn't explain much "A single trigger is exactly one sample that is a non-zero value (typically, this value is just a '1')"
Ah yes, this is modular synthesizer terminology. If you don't have experience using modular synthesizers, I can see why this is confusing.
Triggers can be thought of as a sort of message, encoded in an audio signal. When a trigger signal occurs, it means "do something". What that something is, depends entirely on the ugen reading the signal. When a trigger signal gets fed into an envelope generator, it tells the envelope to re-trigger the envelope. When a trigger signal gets fed into a sequencer, it means go to the next note in the sequence. Stuff like that.
> I just do not understand half of the words in the above sentences.
That was me and the music-dsp mailing list for many years. I've now got around 70-80 percent comprehension there, but yeah jargon. The thing is, once you start memorizing jargon words, you forget what is jargon and what isn't.
I can totally see where you are coming from. It would be great to see Sporth tutorials written for different audiences than mine own. But I need help for that. It's just not a responsibility I am ready to take on. If you do not have the prerequisite background in computer music, there is just so much you need to unpack, and it will never be enough. I'm only one person, and I need what little time I have to try to compose my own music with the tools I write for myself. Selfish by definition, but true.
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.
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 tend to generate Runt code using higher level languages like Scheme.
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:
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.
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).
In acidforth, I implemented "functions" in a way that it can be handled very early in the compilation process and not have any impact on the execution environment. They look like forth colon definitions but are just macros that get expanded immediately during compilation.
Perhaps that is an approach that would work for Sporth? If nothing else it could be implemented as a separate source to source pre-processor.
> Note: aubio is not MIT or BSD licensed. Contact the author if you need it in your commercial product.