In OFL, we optionally store manual URLs. Detecting broken links is done with a test script that runs with Travis and posts a GitHub comment if a manual url is broken - if it remains broken for a few days, we search for an alternative, and if we can't find an alternative, we'll remove the url sometime. Having a reference to the manufacturer's instructions about a fixture is pretty useful. For example, when we extend our format to be more exact / specific, we can quickly find the manual and examine the exact information. And as an end user, it's useful to know where to quickly look up if there's something unclear when (physically) installing a fixture (however, this might be an OFL-specific point). In my opinion, the only disadvantage against an optional manual url are spammers / advertisers, which seems to be a big problem with QLC+'s fixture proposals.
In general, unit tests for fixtures (that run with Travis and are required to pass) are a valuable component. It helps you detect broken fixture definitions: Right after creation, but also over time when new features are added and/or fixture requirements/regulations have been changed. Think about the dependent channels: They might make fixtures a bit more complicated and decrease the chance to spot errors by hand. Maybe it's also possible to warn about possible optimizations (like replacing a channel with a preset).
The xml schema plays an important role here as it declaratively describes how a fixture should look like. It therefore catches many possible errors using an easy-to-read format. Some requirements (like correct usage of channel names) have to be checked with an extra script. I know there's already a script that checks all fixtures against the schema, but as far as I know, it's not a required Travis test and the console output wasn't very readable to me. Anyway, that could be a good starting point! I can help implementing this point, if wished, as it doesn't require much background knowledge about how the QLC+ engine and UI work (or does it?)
The capability presets and the new possibility to define a "value range" that describes a physical entity is quite interesting. You know that we're also thinking on this topic, but haven't found a solution yet. We'll keep you informed on what happens with this topic on our side.
As of dependent channels: I'm really looking forward to seeing this feature in QLC+ fixture definitions! Just a small note:
Code: Select all
<Alias name=”Sound sensitivity” number=”7” />
would set the mode's 7th channel to "Sound sentivity", right? So we'd declare something mode-specific in a mode-unspecific scope, or in other words, the channel only works in some modes, and has to be duplicated to work in other modes in which "Sound senstivity" would be the 9th channel, for example. See
cameo Hydrabeam 300 as an example that uses a switching (dependent) channel at different mode positions. I'd suggest introducing a placeholder channel (that may resolve to a default channel) and can be overridden by aliases, like so:
Code: Select all
<Channel Name="Program Speed / Sound Sensitivity">
<Group Byte="0">Placeholder</Group>
<Default>Program Speed</Default>
</Channel>
<!-- ... -->
<Channel Name="Auto Programs">
<Group Byte="0">Effect</Group>
<Capability Min="0" Max="10">No function</Capability>
<Capability Min="11" Max="50">Program 1</Capability>
<Capability Min="51" Max="100">Program 2</Capability>
<Capability Min="101" Max="255" Preset=”Alias”>Sound active
<Alias set="Program Speed / Sound Sensitivity" to=”Sound sensitivity” />
</Capability>
</Channel>
<!-- ... -->
<Mode Name="8bit">
<Physical><!-- ... --></Physical>
<Channel Number="0">Pan</Channel>
<Channel Number="1">Tilt</Channel>
<Channel Number="2">Auto Programs</Channel>
<Channel Number="3">Program Speed / Sound Sensitivity</Channel>
</Mode>
<Mode Name="16bit">
<Physical><!-- ... --></Physical>
<Channel Number="0">Pan</Channel>
<Channel Number="1">Pan fine</Channel>
<Channel Number="2">Tilt</Channel>
<Channel Number="3">Tilt fine</Channel>
<Channel Number="4">Auto Programs</Channel>
<Channel Number="5">Program Speed / Sound Sensitivity</Channel>
</Mode>
Is the preset Alias really needed then? The existence of the Alias tag(s) already declares that this capability changes the dependent channel. A unit test should ensure that a placeholder channel is only affected by a single other channel (only "Auto Programs" changes the behavior of "Program Speed / Sound Sensitivity"). Maybe add a information in the placeholder channel about the "trigger channel" (= Auto Programs), or move the placeholder channel declaration into the channel tag, as they are strongly connected to each other?
)
