yes, set $1 for each of the output boxes should work, these set the float boxes that [pattr] binds to. You can then hide the float boxes if all you want to use is the filtergraph~ part of the UI. If you have [line] ramps these can go into the float boxes too, etc. It's a case where you actually want to have an extra UI-type object, to give [pattr] a bridge to an object it doesn't directly support.

Try using [mtr] with filtergraph~ too, that's an easy wiring-together. The [mtr] has its own stack-overflow protection built-in, so that incoming messages (when recording) don't get sent out, while when playing back, messages don't get accepted in.

thanks for the very good advices ( [mtr] is too new to me ) would you be kind enough to provide a quick example on 1 in/out of filtergraph~ for the [line] and the [mtr]

I am pretty new to max and it will avoid me a long tester on [mtr] the pattr stuff is ok don't worry

thanks

just follow the [mtr] help file, the inlets and outlets correspond to playback of a number of "tracks". all you have to do is wire the same [filtergraph~] values like frequency through the [mtr] and then back into the [filtergraph~]. Or you can get fancier and have floats before and after, which is where [pattr] comes in.

muting individual tracks is easy, so you can block playback of whichever parameters you want and get UI control back for that element: playback the Q and the gain but manually move the frequency, or whatever combination during playback.

Hello Maa,

I don't see how [mtr] will solve your pattr problem but anyway.

Here's the way to go to store filtergraph~s freq/gain/q values :

léo

mtr is not related, but I learned a new object

I took the best of both examples, and extend

somebody complete to avoid clicks (smooth the change) ?

> I want to use filtergraph~ settings with pattr but filter graph can't be used directly

Unless I completely misunderstand, this appears not to be true.

even better work with autpopattr too how ro know if an object is compatible with pattr or not ?

> how ro know if an object is compatible with pattr or not ?

Don't know if there's a complete list, but easiest is just to try. All ui objects are candidates.

two more thing for the v6 wish list a field in the documentation obj parameter which expose in the inspector some properties like this one

Yes, that the easiest solution. The only problem I see, is that you cannot read freq/gain/q values in the filter coeff list. Sometimes it's of some use to have a look at the preset files or the pattrstorage client/storage window.

Concerning avoiding clicks, you can use pattrstorage internal interpolation (just connect a float to pattrstorage). biquad~ should not produce any clicks. Of course you can not interpolate between different filter types (unless you have 2 filtergraph~ & 2 biquad~).

Léo

Leo

very good point about the readability of the storage data infact all this object should be like a subpatch and declare several pattr with names and not a list, this way they could be select/deselected from the preset, pattrstorage client/storage window. but this not the first flaw in the symetry of the design... even the pattr name is bad (param would be better).

avoiding clicks: are you sure biquad~ don't produce clicks.

no one on the line stuff (i am controling individual param (goingthru pattr interpolation is too complex for simple fx

For interpolation, I would opt for this solution.

Really nice one, interpolation between filter types is then also possible.

Thanks

Léo

yep but everytime you recall something you UI is lost on the filtergrapgh have to pick a filter type to reactivate

An easy solution :

filtergraph still can't be change with the mouse after a store I am going for the solution with float box ( pattr name / direct control)

thanks

Maa

Just include the mode menu into the pattrstorage: