Fixture definition.

[jfitzpat]

Which sounds somewhat sensible. Obviously implementation starts to get slightly tricky then, but I think a construct such as can do more than any console currently on the market can (correct me if I'm wrong).

 

Well, we implement this now... :) The implementation of 'mode' is not trivial (for that matter, reversed faders are tricker than you might think), but I think it is worth it. Where it really pays off is when you want to have the ability to mix and match looks at random - IE, I can fade from cue X to Y, X to Z, Z to Y, and etc. and all selected features on all the fixtures transition gracefully.

 

I've always considered this important, because I think it impacts the flexibility of the system and efficiency in cueing/show programming in so many ways. This criteria, the ability to mimic old fashioned additive behavior with even very complex fixtures and features (like a Catalyst), is why we went to the trouble to make our 'effects generation' (movement generation) both open ended in terms of concurrency and morphing. If you need to leap ahead from a scene with some fixtures doing a large, slow spiral to one with the same fixtures doing some small, fast triangles, the crossfade needs to be smooth and graceful, regardess of fade time. This was important to me from a usage perspective and, if nothing else, it let me apply use the vector graphics stuff I had to learn for LaserMedia years ago. ;)

 

But again, even though the larger picture is a little moot (if you want to create a fixture 'template' on our system you use a graphical editor and property pages, much like Visual Basic) - I think that the concept of mode is well worth implementing for the playback feature benefits alone.

 

-jjf