Yeah, so it's a didactic motivation, like I agree... so, you may be happy to know that the [filtercoeff~] object will have a visual graph (just like filtergraph) in its help file to show the response of all its filters. This is actually already inside the help file of it, but not really working yet, cause we're just attacking other priorities - but it was lazy of me, I could have done that. It is on the list though, a final release (which is getting close to a reality) will have it.
And yeah, I also use graph plots of filter's response in my didactic material https://github.com/porres/LiveElectronicsTutorial, and not only for biquad~ coefficients, but also to plot the filter response of [vcf~], which you can't get with biquad coefficients. And I'm also considering making it an abstraction in "else", to go along with the other objects I have... since I'm gonna use this library all over my tutorial anyway, that's the plan.
So maybe this settles it? Huh? Or do we really need to control a filter with a mouse dragging through that GUI? Well, again, I'd be happy and fine if anyone else cared to steal filterview and put it in cyclone for that... but I just needed to rant on how silly I think that is :)
cheers
2017-07-11 13:47 GMT-03:00 jmejia@anestheticaudio.com:
Ah yes - and of course I should've included Derek and Matt in my comment!
I find [filtergraph~] extremely useful pedagogically. I teach max and pd in that I'm also teaching basic filter theory. Hearing a bandpass filter for example without seeing or knowing its response curve is a hard way to intuitively understand how that filter works and what it's doing, so visuals go a long way when you're encountering this stuff for the first time.
When I teach using Pure Data - my current go-to are the mmb abstractions I mentioned earlier - which are pretty nice, and really worth a look if you haven't checked them out.
Combining an intuitive gui with [biquad~] (as opposed to static filters like [lowpass~], [bandpass~], etc) - is actually really exciting - because you can go from learning about filters at a really high level - to digging into biquad~ and *really* learning filter theory if you want to go there - all sort of within the same patch. That said - dedicated objects like the ones you're working on will be a great asset to have around, and yes probably more useful for quick and general use.
And actually the mmb collection also includes a biquad abstraction that uses the low level pole/zero objects - which is pretty cool.
That's exciting that [cyclone/biquad~] and [cyclone/filtercoeff~] exists!
-Jesse
On 2017-07-09 22:52, Alexandre Torres Porres wrote:
2017-07-09 18:00 GMT-03:00 jmejia@anestheticaudio.com:
Alex - any cyclone stuff in the works that might be like filtergraph in max?
No, but I guess we could "steal" from this object and include it in cyclone as a starting point for a proper clone of max's filtergraph~
Now, when I say "we", I'm not a part of it, so count me out actually :) - First cause it's out of my skills, but you know I'm not the only one working with cyclone; there are two other guys (Derek and Matt) who do the actual hardcore programming, and there is room for anybody else to join in and give us a hand coding ANY new object considered important.
Secondly, even if I could do it, I'd also be out cause personally I don't really care for this GUI (I think there are others more important and missing in Pd, like matrixctrl). But anyone is welcome to help doing it, this is what I'm saying ;) - though I wish that any GUI new development in cyclone would be applied to other objects I consider having a bigger priority.
Now, as long as we're at it, the new cyclone has new objects that I included, like [cyclone/filtercoeff~] and [cyclone/biquad~]. So [filtergraph~] is the only thing missing... Again, I don't really care much for that, I'm happy to set the cutoff frequency and Q with a number box only, I don't need a graph to see what is coming out, I already know what a bandpass is and what the Q does to it, I need my ears more than my eyes and I wonder if anyone misses seeing that during a performance - seems like it is only useful for didactic reasons, or if you're testing some formulas and biquad coefficients of your own.
Well, now that I'm at it, I'd also like to say how I think the [filtercoeff~] + [biquad~] design seems more complicated than it should, if you're going for user friendliness. It's cool you can have more than one filter with the same object and switch around, but most the time you'll be using just one of them anyway... this is why I'm designing new filters on a new library of mine, and now I have all these filters as dedicated modules, such as [bandpass~], [lowpass~], [highpass~], [lowshelf~], etc... all taking audio inlets to control the parameters.
I think this is in fact much more friendly, that is why I'm caring to design them. And I find this more important than bothering on the supposed friendliness of a filtergraph~ object. Yet once again, you can't see cute graphs or play with them, but being a musician who's been playing with filters live for a long time, I never felt that need...
So, I haven't mentioned this new work of mine on this list because it is still at an early alpha stage, and I might change some stuff before the final version (I'm aiming for a release around september). But anyway, here it goes... https://github.com/porres/pd-else
cheers