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

www.etcconnect.com