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
    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.
Reply
  • 0
    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.
Children
No Data
Related

www.etcconnect.com