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
  • [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?
Reply
  • [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?
Children
No Data
Related