Old idea for making interesting sounds with cheap hardware
Now used digitally because easier to implement accurately
Idea: Think about an LFO being used to provide vibrato
Well, what happens when \(w_l\) gets above 100Hz or so?
Turns out, can be modeled as a bunch of harmonics and subharmonics of \(w_0\)
This is the same as FM radio: use an audio signal to make vibrato on a radio signal!
Wikipedia has a decent explanation: note "operators"
Some nice samples and a tutorial are here
Recall our discussion of sound time scales earlier
1-50ms is an interesting duration: long enough that tones will be heard as tones, but too short to hear individual notes
Idea: Break a sample into overlapping chunks in this time range and treat them as separate "music particles" or "granules"
Various games can now be played with the granules: pitch shifting (resample the individual granuals), time stretching (replicate or omit granules), fun synthesis effects (e.g. emit randomly-sampled granules)
Idea: Quit trying to be so clever. Build a model of the instrument and run the model to make simulated sound
Way harder than sampling synth, but likely to produce way better results
Pipe organ is pretty close to perfect: Hauptwerk has some amazing commercial software combining sampling (for individual pipes) with physical modeling (for the instrument as a whole)
Piano isn't bad: Physis has a nice demo
Plucked string modeling is kind of terrible in general: Karplus-Strong is basic plan.
Proper modeling requires solving acoustic systems; really hard math and physics. Drums are an active area of research
A synth is fundamentally async: want to take input from the musician while generating sound on the output
Worth thinking about how that should work
Concurrency / parallelism is generally inefficient
Hard realtime requirements on both input and output
Usual plan: three tasks, two threads
Retrieve input from the musician
Synthesize an output
Split is somewhere in the middle, but where?
The "Pull Model"
I recommend the simple, but sometimes inefficient, "pull model"
When a sample is needed, call a sample mixer, which calls sample generators, which call each other. There may be a complex flowgraph to interpret
The sources in the flowgraph are a set of currently-playing "notes" (sample buffers) and a set of control values. When a note is played out, it is removed from the note set
When a key is pressed, add a note to the note set
When a key is released, find the note that it generated and mark it as releasing
When a control is changed, update the control value
Sample generation gets priority. Good because underruns are the worst
Many audio libraries are already callback driven
No "lookahead" on key and control changes
Have to have some synchronization around control value and sample buffer access
Fairness is hard: musician may be "locked out" of the instrument
Overhead can be high — laziness is expensive