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]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.

Reply
  • 0
    [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.

Children
No Data
Related

www.etcconnect.com