Working with paint synthesizer can be confusing because settings in one control panel overrides settings in other panels, and there are no visual clues to see what affects what.
Yesterday I saw the image below and thought I would be quite happy to see something similar in SA.
Are there any plans to extend SA GUI with some kind of visual editor?
Replies
I'm always open to suggestions for future development.
I'm not sure if a nodal hookup GUI like you illustrate would be any easier for a typical user to work with in reality. They are nice for really simple hookup things and then get to be a mess really quickly, as a look under the hood of Max patches will point out.
A nodal graph also does not match the internal architecture of something like MSG, while a list of processors processed in order accessing a fixed set of stream buses for input and output does directly mirror what is going on internally.
We would like to modularize what is in the paint synthesizer more in the future. And generalize the modulation routing. So those kinds of things are in our development plans.
And providing better visualization tools for what a paint preset is going to look like or how it works would be great.
Some of the brush type options and the vector painting options are really what override the normal paint synthesizer render pipeline. They were kind of shoehorned into the existing structure. And i agree it can get a little confusing when you turn on a vector render mode and then many paint synthesizer controls or features no longer work with that particular kind of painting. But we thought it was better to give people access to that functionality in the short term as opposed to not providing it because it supersedes some parts of the original paint synthesizer design.
There's a 'get info' overview for paint presets we've been playing around with here, that seems to be useful for giving you more overview information about what a particular preset does or how it reacts to interactive modulators like the pen without having to run through all of the control panels to figure it out.
I have to agree with panoart that some type of visual representation of the processing flow would be very helpful. I find myself trying to construct internal visualizations that look like his example when I don't understand SA's behavior. I also write a lot of Max patches, though, so I know how quickly simple can become confusing. Encapsulation helps a lot in Max, and it forces the user make their internal concepts more explicit.
Since SA users are by definition visual artists, some type of visual representation should work well. And it would be in keeping with the neuroscience foundations of SA. A good visual representation can be a very efficient display mode, more readily scanned and processed by the user than menus and text.