hey list,
back when i started using pd, some years ago, i can remember struggling to find anything made using it that sounded _good_. it seemed to be great for making 8bit sounds and tinny FM synthesis; but not so good for the big lushness one might expect a DSP synthesis thing to be capable of.
so.. over the last year i've been developing a bunch of techniques for making things sound 'rich' in the way that analog gear can sound. the techniques are based on ideas of inexactness and shifting over time, recognizing that in an analog system concert A will never be exactly 440Hz, and it will shift over time as the conditions change, disrupting our brain's pattern-recognition systems and leading to a more rewarding sonic experience.
the thing i'm most proud of right now is [d-fbdelay~], which is a stereo feedback delay with built in highpass and lowpass filters and a tape-flutter emulation effect. the tape-flutter is responsible for much of the richness of the synth sounds, i think. it works by smoothly changing the delay time of the delay channels slightly - by 1% or 2% - over time, to simulate an every so slightly worn out tape motor. it also effects the filter parameters. (for a nice demo grab the lowpass filter slider and whip it up and down quickly - it should make a click that disappears beautifully off into the ether.)
the other nice thing is [d-modes] which outputs MIDI notes for incoming scale degrees based on a current tonal mode (eg ionian, dorian, phrygian, lydian..), and includes a small amount of random detuning to further break up the randomness. scale degrees are being triggered by a random function with a fibonnaci distribution so that the tonic and dominant are triggered more often.
then there's the [d-biquadcalc-*] objects, which rebuild ggee's biquad filter objects in pure pd. these are a work in progress.
and [d-reverb2~] just wraps [rev3~] from the help patches.
anyway.
attached you'll find dinosaurs.tgz, which contains _dinosaurs.pd and a bunch of support files extracted from my own dlib (which, yes, i still need to get around to releasing). it is pure-pd and will definitely work with any Pd >= 0.40.3, and perhaps earlier. it might throw some errors about mrpeach objects but don't worry about that, i'm not using them yet.
at the moment the only real problem is that the biquad filter clicks sometimes when you change the sliders. i don't think there's a way around this, unfortunately. i might have to do a new external version of [biquad~] that internally ramps the values to avoid this.
let me know if you like it.
myself, i could listen to it for hours. it's very late, and i should be in bed, et cetera; but i think this might be the way to make the phantom music i hear sometimes in fans and ducts and air conditioning systems in empty offices and industrial spaces; the sounds of pieces of machinery slowly wearing themselves down to nothing, the sound of dead dinosaurs burning, ruining our winters. and what do you know, it's just the fibonacci sequence...
damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
let me know if you like it.
I like it *very much* - even love it a little!
I have a slightly simpler way to calculate the fibonacci sequence here, which uses less objects, mostly of the [list] family. It's attached. Combined with [list-wrandom] from [list]-abs it also allows for a more compact patching of the fibonacci-distributed random object. Example is in the attachement as well.
Frank Barknecht _ ______footils.org__
Very rich sound, Damian. I'd say you nailed your goal.
Phil Stone
Damian Stewart wrote:
hey list,
back when i started using pd, some years ago, i can remember struggling to find anything made using it that sounded _good_. it seemed to be great for making 8bit sounds and tinny FM synthesis; but not so good for the big lushness one might expect a DSP synthesis thing to be capable of.
so.. over the last year i've been developing a bunch of techniques for making things sound 'rich' in the way that analog gear can sound. the techniques are based on ideas of inexactness and shifting over time, recognizing that in an analog system concert A will never be exactly 440Hz, and it will shift over time as the conditions change, disrupting our brain's pattern-recognition systems and leading to a more rewarding sonic experience.
the thing i'm most proud of right now is [d-fbdelay~], which is a stereo feedback delay with built in highpass and lowpass filters and a tape-flutter emulation effect. the tape-flutter is responsible for much of the richness of the synth sounds, i think. it works by smoothly changing the delay time of the delay channels slightly - by 1% or 2% - over time, to simulate an every so slightly worn out tape motor. it also effects the filter parameters. (for a nice demo grab the lowpass filter slider and whip it up and down quickly - it should make a click that disappears beautifully off into the ether.)
the other nice thing is [d-modes] which outputs MIDI notes for incoming scale degrees based on a current tonal mode (eg ionian, dorian, phrygian, lydian..), and includes a small amount of random detuning to further break up the randomness. scale degrees are being triggered by a random function with a fibonnaci distribution so that the tonic and dominant are triggered more often.
then there's the [d-biquadcalc-*] objects, which rebuild ggee's biquad filter objects in pure pd. these are a work in progress.
and [d-reverb2~] just wraps [rev3~] from the help patches.
anyway.
attached you'll find dinosaurs.tgz, which contains _dinosaurs.pd and a bunch of support files extracted from my own dlib (which, yes, i still need to get around to releasing). it is pure-pd and will definitely work with any Pd >= 0.40.3, and perhaps earlier. it might throw some errors about mrpeach objects but don't worry about that, i'm not using them yet.
at the moment the only real problem is that the biquad filter clicks sometimes when you change the sliders. i don't think there's a way around this, unfortunately. i might have to do a new external version of [biquad~] that internally ramps the values to avoid this.
let me know if you like it.
myself, i could listen to it for hours. it's very late, and i should be in bed, et cetera; but i think this might be the way to make the phantom music i hear sometimes in fans and ducts and air conditioning systems in empty offices and industrial spaces; the sounds of pieces of machinery slowly wearing themselves down to nothing, the sound of dead dinosaurs burning, ruining our winters. and what do you know, it's just the fibonacci sequence...
d
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Fun! Two things:
"/note/phasor $1", "/note/bass $1" and "/note/osc $1" in order to get [pack OSC] to recognize them. Are you using a different [packOSC] than I am???
biquad? It's not really meant for live modulation/control of the cutoff frequency without producing clicks...
best! Derek
Derek Holzer wrote:
- Isn't there a decent audio controlled filter you could use instead of
biquad? It's not really meant for live modulation/control of the cutoff frequency without producing clicks...
cpole~ czero~ rpole~ rzero~ have signal inlets for filter control, so i assume sufficiently smooth changes will not cause clicks
Claude Heiland-Allen a écrit :
Derek Holzer wrote:
- Isn't there a decent audio controlled filter you could use instead of
biquad? It's not really meant for live modulation/control of the cutoff frequency without producing clicks...
i recently made bq~ : a biquad with audio inlet for the filter coef.
++ c
cpole~ czero~ rpole~ rzero~ have signal inlets for filter control, so i assume sufficiently smooth changes will not cause clicks
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Cool! Of course there are many audio-modulated filters in IEM lib too. I think Damian's idea was to do it in Pure PD. So I was curious.
d.
cyrille henry wrote:
Claude Heiland-Allen a écrit :
Derek Holzer wrote:
- Isn't there a decent audio controlled filter you could use instead
of biquad? It's not really meant for live modulation/control of the cutoff frequency without producing clicks...
i recently made bq~ : a biquad with audio inlet for the filter coef.
Claude Heiland-Allen wrote:
cpole~ czero~ rpole~ rzero~ have signal inlets for filter control, so i assume sufficiently smooth changes will not cause clicks
that is true, but it looks like no one has made a (usual lp,hp,etc.) filter with these objects until now. i have tried (and searched a lot before), but its not finished/perfect yet.
bis denn! martin
Hallo, martin brinkmann hat gesagt: // martin brinkmann wrote:
Claude Heiland-Allen wrote:
cpole~ czero~ rpole~ rzero~ have signal inlets for filter control, so i assume sufficiently smooth changes will not cause clicks
that is true, but it looks like no one has made a (usual lp,hp,etc.) filter with these objects until now.
Except Miller. [1]
Though I agree that some more of these would be handy. I tried to make a biquad~ clone with the elementary filters, but failed so far. I assume from [2] that the transfer function of two rzero~ and two rpole~ in series should be the same as a biquad~, however I don't know how to convert the ff1, ff2, ff3, fb1 and fb2 coefficients of biquad~ into the coefficients to use at the second inlets of the elemetary filters. Can anyone help?
[1] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node160.html [2] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node136.html
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, martin brinkmann hat gesagt: // martin brinkmann wrote:
Claude Heiland-Allen wrote:
cpole~ czero~ rpole~ rzero~ have signal inlets for filter control, so i assume sufficiently smooth changes will not cause clicks
that is true, but it looks like no one has made a (usual lp,hp,etc.) filter with these objects until now.
Except Miller. [1]
Though I agree that some more of these would be handy. I tried to make a biquad~ clone with the elementary filters, but failed so far. I assume from [2] that the transfer function of two rzero~ and two rpole~ in series should be the same as a biquad~,
You need two cpole~ and two czero~ here, admittedly in complex-conjugate pairs.
however I don't know how to convert the ff1, ff2, ff3, fb1 and fb2 coefficients of biquad~ into the coefficients to use at the second inlets of the elemetary filters. Can anyone help?
http://ccrma.stanford.edu/~jos/filters/BiQuad_Section.html
you need to munge the biquad coefficients from the form expected by Pd's biquad~ to the form of the difference equation at the bottom - should just be some scaling and sign stuff.
then you can factorize the transfer function's numerator and denominator to get the locations of the (complex) zeroes and poles (using the quadratic formula would do the trick)
then feed them to [czero~] [cpole~], and an additional [*~] for the global gain.
[1] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node160.html [2] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node136.html
Ciao
Claude Heiland-Allen wrote:
Frank Barknecht wrote:
Hallo, martin brinkmann hat gesagt: // martin brinkmann wrote:
Claude Heiland-Allen wrote:
cpole~ czero~ rpole~ rzero~ have signal inlets for filter control, so i assume sufficiently smooth changes will not cause clicks
that is true, but it looks like no one has made a (usual lp,hp,etc.) filter with these objects until now.
Except Miller. [1]
Though I agree that some more of these would be handy. I tried to make a biquad~ clone with the elementary filters, but failed so far. I assume from [2] that the transfer function of two rzero~ and two rpole~ in series should be the same as a biquad~,
You need two cpole~ and two czero~ here, admittedly in complex-conjugate pairs.
(oops) : either conjugate pairs, or both on the real line.
however I don't know how to convert the ff1, ff2, ff3, fb1 and fb2 coefficients of biquad~ into the coefficients to use at the second inlets of the elemetary filters. Can anyone help?
http://ccrma.stanford.edu/~jos/filters/BiQuad_Section.html
you need to munge the biquad coefficients from the form expected by Pd's biquad~ to the form of the difference equation at the bottom - should just be some scaling and sign stuff.
then you can factorize the transfer function's numerator and denominator to get the locations of the (complex) zeroes and poles (using the quadratic formula would do the trick)
then feed them to [czero~] [cpole~], and an additional [*~] for the global gain.
[1] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node160.html [2] http://crca.ucsd.edu/~msp/techniques/latest/book-html/node136.html
Ciao
Claude
Claude Heiland-Allen wrote:
http://ccrma.stanford.edu/~jos/filters/BiQuad_Section.html
you need to munge the biquad coefficients from the form expected by Pd's biquad~ to the form of the difference equation at the bottom - should just be some scaling and sign stuff.
then you can factorize the transfer function's numerator and denominator to get the locations of the (complex) zeroes and poles (using the quadratic formula would do the trick)
then feed them to [czero~] [cpole~], and an additional [*~] for the global gain.
wow - this is a bit above my head at the moment. i can go from equations in C to pd, but only if i have the equations themselves to look at...
anyway it would be great to have a pure-pd [biquad~] with signal input. it's the resonance and ability to control the Q that i'm really after, plus the ability to nice tricks (cf [hlshelf] which combines a high and low shelf filter into one [biquad~], saving cpu). [lop~] and [hip~] do the trick for simple filtering but when you want a squelchy resonant lowpass for bass triangle wav filtering, they don't cut it..
damian stewart | skype: damiansnz | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz
Frank Barknecht wrote:
that is true, but it looks like no one has made a (usual lp,hp,etc.) filter with these objects until now.
Except Miller. [1]
you are right, there are some "usual filters" made with pole/zero objects, the shelving and peaking ones, a nonresonant lp and a bp, iirr. and the examples in millers book have been very helpfull with my own attemps to make a resonant lowpass. but the "standard" filters (resonant 2,4 pole lp,hp,bp,notch,...) for sound synthesis do not exist (yet) in "vanilla-pd".
Though I agree that some more of these would be handy. I tried to make a biquad~ clone with the elementary filters, but failed so far. I assume from [2] that the transfer function of two rzero~ and two rpole~ in series should be the same as a biquad~, however I don't know how to convert the ff1, ff2, ff3, fb1 and fb2 coefficients of biquad~ into the coefficients to use at the second inlets of the elemetary filters. Can anyone help?
i had the same problem, and did not find a solution. (it might be quite complicated anyway), so i tried to build a filter by "directly" placing the pole and zero. it sounds not bad, but i still have a problem with scaling the output correctly. if i use this filter in a synth i have to adjust the volume quite often.
bis denn! martin
Derek Holzer wrote:
Fun! Two things:
- I had to change three messages, adding "send" to the OSC strings
"/note/phasor $1", "/note/bass $1" and "/note/osc $1" in order to get [pack OSC] to recognize them. Are you using a different [packOSC] than I am???
recent versions of [packOSC] allow to skp the "send" since this is a redundant information (only "send" messages are allowed to [packOSC]) and is misleading at best ([packOSC] does not "send" at all). at least that was what i had in mind when i asked mrpeach to accept patch#1739651 in summer 2007. http://sourceforge.net/tracker/index.php?func=detail&aid=1739651&gro...
fgmasdr IOhannes
OK, that's good to know! I'm still using Pd Extended 0.39, so I guess that change hadn't been made yet.
best, d.
IOhannes m zmoelnig wrote:
Derek Holzer wrote:
Fun! Two things:
- I had to change three messages, adding "send" to the OSC strings
"/note/phasor $1", "/note/bass $1" and "/note/osc $1" in order to get [pack OSC] to recognize them. Are you using a different [packOSC] than I am???
recent versions of [packOSC] allow to skp the "send" since this is a redundant information (only "send" messages are allowed to [packOSC]) and is misleading at best ([packOSC] does not "send" at all). at least that was what i had in mind when i asked mrpeach to accept patch#1739651 in summer 2007. http://sourceforge.net/tracker/index.php?func=detail&aid=1739651&gro...
fgmasdr IOhannes