wheelsets, and customisation

Anders,

I completely understand your request and agree with some aspects, but some of this is happening at a low level of our architecture and affects a *lot" of functionality in the console. So much of the functionality is tied together here, that allowing users to make changes could open up some opportunities for huge problems. For example, functions and features are often inter-dependent. Mutually exclusive (mutex) functions, like random color and color spin could cause all sorts of confusion if they ended up in different parameter groups. It would be even more troublesome when working with a pair of parameters that only have significance when used together, like gobo and gobo offset or hue and saturation.

We could certainly remove the duplicate wheelset entries under the parameter group that matches the "kind" of the function and this shouldn't cause any show file issues, but it could cause confusion because now knocking out position isn't knocking out all of the parameters in the position wheelset.

The problem with being able to edit kind from within edit fixtures, wheelset editor, or fixture builder is that the parameter group or kind is associated with each function. It isn't handled on a per-fixture basis. We could have issues if you had 2 lights with the same feature and those fixtures had that feature in different parameter groups.

Making the fixture builder work with every parameter is also a much easier task than it sounds. Our library supports a surprisingly large amount of features and allows for very specific customizations. The fixture builder is capable of building profiles that will work for most fixtures on the market and is capable of handling many common protocol oddities, but it is basically designed to be a tool that allows users a quick way to build a library with basic functionality until HES can deliver one with full functionality (which we try to do very quickly for user requests).

Steve developing libraries on request is usually the best solution. Users get libraries that are fully functional and we have the large advantage of being able to ensure consistency. This means better libraries based on user feedback and far easier support for us because we're working with the same libraries that you are.

Releasing the library generation tool and library source files really isn't likely to happen. There are plenty of reasons for this, but the 2 main categories of reasons would be that 1) It's a very involved process that would probably require a training course longer than Wholehog 3 console training and 2) Making changes to the library building blocks (families, functions, features, units, etc.) has to be done in very specific ways to avoid breaking functionality.

I think one possibility that may be worth considering is to add a concept of user-definable parameter groups that would allow you to define and manage your own groupings. Depending on how far we wanted to take this idea, these could be used for wheelsets, masking, knockout, and equalise operations.

I'm curious to see what other users have to say about your suggestions.
Thanks for the ideas.

I had a feeling this was a bit more complicated than i had wished for;).. man,sometimes i miss the easiness of the H2 and librarys..

"The problem with being able to edit kind from within edit fixtures, wheelset editor, or fixture builder is that the parameter group or kind is associated with each function. It isn't handled on a per-fixture basis. We could have issues if you had 2 lights with the same feature and those fixtures had that feature in different parameter groups."

-- That makes me to believe that even Steve can't make a "custom" library that moves some parameters from beam to position as an example and keeping their name? did i understand it right?

"We could certainly remove the duplicate wheelset entries under the parameter group that matches the "kind" of the function and this shouldn't cause any show file issues, but it could cause confusion because now knocking out position isn't knocking out all of the parameters in the position wheelset."

--In most situations that will be ok for me. You will of cource need to think twice, and have your head together, but for me that would be great.. Maybe a little dangerous to some with "lesser skill"(if that is alowed to say without dissing others, or making me sound bigheaded)..

-for the times i want this mainly to clean up the beam pages, we could make some kind of "hide parameters" function.. like somewhere setting parameters to "hide"(prob best place would be wheelset editor) and then when cycling beam pages, only the ones that where not selected was there, and some button combination brought up the rest of the parameters? maybe the beam button held down for 1sec or something?. Of cource this could be with every kind.. I don't know, maybe an idea?

Well when dealing with an awful lot of parameters it would be kind of interesting having a more rational way of distributing parameters. Let’s take the catalyst as an example
I have made my custom wheelset for catalyst and I have [image X pos] and [Image Y pos] under the position wheelset. Now sometimes I find myself knocking out position (Backspace [Position]) and practically doing nothing for the Hog III recognizes these parameters as Beam kind. Personally I find more logical having these parameters under the position kind, for anytime I refer to image X&Y position I’m actually moving my file around the virtual space. That would be reasonable for Image Scale and Image , Image and for the above mentioned reason. What am I asking?
Well simply to correct the fixture and to move all the above mentioned parameters in the position kind gravity and influence. I reckon it’s definitely more intuitive and we would get the beam kind lighter. It would affect an awful lot of operations we normally do such as storing palettes, or knocking out parameters.
For Catalyst particularly, it would be something that goes more according to the real world values and to the natural way we perceive anything connected to positioning.
Thanks
Marco

HI Marco.. I sertainly see your point, and i have had many discussions with people about where the different parameters should belong when dealing with a mediaserver.. and maybe the positioning/scaling/rotation/keystone is the most debated.. but i've also met people who would wan't efx parameters on a mediaservers under the coulour kind.. However my intend with this thread was not to change where they initially are, becouse i personally think that is too late, there are so many users that are both happy, and used to havin it the way it is today..

My intend was to maybe make this customable in some way, becouse basically we all have our own ways, and we all think our way is the right or best way(;).hehe) so why not make it possible to change it ourselves.. that was atleast my intention with this.

This all reminds me of a discussion of the possibility to use faders for parameters... How about having custom parameter sets on faders?

[quote=teerickson]Depending on how far we wanted to take this idea, these could be used for wheelsets, masking, knockout, and equalise operations.

it would absolutely have to.

and it's gotta be done per user.


which makes masking a load of fun.[INDENT]palette indicators definately need to reflect their masking as defined by UserKind.

Assuming that palettes, internally, have their masks defined by "Mask = I | F | C | B | T" rather than a list of every function stamped on at record time, updating needs to get a little smarter, too. i'd suggest that Update gets the set of fuctions that are allowed through the mask (per each palette) by combining the functions attributed to the UserKind + any functions that already exist in the palette, inclusively. if the function is already in the palette, allow it to update regardless of how the function evaluates against the new UserKind, in terms of masking.

[/INDENT]does that make sense? are there any other gotcha's that i'm totally spacing on?

What has not been said in this thread that is most important is to remember the generic library model. All fixtures should share common functions and kinds. So a custom fixture for a user breaks the generic model. This becomes real important when you want to copy your color values, change fixture types, etc.

All of the suggestions in this thread are very good and will be taken into consideration. We must also try to maintain the design concepts and goals of the Wholehog 3 library model, while adapting for technology and user preferences.

Please continue to make suggestion and also understand that many items are not a quick fix, but require lots of "beard stroking" prior to implementation to ensure all subsystems work as designed.

Quinn,

If you're talking about my idea of user-definable parameter groups that work in addition to the base groups of IPCBETL, then this would be possible. If you're talking about actually changing the parameter groups for certain parameters, then it would not. If we gave users any control over the primary parameter group membership, it would have to stay consistent across a single show file. Think of the problems that would happen if you had 2 programmers on a single show file and some parameters were position for one operator and beam for another. This opens up some huge opportunities for confusion, even with the dynamic typing that you describe. Looking at what we're trying to accomplish here, I think that we can find a solution that is less confusing and less likely to cause problems.

[quote=teerickson]user-definable parameter groups that work in addition to the base groups of IPCBETL"in addition" - are you suggesting the introduction of parameter groups with names other than IPCBETL?, and just so i'm clear, we *are* talkin functions, not features, right?




as for per-user/per-show, it's my strong opinion that per-user is the lesser confusing implementation. let's do the story-time thing. choose your own adventure: [INDENT]Continued from page 242

Hippie and Hardass are fighting over Frost.

Hardass thinks Frost is a property of Beam, cuz all frost does is spread the freakin beam yo.

Hippie feels Frost... *is*... a Colour... that turns down the bold... and makes the moment just... whisper in, man...




Per Show [INDENT]Hippie makes the change and Has a Nice Day.

Hardass comes in and wastes half a day re-loading the console software like six times cuz suddenly everything's half-Keeping-Separate and palettes are randomly not updating with what's RIGHT THERE IN THE PROGRAMMER!!! finally figures it out, tells LD to put his pants back on, and starts filling out the workman's comp forms that will be needed for the next time he sees Hippie.

Later, Hardass forgets that Frost is now a Colour, and inadvertantly adds new color info into hundreds of Beam palettes. Makes changes while running the show, hits his *trusty* Auto-Update all night long. goes back to 1/1/1 to begin notes. 1/1/1 doesn't exactly look right...

The confusion caused by Hippie not telling Hardass that has led to the loss of an entire day of good programming time.

You Died.
so did Hippie

[/INDENT]Per User [INDENT]Hippie makes the change and Has a Nice Day.

Hardass comes in, does his job, picks up a paycheck, and leaves. gettin' in that golden time, he heads next door to do a fill-in. Loads his prefs, like always, and tomorrow morning's programmer will never need to know that Hardass only adjusts Shutters to counter a change in Position.



[/INDENT][/INDENT]having these defined per-user is the only way there's ever going to be any consistency with this. nobody will have to learn any one else's "preferences", and nobody will have to re-learn (un-forget?) what's what when they encounter a new showfile.




[quote=teerickson]If we gave users any control over the primary parameter group membership, it would have to stay consistent across a single show file.
assuming you're talking technically, rather than personably, i'll submit this:

let's add another "user" to this thing. Server. (he lives *in* the box).
Server doesn't get its own prefs file, but is responsible for managing Hippie's and Hardass's.

When Hippie asks Server to populate his Beam palettes, Hippie should get a big ol' "C" stamped on any palette that has Frost in it.
When Hardass asks Server to populate his Beam palettes, Hardass should get a big ol' "B" on the Frosts.

this should be able to work, cuz Server can figure out which "Kind" Frost is, for each user. (whether palette labeling is server's job or desktop's job leads me to the next one...)

When Hippie changes some Frost and asks Server to "Record Position 1 Use C", someone down the line (whether it's desktop or server) decides just exactly what's in the editor, which palette is Position 1, validates the command line, and most importantly, decides which functions "Use C" refers to. i'd love to hear the reason that whoever makes that determination can't check Hippie's prefs, and just do what he wants it to do.

Quinn,

We need to consider the significance of the convenience that we're adding compared to the potential confusion.

Here are some points worth thinking about:

• Most (if not all) parameters clearly belong in a specific primary parameter group.

• Many console operations are hugely dependent on which parameter groups parameters are in.

• In a situation where there are multiple operators, there is still almost certainly going to be a single designer. In my opinion, that designer should be the one making these choices and they should affect the entire show file. Keep in mind that there are still plenty of designers in the world that speak in keystrokes to their operators. It would be very confusing if a designer telling their operators to knock colour out of a cue produced different results because the 2 consoles have different colour parameters.

I suggest that we offer users the ability to create and modify sub-groups for parameters. Here are the details I would suggest for implementation:

• Primary parameter group assignment is fixed and not controllable by the user.

• Operation remains consistent for users who choose not to create sub-groups. Current functionality is not changed.

• New sub-groups can be created, named, and deleted. Functions can be assigned to these groups. Features remain attached to their parent functions and will be in the same group. For example, Gobo 1 could be assigned to a group. Gobo 1 rotate and Gobo 1 index would be in the same group and could not be separated.

• Any masking operations for cloning, extracting, knockout, etc. would be able to use these new sub-groups.

I hope this helps to clear up my thoughts on this. Feel free to disagree or provide other suggestions.

[quote=teerickson]Primary parameter group assignment is fixed and not controllable by the user.
see, that's my problem, right there, and i think i just figured out how you're thinking, so here goes:

[quote=teerickson]Many console operations are hugely dependent on which parameter groups parameters are in.
just as it's possible to have a "Gobo" group without having to gut _lib, a "Beam" group should be able to kinda *replace* the real Beam group. "I","P","C","B","T","E","L" should all be default in a new show file, and managed by the system to automatically update based on the current fixture schedule. the "real" groups would never be exposed.

further, i think every single interface that has anything to do with displaying or parsing Kind needs to point to these primary parameter groups (which are SEPARATE from the definitions in the library).

i'm totally gonna fight for per-user later, but that's the point i'm trying to make about being able to change the "primary groups" without impacting mutex's and qualifiers and such. it can be an interface-only change.


another beef i've got with not being able to change the primaries is it's gonna double the amount of "groups" we'll need. if we made that "Gobo1" group, we'd also have to make a "Beam - Gobo1" group (which we'd have to remember to update as the fixture schedule changes) so that we don't have any knockout:beam mishaps. can you imagine how small the toolbar text would have to be?


[quote=teerickson]there are still plenty of designers in the world that speak in keystrokesi'd say, then, that since their programmers don't have to think about what buttons to press, they can instead spend allllllllllllllll day asking each other if their parameter groups are the same.

last i checked, a programmer's primary duty is to provide a layer of abstraction between a designer and the realization of the design. it's a beautiful thing when you know exactly which keystrokes "uhh..." expands to. it's even better when you're doin aerials your way, someone else is hittin the talent his way, and you both know who got uhh'd. please don't make it per-show.




anyway, you may have noticed that i only jump on ideas that i think are really really really cool. i love this one, and i'm really curious if anyone else has an opinion on how it would work...


had any thoughts on the interface, specifically knockout and equa/ize?

Quinn,

We're going to have to disagree on this one.

As I think about both current functionality and possible future expansion, I continue to think of problems that could and would happen if we gave users the ability to alter primary parameter group membership at the per-console level. I don't think it's reasonable to expect programmers to spend all day asking each other if their parameter groups are the same. Just think of how much scarier things would be if we ever chose to implement playback filtering by parameter groups. In that situation, the same playback would produce different results on different consoles, which is completely unacceptable.

My thoughts regarding an interface for knockout and equalise would be to have a button toolbar that would show all of the user's parameter sub-groups. These buttons could be used just like the IPCBETL hard keys.

I'm also very interested to hear other users' opinions about this feature request.

aight, yo dime, but for the record, i really meant per-user and not per-console.

still haven't heard your position on per-show...

Quinn,

Per-show would be far more managable than per-user, but it still runs the risk of breaking our generic fixture model, as Brad described above. Per-show would prevent the problems I describe with having differences between consoles and users on a show.

I've been thinking would it be a good idea, just to have a another wheelset above the basic one which is connected to IPCB. This may be a bad idea cause I think we run out of space...
But, the custom wheelset could be totally custom. It can have any parameter, but they are masked like they should be. The wheelset is activated by pressing it on screen and when you use masking, parameters are greyed if they don't belong to mask...there could be a little info about parameter group they belong.
Does this make any sense?