Control Locks in V4???

How about in 'Filter > Overrides' having a button to make locks either per filter or per preset. When they are per filter, every preset takes the 'default' values, and when changed to per preset, they are flexible. Gold locks to indicate per filter, silver locks to indicate per preset? I've had cases where both would be ideal.

Quote
How about in 'Filter > Overrides' having a button to make locks either per filter or per preset.

xirja, that would mean two separate code paths for us developers and two separate "understanding paths" for users. We generally avoid such decisions, because that would be shifting responsibility and cognitive burden to the customers.

Dilla, inujima's idea above (see also my interpretation of it) is a pretty strong argument in favor of per-filter locks. What do you (and everyone) think about allowing to lock modifiability, not just randomization?

We could implement a weaker version of modification lock by introducing a way to apply a preset to unlocked controls only, alongside with the existing 'vanilla' Apply command. It could be added into the triangle menu on the Presets tab, the hotkey could be Shift+Enter (alas, we can't use Shift+doubleclick because Shift is used for multiselection). The new command would be disabled if all controls are unlocked.

If per-preset randomization locks are actually implemented, then I'd strongly suggest introducing a new property to control components which completely disables randomization (without the user being able to change that state short of editing the filter itself).

It really really really makes sense that filter authors have the option to hard-code certain controls to be non-randomizable. Per-filter locks would be a 'soft' way to do it, but per-preset locks really totally kill that ability (which is why I am against them). I'd really hate having to go through all presets and toggle locks just because these locks are per-preset.

Alternatively, there could be an override that toggles between per-preset locks and per-filter locks, i.e. a local/global lock option. However, I have a feeling that this would complicate things too much.

As long as the rightmost visible lock option is the preferred GUI, I don't see there being any disunity.

Quote

Simply with respect to a Noise Component, because there are different formulas and profiles available in that one component, some presets having one formula and/or profile type may require certain locks that the next formula and/or profile doesn't. Wouldn't a noise lab, or other filters with a comprehensive nature, benefit by this?

http://www.filterforge.com/filters/5036.html

Instead of having to split one filter into many, solely because of the control lock differences necessary for the differing formulas/profiles on one component, it could remain a unified and usable 'lab'.

Quote
What exactly would be the advantage of having randomization locks per-preset, I wonder. Because I really do not see any.

Same here, the advantages seem unclear to me.

I do see a potential disadvantage: per-preset locks can confuse some users. "Hey, wait a second, didn't I just lock this control down, why is it unlocked again? Let's report a bug..."

(On the other hand, presets do change all values of filter controls, and nobody seems to be confused about that.)

Well, I've briefly described some of the advantages but never went into depth about them. The idea here is that each preset acts as it's own randomizable component, instead of being "presets" as starting points for derivatives.

For example, I may have a filter that has three components: coloring, noise, and pattern selections. So I can then make a preset where I lock down the patterning and noise sliders and keep the coloring unlocked. That way the patterns and noise won't change but the colors can. Saving that as a preset means I can (without clicking around) switch between those as well.

The catch is this. If that filter exists, I may want to randomize just the colors of my filter while keeping the pattern and noise settings the same. I may want to keep the colors but randomize both the pattern and the noise. So what if I had 20 controls for this filter? Per-Filter locks means that the locks would be there globally, therefore I'd have to go and manually lock stuff around to get what I want. Per-preset means all of that is saved, meaning I wouldn't have to manually lock stuff for specific needs.

So when I mentioned "little tools" I basically mean that each preset becomes a randomizable preset with no interruption in between. I can keep the design (colors and stuff) the way I want while changing the necessary elements or otherwise.

Of course, there are a number of disadvantages, but I feel as though given the power of per-preset and the potential, it SEEMS I'd lean towards per-preset over per-filter.

The obvious disadvantage is that not all filters behave like I'm describing. There are so many filters and not exactly all of them share similar methods of building stuff so for those filters, I'm inclined to think "why per-preset? isn't that too much then?"

Even worse, it'll change the behavior and way in which some filters will be built. There's a likely chance of that "Jack-of-all-trades" filter being submitted. That's bad design, but it's going to happen one way or another. Though I feel as though some of that is over thinking the possibilities because I haven't really seen too many of those filters that attempt to do everything, and if in any case they appear, I just don't use them unless they're useful which they typically aren't.

Here's what I think overall: per-preset basically suggests the user and the author can enjoy a much controllable, randomizable filter compared to that of a per-filter scheme. Both ways we'll be able to do what we need, but the difference is in the ability to save those locking patterns. There's a significant advantage of the ability to save those combos compared to just having it saved with the filter. Personally, I'm slightly mixed with options here myself. But it doesn't seem like a major problem to me just because per-preset is implemented.

In the end, I wouldn't care which way this goes. I care more about what I can do with it. I'd vote per-preset just because I can do more with it and there are more possibilities that can be explored. The limitations are obvious with per-filter storage of locks.

I feel as though eventually if per-preset locking is available... the somehow there will be somebody who will request per-preset anyway. And having the feature per-preset covers what's available as per-filter.

Quote
In my opinion, implementing per-preset randomization locks would actually make randomization less controllable. Imagine your randomizer settings panel exploded and each of its controls scurried away to hide in some different part of the GUI. Now your once-nicely-unified controls have multiplied all over the place, resulting in one clickfest of a usability fail.

I agree with Crapadilla. Per-preset locks seems like overcomplicating something which is meant to make the user experience simpler and easier.

It's likely that in terms of workflow, a user might set their randomizer locks, hit the randomizer a couple of times, and then move sideways between to other presets: either creating new ones or jumping to a new preset and repeating the process.

I'd vote for: keep it simple.

Also, IMHO, having the locks needing to be deliberately activated somehow is OK.
Also, IMHO, having the locks be set per-filter is maybe OK. (ie per-filter not per-preset)

Really we just need the locks, and simple = good enough.

Dilla, this is an honest question: What is the point of having a control permanently non-randomizable? The user is just a biased randomizer himself if you think about it. The user is just going to see which values are good, trying out different values just like the randomizer would.

I'm now on the fence on this... there's valid points on both sides. You can't really go wrong though, and it can be updated later, that's what betas are for!

I would like that if it were per-preset, authors could make presets work the way they want them to so when someone uses it, they can hit the randomize and still get the essence of a particular preset they want.

Either per-filter or per-preset just saves time in one way and not the other since the user can change the locks manually at any time, so the real question (I think) is: would saving the lock per-preset/per-filter generally save more time or less time?

Ooooh yeah I have a bunch of filters that have different view modes as well. I hate when the randomizer messes with those. However the user may be super crazy and want it to be randomized like anything else. I'm Pro-choice

Hey how about this guys, global filter settings? like uhh.... independent of preset? I AA settings could be put in here too (but that's another topic). We could have controls that affect the filter entirely regardless of preset. These controls would typically be very much like Dilla's example of "viewing modes". I have a few fully HDR filters that have an Exposure control which would be nice to have globally too. It could be in the same section as controls but maybe on the top/bottom and not scroll with the rest of the control box.

This is a moderately large change in UI and structure but it could prove useful.

Regarding the per-control randomization permalocks on the filter author side, as suggested by Crapadilla above, my current position is weakly agaisnt.

I think it would be enough to allow the filter author to specify the default state for the locks, which would serve as a "suggestion" for filter users on what controls shouldn't be randomized. Hovever, the users remain in control and can unlock everything and anything they want.

BTW, we already have one permanently unrandomizable control on the Settings tab, the Seamless Tiling checkbox.

Quote
Regarding the per-control randomization permalocks on the filter author side, as suggested by Crapadilla above, my current position is weakly agaisnt.

The downside of my suggestion is that people might submit completely locked-off filters to the library, but you could check against that via the submission wizard.

Other than that, component-level permalocks appear to be a powerful way for filter authors to 'foolproof' randomization.

Dilla, regarding your clickfest argument, I agree. The state of filter controls is reflected in the preset thumbnail, to a rather large degree, while the state of control locks is not, so in order to check the lock-state on all presets the author has to apply and review them all, instead of just glancing over thumbnails.

Regarding the implementation of the UI for the 'soft' lock method, it could be the same as in the main window: You just switch to Filter Controls, lock / unlock controls and you're done. In addition to that, we can add a checkbox "Locked" or "Protected" into the properties of all control components. This will work with both per-filter and per-preset approaches.

(Personally, I'm in favor of keeping things simple -- that is, no checkboxes in control properties, just the little padlocks on the Filter Settings tab.)

The new locking approach makes the Randomizer Settings dialog obsolete, so I'm thinking about killing it off entirely, and replacing it with a menu that would appear when you click the little button to the right of 'Next Variant' (we'll remove the ellipsis icon and replace it with our standard menu triangle icon). The menu would look like this:

Randomization Level >
- Low
- Medium
- High
Quick Lock >
- Lock Lighting // disabled when all Lighting controls are locked
- Lock All // disabled when everything is locked
- Unlock Lighting // disabled when all Lighting controls are unlocked
- Unlock All // disabled when everything is unlocked

What do you think? Sorry for the lame mockup

Betis, the current interface can stomach maybe a single three-position randomization strength toggle ('Low' / 'Medium' / 'High'), but that's about it. The rest of the commands (i.e. Lock All, Unlock All etc.) are actions, which would require buttons, which in turn would lead to UI clutter. Anything with more than three buttons is a headache, and we already have two ('Back' and 'Next Variant').

Quote
The new locking approach makes the Randomizer Settings dialog obsolete, so I'm thinking about killing it off entirely, and replacing it with a menu that would appear when you click the little button to the right of 'Next Variant'

For the per-preset approach:

Maybe you could include an option there to copy lock-settings from one preset and paste them to another. And it would be great if you could paste them to all presets selected, would also like to see that for the lighting.
That would solve the "clickfest" problem with per-preset locking.

Quote
Another thing: The 'quick locks' should also be available as a context-menu when RMB-clicking on any of the small padlock symbols, IMO.

Dilla, we can link it to right-click anywhere in the leftmost part of Filter Settings and Lighting, i.e. the part where the control names reside.

Regarding the menu commands you suggested, adding more commands to the menu is easy, so we'll consider these commands.

Quote
For the per-preset approach

Sharandra, as for the approach in general, I'm currently leaning towards the per-filter one.

Quote
Vladimir Golovin I'm currently leaning towards the per-filter one

I agree too that I think is better to have it per-filter and NOT per preset from my personal point of view

Just caught up on my reading here...

Suggest just making this simple...little control locks (lock check boxes) on each filter and lighting control with a lock/unlock all check box...

Is this happening???

I wonder if it would be possible to have this small modifications to the GUI and also like having to be able to have a line to separate the settings inside the settings panel, and so could be put perhaps a separation between settings (as suggested here) that would give a good result randomizing and others apart with a line that would not be a good idea to be randomized and leave them locked and even better would be if they could be able to have a an on/off switch as suggested here

Have just been using some filters that would benefit very much from having this randomization locks, because as they are now, the randomization is mostly useless, as they have many settings and using the "next variant" button makes most of the times a great mess and useless results.

Would love that this is included in FF 4.0