I have a very old showfile which I've just updated to use the v3.0.2 fixtures in order to make Augment3D work. As you might imagine this is causing a bit of pain.
One very particular question relating to this: are there any 'in house' (at ETC or at Carallon) rules as to which speed/beam time parameters are used?
For example, this show has VL3500 Spots and VL3000 Wash fixtures.
Both have a beam time parameter controlling (amongst other things) the beam size - 'Zoom'.
On the VL3500 Spot, the current fixture has this as 'Beam MSpeed/Beam MSpeed Mode'. (The current VL1000AS fixture has the same thing).
But the VL3000 Wash fixture uses 'Zoom MSpeed' and 'ZoomMSpeed Mode'.
Given that these are the exact same fixture family, these should surely all be using the same - probably Beam MSpeed - parameters?
(I know I could just edit this to fix it, but that now breaks being able to easily move to updated fixtures in the future; it would also involve some careful juggling of parameters to make sure the information could now transfer across safely).
Also, while we're on the subject, please could we raise the subject of all the 'MSpeed'-type parameters just going into their own 'timing' category so they're not always getting jumbled in with the actual parameters for each category (pan/tilt, edge, zoom etc).
'Color MSpeed' vs 'Color Mix MSpeed' is the other one where there seems to be inconsistency...
Howdy Rob -
As I'm sure you know, certain fixtures use their MSpeed to set timing on various parameters - and even in the same fixture family, the parameters controlled can be different.
Carallon gives us information about which parameters are under the control of a particular MSpeed: VL3500 Spot: DMX 29 = Zoom MSpeed, Edge MSpeed, Frame MSpeed VL3000 Wash: DMX 15 = Zoom MSpeed
Eos uses that information to give names that are legible, and describe the category, subcategory, or parameter being controlled. The VL3500 Spot is called "Beam MSpeed", because the parameters controlled span multiple subcategories of Beam. Were it just Zoom and Edge, we would label it "Form MSpeed". And if there is a single parameter being controlled (like the VL3000 Wash), we name it for just that parameter. It isn't a perfect system, but it allows us to show a reasonable parameter name that is semi-indicative of the parameters affected.
I do think we can look at some category additions/rearrangements in the future - fixtures have evolved, and we know there can be some improvements in our current structure. Those conversations are a bit off yet however, as that has massive implications throughout the system.
The two practical issues, using this VL3500Spot/VL3000Wash together in a show as an example, are:
- I want to use the speed channel to control a live size (zoom) change on a VL3500Sp and a VL3K Wash together. But I have to select and manage two different speed parameters to do it.
- The manual parameter soft keys on the main Eos touchscreen just get cluttered with more and more parameters. This is made worse by the fact that these Mspeed channels are now often (but interestingly, not always) actually split into two parameters - an MSpeed and a (virtual) MSpeed mode.
If I was using VL3500s on their own or VL3000Washes on their own, your argument would sort of make sense (except that in both cases Vari-Lite call it Beam MSpeed). It's using them together where it becomes an issue.
The workaround always used to just be to re-make the parameter to whatever suited (ie. I'd have re-made the Zoom MSpeed as Beam MSpeed, and I'd standardise all of the ColWheel/ColMix/Color MSpeeds to be just Colour MSpeed), but that's harder in the world of Augment, and particularly when these modes are split into two different parameters on the console.
Talking of which, this show also has Revolutions, where the MSpeed parameter is just one MSpeed parameter, not an MSpeed and MSpeed Mode parameters. Why is this case different from the VL3500s...?
I totally understand the issues with multiple fixtures introducing multiple parameters, and making them difficult to control together, as well as the clutter it introduces. We can also check on Revolution - I know our code does a lot to auto-parse the data we receive, so I can't definitively answer why it doesn't get a Mode parameter as well.
I also agree this is an area we can make great improvement - my previous answers were not "this is how we want it," they were "this is how it is." We've got a lot of work to do in profiles/parameters, and Augment3d has only magnified the existing issues. We're starting some of those conversations internally this year. It'll be a slow boat to turn, but we will engage folks when we have some ideas of where we want to head, potential roadblocks, etc.
Thanks for the feedback, I'll bug you when we're ready to get into it in earnest.