More about Switches

it's struck me that some of the components could have embedded or internal switches, especially the type that only allow one type of switch to be applied. i know you can set the switches on a component manualy or add a switch externally. but some just really dont need that.

i also have come to realize why the 10 control limit was set. it's not because the editor cant handle them but because the user interface space is limited. that can be re-worked to allow more with a simple tab system or scrolling system much the same way a drop down menu in psp or ps allows you to scroll down.

i recently had one of my filters end up in the 'unfinished' category with the accompanying email saying something about one of the controls not being what it said it was. this was due to not re-naming it and because i often have to cheat with controls to get more out of them. since we can output more than one output to different nodes on different compnoents, IF you bear in mind the hierarchal nature of the switches, you can use one control to control more than one component feature. but, that does mean that sometimes the control you plug into 'contrast', and thus gets named 'contrast', can also be used in another component as the 'lightness' switch.

i've also been toying with the notion of what if you just showed the components and switches on the user side? if the switches were embedded, at least in some cases, you could see the component and simply click the swtich that is ON the component itself. that might not work for nodes that can accept multiple types of inputs, but on the fixed ones it shld.

i tend to like to make BIG, multi-function filters. 10 controls just drives me nuts. ok, you already know that but maybe you dont understand quite the scale i do want. 50 switches is too few. some components all by themselves have 12 input nodes. that's just one component. use a few of those for a multi-filter and you're already up to 36 switches or inputs. yes, i know not all of those nodes are for switches. i have one filter i'm working on that has about 20 of these. 20 x 12 = 240. so, yes, i'm looking at the desire of having 200 + switches.

so, i've also been working on a re-design of the interface to accomodate that many functions and switches. tabs makes the most sense so far. if you take the left panel and remove the filter list and replace it with a tab system, then the filter list becomes just one of those tabs. this removes the filter list from the other tabs and allows a LOT more space for other things. since i'm mostly talking wanting switches and controls here, i could easily see adding 4 or 5 tabs for nothing but space for controls or even categories of controls with further tabs on those for individual controls. in other words, a nested tabbing system.

also, one thing that might take up less space than slider controls is radial controls. havent tested this out yet, so it's just a thought.

in a construction kit what you want is options, options and more options. you've got the basic building blocks, i just want to be able to access more of them at one time, in one filter.

sorry, i know i'm a bit obsessive on this, but the interface idea is something i did start working on last night and thought i'd pass some of this on.

oh, and one last thing, since i mentioned internal switches. the 'color' component could have another type, one with 3 colors included in the one component. using internal switches on this would make sense and you wouldnt need to add 3 different components. the internal switches would allow you to do either any one color or any mix of two or three colors. you would still be able to choose and alter any of the three colors from the user side.

craig

vladimir,

what i meant was instead of having controls as sliders and checkboxes on the user side, what if you actually showed the component like you see it on the editor side, but do it on the user side instead of the normal control sliders. the difference on the user side would be that the component would show the controls as if they were built into the component.

it's not very space efficient, i'm afraid, but it might be more user friendly in that the user could see the actual component he's using when he uses it.

it's actually not a very efficient method and was more just a wandering thought that passed by

if we had a lot more space on our monitors the best way to handle things would be to show the entire workspace of the editor but show it on the user side. if you've ever been in one of those large railroad control centers, or a large hydroelectric plant or nuclear power plant, they have those giant visual displays that show all the switches, valves and controls. as you move a control and change things the display changes also to reflect this. the FF editor does this on the editor side quite nicely, but on the user side all you see is the slider or checkbox and the result in the main window. if the user side were more like the editor side with the difference that the 'Results' component WAS your main window, i think this might be even more intuitive to the end user.

the problem with that method, of course, is the lack of space on the monitor. a compromise could be done, however. if you kept the user controls as they currently are, but added an additional panel or window that showed the component block when you clicked on the corresponding control, that might work nicely. you've currently got the list of filters above the controls, but what if that same pane showed the component one was using instead of the filter list? in the case of the controls, then, it would make sense to show both the control component and the component it was controlling and maybe even like it does on the editor side, the small preview window within the component.

but, it was really just a passing thought and not so much a serious suggestion or desire. it might be a good teaching aid, though.

craig