I want to use filtergraph~ settings with pattr

so I have to use float boxes on the input parameter

but if I use the mouse UI just the out put are set,

so i mean I have to reroute correctly (no infinite messaging so I use set)

I want to use filtergraph~ settings with pattr
but filter graph can't be used directly,
so I have to use float boxes on the input parameter
but if I use the mouse UI just the out put are set,
so i mean I have to reroute correctly (no infinite messaging so I use set)
the output to my box input.

filtergraph-and-pattr-2

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

I am pretty new to max and it will avoid me a long tester on [mtr]

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

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.

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 :

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.

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

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.

obj parameter which expose in the inspector some properties like this one

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


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).

Of course you can not interpolate between different filter types (unless you have 2 filtergraph~ & 2 biquad~).

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~).

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).

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

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.

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


filtergraph still can't be change with the mouse after a store

I am going for the solution with float box

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)

Just include the mode menu into the pattrstorage:

filtergraph~ and pattr