There are a number of standard oscillators used in synthesis, I think it would be very useful to have a standard library of them. I think at this point there are already implementations of all of the oscillators that I can think of, what needs to be done now is to define a standard interface and naming scheme, and collect them into a standard library.
One question I have is whether they should all be bandwidth-limited, based on the current sample rate, or whether this library should have both versions.
Anyone interested in working on this? I think this would also be a building block for the standard synth lib that Ed is proposing.
.hc
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
Yes! Must have implemented them all a hundered times over by now and getting rather fed up of it.
I suggest the names
sqrosc~ (50% duty cycle standard square) sqrblosc~ (bandlimited square type) triosc~ (standard triangle) triblosc~ (bandlimited triangle) pwmosc~ (pulse width 0.0001 to 99.9999 duty) sawosc~ (sawtooth - just a 0 centered phasor) sawblosc~ (bandlimited saw) vstosc~ (vari-slope triangle, from sawtooth to inverse sawtooth) circosc~ (circle - square root of cosine) pulseosc~ (sin(x)/x pulse with variable width)
On Fri, 21 Dec 2007 12:43:17 -0800 Hans-Christoph Steiner hans@eds.org wrote:
There are a number of standard oscillators used in synthesis, I think it would be very useful to have a standard library of them. I think at this point there are already implementations of all of the oscillators that I can think of, what needs to be done now is to define a standard interface and naming scheme, and collect them into a standard library.
One question I have is whether they should all be bandwidth-limited, based on the current sample rate, or whether this library should have both versions.
Anyone interested in working on this? I think this would also be a building block for the standard synth lib that Ed is proposing.
.hc
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I think we can safely eliminate the "osc" from the names since there won't be a lot of overlap. Also, since everything is a float, I think it makes sense to standardize on 0-to-1 range. That's the standard range for amplitude, OpenGL colors, and the mapping library, and I think it makes sense to use it here.
For example, the pulse width could be 0.000001 to 1, with 1 being DC. For parameters that are an angle, then radians makes the most sense, and Hertz for frequency, IMHO. Here's my sketch for the names:
square~ (50% duty cycle standard square) squarebl~ (bandlimited square type) triangle~ (standard triangle) trianglebl~ (bandlimited triangle) pwm~ (pulse width 0.0001 to 1 duty) sawtooth~ (sawtooth - just a 0 centered phasor) sawtoothbl~ (bandlimited saw) varitriangle~ (vari-slope triangle, from sawtooth to inverse sawtooth) circle~ (circle - square root of cosine) pulse~ (sin(x)/x pulse with variable width)
Are there existing Pd implementations of all these? I think there could be an 'oscillators' lib made of all Pd patches. Then someone could make a 'simd_oscillators' with the exact same names and interface, for optimization.
.hc
On Dec 21, 2007, at 3:20 PM, Andy Farnell wrote:
Yes! Must have implemented them all a hundered times over by now and getting rather fed up of it.
I suggest the names
sqrosc~ (50% duty cycle standard square) sqrblosc~ (bandlimited square type) triosc~ (standard triangle) triblosc~ (bandlimited triangle) pwmosc~ (pulse width 0.0001 to 99.9999 duty) sawosc~ (sawtooth - just a 0 centered phasor) sawblosc~ (bandlimited saw) vstosc~ (vari-slope triangle, from sawtooth to inverse sawtooth) circosc~ (circle - square root of cosine) pulseosc~ (sin(x)/x pulse with variable width)
On Fri, 21 Dec 2007 12:43:17 -0800 Hans-Christoph Steiner hans@eds.org wrote:
There are a number of standard oscillators used in synthesis, I think it would be very useful to have a standard library of them. I think at this point there are already implementations of all of the oscillators that I can think of, what needs to be done now is to define a standard interface and naming scheme, and collect them into a standard library.
One question I have is whether they should all be bandwidth-limited, based on the current sample rate, or whether this library should have both versions.
Anyone interested in working on this? I think this would also be a building block for the standard synth lib that Ed is proposing.
.hc
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Use the source
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Two quick thoughts;
Watch out for clashes with square~ (as in x^2) - I thinkk I've seen patches with that trivial abstraction, but it might have been [squared~]
Maybe truncate trianglebl~ and varitriangle~ to tribl~ varitri~ (good to keep names less than 8 chars)
On Fri, 21 Dec 2007 16:36:03 -0800 Hans-Christoph Steiner hans@eds.org wrote:
I think we can safely eliminate the "osc" from the names since there won't be a lot of overlap. Also, since everything is a float, I think it makes sense to standardize on 0-to-1 range. That's the standard range for amplitude, OpenGL colors, and the mapping library, and I think it makes sense to use it here.
For example, the pulse width could be 0.000001 to 1, with 1 being DC. For parameters that are an angle, then radians makes the most sense, and Hertz for frequency, IMHO. Here's my sketch for the names:
square~ (50% duty cycle standard square) squarebl~ (bandlimited square type) triangle~ (standard triangle) trianglebl~ (bandlimited triangle) pwm~ (pulse width 0.0001 to 1 duty) sawtooth~ (sawtooth - just a 0 centered phasor) sawtoothbl~ (bandlimited saw) varitriangle~ (vari-slope triangle, from sawtooth to inverse sawtooth) circle~ (circle - square root of cosine) pulse~ (sin(x)/x pulse with variable width)
Are there existing Pd implementations of all these? I think there could be an 'oscillators' lib made of all Pd patches. Then someone could make a 'simd_oscillators' with the exact same names and interface, for optimization.
.hc
On Dec 21, 2007, at 3:20 PM, Andy Farnell wrote:
Yes! Must have implemented them all a hundered times over by now and getting rather fed up of it.
I suggest the names
sqrosc~ (50% duty cycle standard square) sqrblosc~ (bandlimited square type) triosc~ (standard triangle) triblosc~ (bandlimited triangle) pwmosc~ (pulse width 0.0001 to 99.9999 duty) sawosc~ (sawtooth - just a 0 centered phasor) sawblosc~ (bandlimited saw) vstosc~ (vari-slope triangle, from sawtooth to inverse sawtooth) circosc~ (circle - square root of cosine) pulseosc~ (sin(x)/x pulse with variable width)
On Fri, 21 Dec 2007 12:43:17 -0800 Hans-Christoph Steiner hans@eds.org wrote:
There are a number of standard oscillators used in synthesis, I think it would be very useful to have a standard library of them. I think at this point there are already implementations of all of the oscillators that I can think of, what needs to be done now is to define a standard interface and naming scheme, and collect them into a standard library.
One question I have is whether they should all be bandwidth-limited, based on the current sample rate, or whether this library should have both versions.
Anyone interested in working on this? I think this would also be a building block for the standard synth lib that Ed is proposing.
.hc
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Use the source
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
I think we can safely eliminate the "osc" from the names since there won't be a lot of overlap. Also, since everything is a float, I think it makes sense to standardize on 0-to-1 range. That's the standard range for amplitude, OpenGL colors, and the mapping library, and I think it makes sense to use it here.
That has got to be the first time I've seen someone suggest to make an oscillator for audio that is not in the range [-1, 1]. Anyways, why not just allow the range to be specified.
Steve
I think Hans means normalised _input_ parameters, not output range. When I specified "duty cycle" it's common to say that in percent, of course we should normalise control params.
On Fri, 21 Dec 2007 23:02:51 -0500 "Stephen Sinclair" radarsat1@gmail.com wrote:
I think we can safely eliminate the "osc" from the names since there won't be a lot of overlap. Also, since everything is a float, I think it makes sense to standardize on 0-to-1 range. That's the standard range for amplitude, OpenGL colors, and the mapping library, and I think it makes sense to use it here.
That has got to be the first time I've seen someone suggest to make an oscillator for audio that is not in the range [-1, 1]. Anyways, why not just allow the range to be specified.
Steve
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
By the way, don't forget that there are good band-limited implementations of a bunch of waveforms in STK / Chuck that you can totally "borrow". The most recent version was published with an actual license that makes it more clearly useable in other projects.
Steve
On Sat, 22 Dec 2007 14:25:04 -0500 "Stephen Sinclair" radarsat1@gmail.com wrote:
By the way, don't forget that there are good band-limited implementations of a bunch of waveforms in STK / Chuck that you can totally "borrow". The most recent version was published with an actual license that makes it more clearly useable in other projects.
Steve
Perrys stuff?
It would be nice to have these for sure. With synthesis very subtle variation in the generators can really change things, so because they have a "sound of their own" it would be good to have these tagged with their own prefix
either stk"oscname" or or pc"oscname" (pc = Perry Cook")
I'm all for a huge and diverse collection of oscillators in Pd, but to make the groundwork to avoid name-space clashes or 'my synths don't sound right because the wrong oscillator got used' .... I guess this is the importance of this discussion.
Andy
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Dec 21, 2007, at 8:02 PM, Stephen Sinclair wrote:
I think we can safely eliminate the "osc" from the names since there won't be a lot of overlap. Also, since everything is a float, I think it makes sense to standardize on 0-to-1 range. That's the standard range for amplitude, OpenGL colors, and the mapping library, and I think it makes sense to use it here.
That has got to be the first time I've seen someone suggest to make an oscillator for audio that is not in the range [-1, 1]. Anyways, why not just allow the range to be specified.
I am talking about the control parameters, like pulse width. A negative pulse width for PWM would be meaningless, or at best bizarre :).
.hc
------------------------------------------------------------------------ ----
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
On Fri, 2007-12-21 at 23:20 +0000, Andy Farnell wrote:
Yes! Must have implemented them all a hundered times over by now and getting rather fed up of it.
excuse my ignorance, but where can i find them? are those abstractions? what externals do they rely on?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Nothing to excuse there Roman, I just vaguely meant I've built them from scratch as needed in vanilla many many times. They'll be littered about various synths, some posted here, some on the forum some just kicking about my private stash.
Pulling all the common oscillators together into a lib for extended seems like a really good idea.
a.
On Sat, 22 Dec 2007 02:20:19 +0100 Roman Haefeli reduzierer@yahoo.de wrote:
On Fri, 2007-12-21 at 23:20 +0000, Andy Farnell wrote:
Yes! Must have implemented them all a hundered times over by now and getting rather fed up of it.
excuse my ignorance, but where can i find them? are those abstractions? what externals do they rely on?
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Fri, 2007-12-21 at 12:43 -0800, Hans-Christoph Steiner wrote:
There are a number of standard oscillators used in synthesis, I think it would be very useful to have a standard library of them. I think at this point there are already implementations of all of the oscillators that I can think of, what needs to be done now is to define a standard interface and naming scheme, and collect them into a standard library.
One question I have is whether they should all be bandwidth-limited, based on the current sample rate, or whether this library should have both versions.
Anyone interested in working on this? I think this would also be a building block for the standard synth lib that Ed is proposing.
i just want to quickly call attention to pdmtl abs. they already started a collection of bandlimited oscillators (my table based versions) and they also have a synth collection. since on the long run i plan to port everything what i can find to pdmtl anyway, i would like to suggest - rather than working on _another_ lib - to create those abstractions for pdmtl directly.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
while we are discussing an oscillator lib, i would like to seed the idea of creating a filter library as well. there are already a bunch of filters in iemlib and also some 'coefficient calculators' for [biquad~] in ggee, but the recently introduced elementary filters provide a potential, that seems to be not fully used yet. the only example i know is a peakfilter in one of millers examples. unfortunately my knowledge about filter design is still too limited to create them myself.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
There are lots of filters implemented already, so you don't actually need to know how to implement them to make a library. You just need to catalog them and define an interface.
.hc
On Dec 21, 2007, at 5:33 PM, Roman Haefeli wrote:
while we are discussing an oscillator lib, i would like to seed the idea of creating a filter library as well. there are already a bunch of filters in iemlib and also some 'coefficient calculators' for [biquad~] in ggee, but the recently introduced elementary filters provide a potential, that seems to be not fully used yet. the only example i know is a peakfilter in one of millers examples. unfortunately my knowledge about filter design is still too limited to create them myself.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
------------------------------------------------------------------------ ----
Mistrust authority - promote decentralization. - the hacker ethic
i'd be interested in having a set of abstractions based on the elementary filters, not on having more externals, since i believe that those would be pedagogically more valuable and also would allow to modify them for the own needs (for example turning a certain control input into a signal inlet). personally i would love to see the ggee/filters/* as abstractions. i don't see any advantage in them being externals (i intentionally neglect the in my opinion neglectible speed difference here). in contrary: to me they equal closed source.
please point me to some elementary filter based filters, if you know some. i'd be glad to catalog them and give them an unique interface.
roman
On Fri, 2007-12-21 at 21:47 -0800, Hans-Christoph Steiner wrote:
There are lots of filters implemented already, so you don't actually need to know how to implement them to make a library. You just need to catalog them and define an interface.
.hc
On Dec 21, 2007, at 5:33 PM, Roman Haefeli wrote:
while we are discussing an oscillator lib, i would like to seed the idea of creating a filter library as well. there are already a bunch of filters in iemlib and also some 'coefficient calculators' for [biquad~] in ggee, but the recently introduced elementary filters provide a potential, that seems to be not fully used yet. the only example i know is a peakfilter in one of millers examples. unfortunately my knowledge about filter design is still too limited to create them myself.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
Mistrust authority - promote decentralization. - the hacker ethic
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de