ha! I suppose the nice thing about filtergraph is that it's an object
you can just instantiate and visualize with. (I might also kinda like
the mouse action - but I'm also happy to not really defend mouse driven
interfaces in general... in pd/max they're always the hardest to preset
and get external control over.)
Your visualization stuff inside the [cyclone/filtercoeff~] help file is
looking promising - (rad phase and everything!) - I'll be interested to
see that up and running for sure! Will it be a portable abstraction that
can just be instantiated whenever it's needed? Maybe your [pd plot]
subpatch could go inside it somehow?
-Jesse
On 2017-07-11 11:10, Alexandre Torres Porres wrote:
> 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
> [1], 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 <[email protected]>:
>
> 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 <[email protected]>:
>
> 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 [2]
>
> cheers
Links:
------
[1] https://github.com/porres/LiveElectronicsTutorial
[2] https://github.com/porres/pd-else
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
