My problem with most music programming environments (in my humble, but very informed opinion) is that . . . they don't sound very good. That is, the oscillators, filters, envelopes, etc. don't sound anywhere near as good as what you can buy from UAD, SoftTube, PSP, U-he, etc.
The OP may be a DSP genius for all I know, and maybe it sounds incredible. I haven't tried it yet.
But it seems (just glancing over it) that there's an emphasis on manipulating existing audio files. This is actually huge. It's true that you can do that things like ChuCK and csound and whatever, but they never felt focused on that to me. The biggest player in this "let's mess with audio files" space was the Composer's Desktop Project. That thing was amazing, but it seems slightly moribund, and I haven't been able to get it to compile for years.
Is the problem of the oscillators not sounding very good a fundamental problem of these programming environments?
I'm mostly ignorant of their specifics, but my assumption is that someone who understands the fundamentals of synth programming could patch oscs and filters into combinations that do sound nice just as well as they could in commercial synth software.
Is there something preventing that from being the case? Or are you just referring to available presets?
It's not the combinations, it's the tasteful application of oversampling, waveshape control, and distortion.
Moog's iPad apps and the new UAD Minimoog both sound pretty good, so there's no practical reason why DSP synthesis should sound bad.
The only thing preventing that being used here is the complexity of the models and the fact they tend to be proprietary. Supercollider, Max, Csound, PD, and ChucK all use the simplest possible public domain models, and even the best of the simple models aren't good enough to generate sounds with the production values you'll hear in a commercial recording.
Generally the computer music community doesn't pay attention to production values at all. They're happy with a workable basic implementation of $effect or $synthesis_element, and they lose interest in the rest.
That's partly because DSP with high production values takes a long time and work. There's a story that gets told about the TC Electronic 6000 system, which has a gold standard reverb you'll hear in most movies [1] - which is that it was the work of a team of more than ten people working for years.
It's not hard to hack together a basic reverb algo from public sources. But it is not going to sound that good.
[1] You know the ambient piano sound some movies have in their scores? That. If you want to buy that reverb the hardware costs nearly $17,000.
To add - the CDP people solved the problem by doing things no one else was doing. It was Trevor Wishart's pet project and it was never going to be commercially viable, but he put some very interesting ideas into it. I played with it for a while and got a good few you-can't-do-this-with-a-synth sounds out of it. It was probably ten years ahead of its time and it's much easier to do that kind of thing today with modern processor speeds.
I used to know some of the CDP people and there was a story that one of them left a script running on his Atari ST and then went on holiday for two weeks. It still hadn't finished when he got back.
Most good sounding vintage synth oscillators have waveforms that are far from the mathematical "ideal" that they are named after. This gives them extra harmonics and therefore character that vanilla DSP creations generally lack. Same goes for filters, too. When they are meticulously modelled on these originals, then they can sound very good, but otherwise tend to lack the character of the sounds many of us have grown up with.
Thanks for checking it out! Trevor Wishart & CDP have been inspirations, I've incorporated some of his ideas surrounding waveset synthesis & transformations into pippi.
Primarily, pippi is the environment I use to compose my own music, and its features and approaches are driven mostly by my own compositional needs & wants. I work often from a "microsound" approach so pippi does have more of a focus on manipulating concrete sound than maybe other systems do.
Do the oscs sound good? I think they sound fine, but I haven't worked with any of the products you mentioned. Commercial synths & DSP I think tends to be focused on providing instruments via opinionated complexes of osc, filters, presets etc as you mentioned. General purpose systems like ChucK etc tend more toward facilitating the user in building their own opinionated instruments, so the path from oscs, filters to a sound you like might take more doing, and some more background in synthesis to arrive at.
That's not to say some opinionated complexes haven't made their way into pippi... but my goal is to allow myself to build instruments in a flexible way just as much as being able to have an expressive way to orchestrate their movements. I sometimes keep a small personal library of instruments I return to with pippi, but it never tends to last very long. I have a hard time fully disentangling the instrument building side of things from the compositional side of things in my own work.
That said, I want pippi to be fun, and useful for others, so including some more preset-like instruments along with the lower level building blocks is definitely in scope for the project!
Edit: FWIW the osc I use personally most often is `Pulsar2d` which is an opinionated implementation of Curtis Roads' pulsar synthesis, where both the wavetable and window stacks can be morphed over time. I often feed this with a stack derived via `wavesets.Waveset()` -- which will split a sound at zero crossings into wavesets, optionally at some interval, offset or some limit, so you can for example tap single cycles of some transforming sound over time, and reconstruct the movement of the spectrum of it in some way by morphing the stack as you like with the `Pulsar2d`...
The next set of tutorials is overdue and will cover synthesis (microsound and otherwise) in more detail!
Thanks! I’ve been performing with what I like to call a “just-in-real-time” approach with pippi now called Astrid, which allows for live coding (instrument modules reload when the file is saved) MIDI input, etc. It is in a works-for-me state though, and probably won’t be documented and packaged for others until after pippi itself is out of beta... if you are curious though it is here: https://github.com/luvsound/astrid
Edit: but to clarify yes pippi is meant primarily to facilitate writing generative musical scores in python. (Scores which produce sounds, not notation.) I have used it to perform from early on in its development, and IMHO it works fine for this, but the main use case is to render offline audio.
OP surely already knows this, but for everyone else in this thread - for live music coding, got to mention Sonic Pi (https://sonic-pi.net and https://github.com/sonic-pi-net/sonic-pi) which is absolutely amazing at what it does; it's Ruby and not Python, but some ideas are quite brilliant.
I haven't found a library for Python that does real time sounds in the way that old home computers (BBC micro etc) used to do. I got loads of pleasure when I was a teenager making sounds on my computer and hearing them back in real time, and I'd like to get that immediacy back (I have a theory that fewer kids are interested in programming than might otherwise be as it's much less immediate and accessible than it used to be).
If anyone knows of one, I'd love to know about it.
I disagree. 80s home computers camev with an interpreted language built in, and you were 5 seconds from power on to writing code. In addition, everything was accessible easily via comprehensible commands, directly. I don't think that's the case today, and in addition the bar is immensely higher than it was in the past. Commercial games in the early 80s looked like the kind of things you programmed yourself, whereas I think any title my kids play now looks like a cgi movie, and is the product of hundreds or thousands of people.
The other day I was looking at an old BBC micro demo (cold tea) and thought about porting it to python for fun. In BBC basic there is a sound command which has 4 parameters, allowing you to play a sound straight away -not play back a wav file (a la pygame etc), but generate musical pitches easily with a single command. Other older era systems had similar commands, and that immediacy (both literally in terms of command leads directly to an audio output, as well as the command being a single line and easy to understand even for 11 year old me) is what I'm looking for.
We had fun in school putting the SOUND command in a loop and either increasing or reducing the Hz to test our hearing and prove that yes, "old people" (such as our teachers who probably weren't much past 30) have terrible ears for higher pitched sounds.
If you're interested in this, I highly encourage checking out Sonic Pi [0]. It's an open source music programming language. Also works very well as a tool to teach coding.
Are you interested in music identification, especially musical instrument identification? If so, You might be interested in looking at a need gap - 'Display musical instruments used in a song'[1] which was recently posted on my problem validation platform.
This is really excellent! I've played around with Sonic Pi but always wished for something with more Python. I will definitely be playing with this.
I'm curious if anyone can point to a free library of samples or synths that would be good to pair with this? I can do without Sonic Pi's GUI but the included sample/synth library is a great jumping off point.
I’ve been really interested in dsp for music and computer music for a while now but am kind of at a loss as to where to learn more after having gone through Xavier Serra’s excellent Coursers class. Can anyone recommend further resources for learning about the subject?
For nitty-gritty DSP I would sit down and read a book like Proakis. It's quite dry but ultimately if you are able to handle the math it's worth it (for me at least, learning mathematical topics through the medium of python or similar is a distraction)
These are meant to build toward a final example mixing aspects of all the tutorials into a more realistic project.
Having used pippi for my own music for about 9 years now I try to only move structures and patterns into pippi itself when I find myself writing the same things over and over in scores. In general each score tends to be structured very differently, depending on what it does. Hopefully I can communicate that in the tutorials by showing a variety of approaches, but it’s a work in progress!
My problem with most music programming environments (in my humble, but very informed opinion) is that . . . they don't sound very good. That is, the oscillators, filters, envelopes, etc. don't sound anywhere near as good as what you can buy from UAD, SoftTube, PSP, U-he, etc.
The OP may be a DSP genius for all I know, and maybe it sounds incredible. I haven't tried it yet.
But it seems (just glancing over it) that there's an emphasis on manipulating existing audio files. This is actually huge. It's true that you can do that things like ChuCK and csound and whatever, but they never felt focused on that to me. The biggest player in this "let's mess with audio files" space was the Composer's Desktop Project. That thing was amazing, but it seems slightly moribund, and I haven't been able to get it to compile for years.
Anyway: I can't wait to dig in!