Honestly the brush engine should ignore the settings for tilt( and probably other unique tablet features) if the graphic tablet dosen’t support it. Then MyPaint could grey out the option in the brush settings and display a tooltip( or something similar) to explain why the setting is not available. If a user needs to access those settings for testing purposes, they could unlock them in the debug menu. That way the creator of the brush doesn’t have to create two different versions to account for tilt.
But they still have to create two versions, because the “substitute” for tilt (ascension) is to use “direction”. Trying to do automatic substitutions of one setting with another sounds nightmarish 
Maybe combining the two into one setting would be the better option then? I know it might be a bit nighmarish to program, but also having to many parameters for the brush engine could become a problem as well UX wise.
I really don’t see how to combine those two without making a lot of assumptions that might not be true all the time-- such as the possibility that you actually want to use both direction and tilt ascension at the same time. Keeping it “dumb” is probably a feature. Heck, a lot of dumb things are actually really cool features. Like the straight lines between points on the input graph. If we gave them nice curves it might be impossible to do some of the cool stuff with square-wave graphs, etc. I DO think, though, that we need to just build out a 3rd level of organization of inputs AND settings. Maybe call it “advanced”. So, we could hide a big list of “advanced” settings and inputs by default UNLESS that setting/input is currently being used by the current brush. So in brushsettings.json we’d add a boolean “advanced” and the just modify the brush editor on the MyPaint GUI side to hide/show these. Then add a checkbox to unhide them all if a user is brave ;-). We could seriously trim out a LOT of stuff and it’d be much less intimidating for the beginner. We could even gamify it so that you unlock settings as you do more drawings. . . (just testing to see if you’re reading 
Actually now that we are in UI talk, I would totally love to transform the brush editor into a node like editor kinda like how blender dose it. Think about, it would show the only settings that are being used for that brush which would make it easy for an artist to understand how the brush works. Plus it could pave the way to add logic to the brushes which would allow an user to use certain parameters if so-or-so device function is used. Basically I imagine these types of nodes:
- Brush Base Node - Base node which lets the user insert custom icon, and custom dab(topic for another thread).
- Brush Parameter Node - Nodes which tell the brushengine what part of the brush to manipulate. Lists available areas that can be manipulated.
- Brush Dynamics Node - A node for specifying a brush dynamic to use to manipulate a parameter.
- Tablet Function Nodes - Node for calling/reading a function of a tablet like buttons, or sensors.
- Logic Nodes - Use x parameter if y function is available.
- Loop Nodes - Why not?
Hair brain Idea I know, but would fulfil your idea. Plus nodes are fun. ^^
Btw I move these last few post to a new thread to keep your thread about your artwork. ^^’
1 Like
I had an idea to highlight and unhide the active settings, but what you describe sounds a lot better. So you would unhide settings somehow to add something new, right. The logic section section would be nice, assuming it’s actually possible to detect features. Worst case users can toggle their features manually per stylus (can we remember stylus by id?)
For GDK, device management is handled by the GdkDeviceManger.
Short term, your idea will be more ideal to implement since it really won’t require a complete rewrite of the brush setting editor. Long term though, the node editor would be fun.
