On 9/12/06, Spencer Salazar wrote:

On the subject of nomenclature, is anyone else thinking about the relative merits of LPF, HPF, BPF, etc. vs. LowPass, HighPass, BandPass, etc.? Obviously the acronym versions are faster to type, which would be important in live-coding situations. However it seems to me that spelling them out fits in more with the current ugen naming scheme, might be a little easier to read, and also might be a little easier to understand for people new to electronic music.

(I dont have a huge vested interest in either way--just wanted to throw out a few thoughts before things get set in stone in the next release.)

Hmmmmm. SawOsc and ADSR are already abreviated too as is the reverb. In my own experience "ADSR" is the word that confuses people, not LPF. It's shorthand but very common shorthand; I could well imagine some entry level magazine writing "The Megasounds RaveBlaster mc3745 adheres to the standard OSC => LPF => ADSR structure but.....". I think it's sufficiently common to justify the useage of shorthand, people who are *that* new to electronic music will have to look up a lot in the manual anyway and you are only that new for a very short time (either you get to know the manual or give up....). That's not meant to sound elitist but if somebody would realy get into electronic music by exploring ChucK then he'll simply need to learn a whole lot in a very short time. I do agree that we need a very good look at this now. How many filters do we want in the end? I was thinking that maybe these should be called LPF12, HPF12 and so on (second order so 12db/oct) and later we might also have LPF24 (24 db) and maybe even LPFMoog, LPF303 or LPFPHLin (phase linear) or whatever. If at some later stage there would be dozens of filters (we can dream....) then "LPF" might stick out and make people wonder what sort of lowpass filter is meant because all of the others would have a more speciffic name. Does that make sense? is that where we want to go? Kas.

On 9/12/06, Ge Wang wrote: This is a 2nd order butterworth. In the future, if we want our

24db/oct filter, it might be cool to chuck 4 to:

.order (filter order)

Furthermore, there could be something to control the type:

.type (butter, cheb1, cheb2, ellip, more)

I realy like that way of looking at things. It should also work well with going from a general large-scope structure to details and refining in the programing process. This a good idea IMHO, way better then LPF12, LPF24, LPFWasp ;¬) and so on. (Of course, it's worth remembering that we can already construct any of

these higher order filter using building blocks such as BiQuad's and PoleZero's.)

Theoretically, yes. I for one need way more reading/homework/time to let it sink in to be able to do that.... Now, I am not sure if this is the right factoring. But organizing it

by function (low, high, etc.) seems slightly better than a monolithic FlexFilter type...

I agree.

If we want to go all out, someone could implement a chuck library for filter design, like the lovely matlab functions such as

.buttord (great name; specs in, minimum butterworth order required out)

as well as analog prototyping functions and bilinear transform?? It's probably pointless to try to duplicate matlab in any significant way, but the filter package is really fun and can be good for teaching in an audio driven manner. That would give us many different ways to approach filter and friends.

now I am talking crazy... must be dreaming...

No, this would be great! I've been thinking that if we have realy open-ended filters as well as the posibility to do loads of things with time then it might make sense to at some stage see how close we could get to EMU style morphing filters and similar sorts of things. A library/tookit type thingy with a "how to get started" sort of tutorial would be most welome here. I realy like how a function-call can be used to set a filter by coeficients but how to construct such a function (math wise) is a big question to me. I like where this is going. Kas.