Could it be possible to have Frame1A and frame 1B on same wheel: Wheel1=Frame 1A and Pig+wheel1=Frame 1B, with this option you could have 4 frames on same wheels page.
I like this idea because it seems to offer a more efficient way of controlling some fixtures and that's always a good thing.
Here are my issues:
1) Pig + Encoder is already implemented as fine resolution control mode. People expect it to work that way when programming, regardless of what type of parameter they are controlling.
2) There aren't currently any parameters for which we display 2 values over a single encoder wheel. When a wheel has multiple control modes that are mutually exclusive you can switch between them, but you're still always dealing with a 1 wheel to 1 value relationship. I'm concerned both because this is a change of our standard and accepted behaviour and because I'm not sure how big a change this would be to implement.
3) Would there be any advantage to having the encoder wheel control both 1a and 1b at once so you have an easy way of moving the shutter straight in and out? This would possibly require 2 separate modifier keys for 1a and 1b, but when I think about what I usually do when I'm working with lights that have shutter systems, I usually run the frame straight in until I'm close to where I need to be, then I adjust the angle.
[quote=teerickson] 3) Would there be any advantage to having the encoder wheel control both 1a and 1b at once so you have an easy way of moving the shutter straight in and out? This would possibly require 2 separate modifier keys for 1a and 1b, but when I think about what I usually do when I'm working with lights that have shutter systems, I usually run the frame straight in until I'm close to where I need to be, then I adjust the angle.
YES! :love: :arms:
I think an easier way than having to hold any extra keys down is to have an encoder "mode" if you will. Similar to gobo/color wheel modes of index vs. rotate and strobe modes, iris modes etc.
So you have three options on the left side of an encoder "A", "B", & "Tandem".
When you touch the encoder value on the screen, you can toggle how the shutters behave.
The only problem with this, is that you will not be able to see two values at once on the encoder...you'll have to look at your Programmer or Output window to see both values for a shutter simultaneously.:33: :33:
Unless you guys come up with a clever way of displaying both values at once on the encoder....not easily done though I'm sure;)
[quote=teerickson] 1) Pig + Encoder is already implemented as fine resolution control mode. People expect it to work that way when programming, regardless of what type of parameter they are controlling. Perhaps with control, set, or back, next ?
[quote=teerickson] 3) Would there be any advantage to having the encoder wheel control both 1a and 1b at once so you have an easy way of moving the shutter straight in and out? This would possibly require 2 separate modifier keys for 1a and 1b, but when I think about what I usually do when I'm working with lights that have shutter systems, I usually run the frame straight in until I'm close to where I need to be, then I adjust the angle.
same than marty, because on Clay paky using 1a and 1b together is great, but it must be 2 closes keys
We are seeing some good ideas here, I just have a thing we need to consider also, is that not all fixtures use 1 a and b in the same way..
As an example, Vl1000 has a and b physically connected to each side of the shutter, so moving them together is ok.. On a Mac2000, a is the whole shutter in and out, and b is the angle of the shutter, so moving them together would be a bad idea..
Encoder without modifier key would increase or decrease A and B at the same time
Encoder with modifier key would decrease the value of A and increase the value of B or the opposite (Clockwise would of course increase A and decrease B and CCW the opposite)
Some Lamps have shutters with 2 channels, one for the position, the second one for the angle. Other lamps have 2 channels, one for each side of the shutter blade. So you'd push in one side of the shutter a little further than the other side to move the angle.
What would be needed is a abstration layer, so you'd push in a shutter blade with the first wheel and have the angle on the next wheel. The desk would have to take care for those lamps, that do not have the angle separated but have just 2 channels for the sides of the shutter... Of course this should (at some time) be calibrated so you'd exchange a VL1000AS for a mac2k performance and not only the head position and colors but also the shutter blade-palettes match...
So with abstraction we would need only two options for an encoder "Thrust" and "Angle". Simply touch the encoder to toggle the mode as you would to go from "Index" to "Rotate" on a gobo wheel.:headbang:
[quote=jankirchhoff]What would be needed is a abstration layer, so you'd push in a shutter blade with the first wheel and have the angle on the next wheel. The desk would have to take care for those lamps, that do not have the angle separated but have just 2 channels for the sides of the shutter... Of course this should (at some time) be calibrated so you'd exchange a VL1000AS for a mac2k performance and not only the head position and colors but also the shutter blade-palettes match... [quote=Marty Postma] So with abstraction we would need only two options for an encoder "Thrust" and "Angle" I am not sure to understand "shutter blade with the first wheel and have the angle on the next wheel" if I count well that made 2 wheels
Having only "Thrust" and "Angle" sound well with my ears, but that seems to give a larger work to HES, therefore an option which will come much later. In addition, for fixtures of the Mac type it is rather simple, but for the CP or VL how to define the origne rotation, from midle, the top or bottom of shape?
Way back in the early days I requested a framing shutter tool, a little like the color picker where users could drag each shutter individually by centre or either edge, or all shutters collectively, rotate the gate in either direction, select from a few preset shapes like box, triangle, slot etc, zoom whilst maintaining each shape, high-light shutters for identification purposes, and a one click home option to reset to defaults.
The beauty of this for me is I rarely know in truth which shutter I need to adjust given hanging orientations, focus positions etc. and it would work cross platform with both methods of framing shutters so when selecting a Mac 2k Performance and a VL1000 together both could be adjusted simultaneously.
I agree with Ross that we need a set of abstraction tools to deal with this!:)
This is exactly the kind of thing a console with abstraction should be good at anyways. That's kind of the whole point. It might take a bit more work calibrating the fixture profile, but once it's done it's done!:D
Keeping track of the orientation of all your heads can be a pain if you've got a lot of them. This means things keep reversing on you of you're not super careful.(Oh, yeah I forgot I flipped that one 5 cues ago...DOH!);)
So what we need is an abstraction tool similar in concept to the HS wheel.
I like Steph's thought of having it work similarly to WYG, but yes we would still need some sort of encoder control just like Hue/Sat. vs. CMY.
Steph's original thought of being able to control all 4 blades on one set of encoders would require that each encoder have 2 modes...one for "Thrust" or "Insertion", and another for "Angle". You would still have to go over to another encoder to rotate the whole shutter assembly, but I think this is minor.
The actual mechanics of the fixture via DMX protocol happens below the abstraction layer in the fixture profile. Which means as a programmer you won't need to worry about how manufacturer A does it vs manucaturer B. The way you interact with shutters is always the same, regardless of the DMX protocol.:D
