Re: [PD-dev] oscillator lib
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. Okay cool, sorry I misunderstood. Steve ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oscillator lib
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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oscillator lib
On Sat, 22 Dec 2007 14:25:04 -0500 Stephen Sinclair [EMAIL PROTECTED] 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 stkoscname or or pcoscname (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 -- Use the source ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oscillator lib
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. 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 [EMAIL PROTECTED] 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
Re: [PD-dev] oscillator lib
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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oscillator lib
On Fri, 2007-12-21 at 23:20 +, 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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oscillator lib
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 [EMAIL PROTECTED] wrote: On Fri, 2007-12-21 at 23:20 +, 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 -- Use the source ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oscillator lib
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
Re: [PD-dev] oscillator lib
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 [EMAIL PROTECTED] 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 -- Use the source ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] oscillator lib
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 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev