Re: [PD-dev] oscillator lib

2007-12-22 Thread Stephen Sinclair
 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

2007-12-22 Thread Stephen Sinclair
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

2007-12-22 Thread Andy Farnell
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

2007-12-21 Thread Andy Farnell


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


[PD-dev] oscillator lib

2007-12-21 Thread Hans-Christoph Steiner

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


Re: [PD-dev] oscillator lib

2007-12-21 Thread Roman Haefeli
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

2007-12-21 Thread Roman Haefeli
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

2007-12-21 Thread Andy Farnell


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

2007-12-21 Thread Stephen Sinclair
 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

2007-12-21 Thread Andy Farnell


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

2007-12-21 Thread Hans-Christoph Steiner

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