Max attribute behaviour is messing with max user expectations in help files

Ok went through all of these.

fluid.dataset~ “audio-descriptor” and “merging” tabs pours off patch size:

There’s also some inconsistencies/weirdness with fluid.noveltyfeature~ / fluid.noveltyslice~ with @maxfiltersize, but I don’t think these are 1.0.9 related.

So it seems like @maxfiltersize cannot be changed at all, as an attribute. You need to set it as an argument. I guess that’s a Max quirkiness thing where you want to be able to set it as an argument and an attribute.

A more solvable thing is that the default settings and the attributes set in the fluid.noveltyfeature~ mean that it is not possible to adjust the filtersize attrui. This was super confusing and sent me down the rabbit hole of maxfiltersize, but looking at the helpfile for fluid.bufnolvetyfeature~ I can see that more comprehensive attributes have been set, which means you can adjust filtersize in that helpfile. So my suggestion with this whole long rant here is to adjust the @maxfiltersize in the fluid.noveltyfeature~ helpfile to be something > 0, especially if you are going to expose the filtersize as an attrui for the user to mess with.

I’ve moved this to another thread - it is more a ‘bug’ report which is not a bug anyway.

the @max* attributes were, by design, never changeable post instantiation. The GUI doesn’t let you. It is a hack to get attrui to get them, and we auto-set them so begenning users do not have to think about allocation

at the moment, you can go downwards from the attribute that has a ‘max’ attribute . having 2 values might (or might not) improve the help for users, I’ll ponder.

Yeah I figured that it was a Max quirkiness while making the post.

Having filtersize be adjustable for fluid.noveltyfeature~ is something that should be there though as it’s super confusing otherwise (by having a non-1 value set for it as an attribute in the helpfile).

1 Like