wheelsets, and customisation

Here's one that's been bothering me from time to time..

When dealing with mediaservers i always make my own wheelsets(or atleast most of the time) , and reordering them is ok within it's "kind"(H2 library term.)

-But sometimes i wan't to do even more customisation. as an example sometimes i wan't to have pos x/y/z,scale x/y in the position kind, and not under beam..or keystone for that mather.. sometimes becouse of programming needs, but sometimes just to get rid of some pages/rows under the beam category.. So if you try to do that in the wheelset editor, you get the parameters in the new kind, but they don't disapear from the old kind.. I guess this is becouse the desk is to "smart" and want's to show me all parameters under it's proper kind(the ones that are in the library) maybe for my own protection.. One could argue that moving parameters to a new kind could be confusing, say if a new operator takes over the desk, and don't know about it.. but on the other hand,I did the changes with intent so maybe it should obey? anyone have something to add to the discussion?

-I know that atm, the parameters you change don't change kind. only comes up another time in the wheelsets.. I see a coupple of ways this could be implemented..:

-you could make the wheelset change the kind also. would meake it easy and fast to customize things. but can be a bit dangerous when you think of that it can be imported exported..

-You can make a kind selection available in the edit fixtures menu. a little more job to customize things, as you would need to do it both in the edit meny, and in the wheelset editor. but probably the "safest" and best imlementation??

-You could make the fixture builder work with every parameter, so that we could "copy from" a library, and actually get a result that works;). and then we can customize things there..

-We can get Steve to make "personal librarys" upon request, hehe.. probably the easiest way to implement for you guys in texas, as Steve would get all the work..

-You can release the tool Steve uses to make our librarys.. one downside might be that Steve would need a new job..


anyways, i'd love this to be possible somehow!
Parents
  • 0
    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.
Reply
  • 0
    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.
Children
No Data
Related

www.etcconnect.com