GithubHelp home page GithubHelp logo

openlightingproject / open-fixture-library Goto Github PK

View Code? Open in Web Editor NEW
183.0 15.0 61.0 40.9 MB

A library and website for lighting technology's DMX fixture definition files.

Home Page: https://open-fixture-library.org/

License: MIT License

JavaScript 9.64% HTML 0.01% Vue 5.18% JSON 84.51% Markdown 0.40% Shell 0.01% SCSS 0.27%
dmx dmx512 lighting json vue nuxt nodejs rdm gdtf hacktoberfest

open-fixture-library's Introduction

Open Fixture Library
open-fixture-library.org

Mozilla HTTP Observatory Grade Beacon

OFL logo

To use lighting control software like QLC+, DMXControl or e:cue, you need fixture definition files that describe your lighting hardware. Since one software can usually only understand its own fixture definition format, switching between different programs can be difficult.

The Open Fixture Library tries to solve this problem by collecting fixture definitions and making them downloadable in various formats. Internally, it uses a JSON format that tries to bundle as much information as possible for all the different output formats.

Contribute without coding

The easiest way to help: Head over to the online Fixture Editor and add your favorite fixture that is not yet included in our library!

There are also other ways you can help without coding.

🙏 Help wanted! There are a lot of pull requests for new fixtures that are not yet reviewed and merged. Reviewing them (and maybe fixing smaller issues) helps get this number down and the number of fixtures in OFL up! See the step-by-step instructions for fixture reviews.

Contribute code

See CONTRIBUTING.md and our Developer Documentation.

open-fixture-library's People

Contributors

ameanomes avatar ashmotif200 avatar breina avatar cgbassplayer avatar dependabot[bot] avatar dyamized avatar firionus avatar floedelmann avatar fxedel avatar greenkeeper[bot] avatar hrueger avatar ilidur avatar jonahkr avatar kengruven avatar luc122c avatar martin3000 avatar moritzvieli avatar peternewman avatar petrvanekrobe avatar pr0gr8mm3r avatar rynr avatar sl1200mk2 avatar snyk-bot avatar swiftb0y avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

open-fixture-library's Issues

Switch to xml builder in xml export plugins

Currently, QLC+'s and e:cue's export is implemented by having a huge xml string and adding a lot of strings contained self-coded xml tags. This can look like this:

str += `                <Fixture _CreationDate="${fixCreationDate}" _ModifiedDate="${fixModifiedDate}" Name="${fixName}" NameShort="${fixShortName}" Comment="${fixture.comment}" AllocateDmxChannels="${mode.channels.length}" Weight="${modeData.physical.weight}" Power="${modeData.physical.power}" DimWidth="${modeData.physical.dimensions[0]}" DimHeight="${modeData.physical.dimensions[1]}" DimDepth="${modeData.physical.dimensions[2]}">\n`;

The disadvantages are obvious:

  • Bad readability: One tag should usually be one line in generated xml, but with lots of attributes, it's a very long line that isn't easy to understand (even with visual line breaks switched on)
  • You have to mess around with generated indentation
  • It's likely to make mistakes like forgetting a double quote for an attribute or forgetting the closing tag

We already use the xml2js dependency, so why not use its xml builder functionality?

E.g. this code:

const xml2js = require('xml2js');

let outputXML = {
    Document: {
        $: {
            attr1: 1,
            attr2: 2
        },
        SomeElementType: [
            {
                AnotherChild: [{
                    $: {
                        with: 'some',
                        more: 'attributes'
                    }
                }]
            },
            {}
        ]
    }
}

outputXML.Document.$.attr3 = 3;
outputXML.Document.$.attr4 = 5;
outputXML.Document.SomeElementType[0].$ = {
    val: 8
};
outputXML.Document.SomeElementType[1].TextElement = 13;

const builder = new xml2js.Builder();
console.log(builder.buildObject(outputXML));

prints this xml to console:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Document attr1="1" attr2="2" attr3="3" attr4="5">
  <SomeElementType val="8">
    <AnotherChild with="some" more="attributes"/>
  </SomeElementType>
  <SomeElementType>
    <TextElement>13</TextElement>
  </SomeElementType>
</Document>

Add plugin tests

The same input JSONs should always produce the same output UserLibrary.xml / *.qxf files.

Switching channels

The problem

Some fixtures have a channel that does different things depending on an other channel's value. "Different things" means that a specific DMX value has a different meaning (for example "rotation" vs. "speed"). It does not mean that a specific DMX value only applies if another channel has a specific value and else has no effect (e.g. "Red" = 147 has no effect if "Intensity" = 0).

Example

Have a look at the Martin MAC 700: https://www.martin.com/Martin.Download.aspx?file=/files/files/productdocuments/11_MANUALS/999/UM_MAC700Profile_DE_A.pdf
It has a gobowheel (rotatable, of course) with 6 gobos that can rotate themselves, too.

It has a Gobo channel (7) with these capabilities:

  • a) 1x Open
  • b) 6x Static Gobo
  • c) 6x Self-Rotating Gobo
  • d) 6x Static Gobo Shake (slow–fast)
  • e) 6x Self-Rotating Gobo Shake (slow–fast)
  • f) 2x Rotating Gobowheel (CW, CCW; slow-fast)

Slow-fast is the speed of goboshake or the whole gobowheel, not the gobo itself.

Then there's a channel (8) for the self-rotation of each gobo.

  • I.) If channel 7's value is in the range of a), b) or d), channel 8 simply defines the static gobo rotation angle (DMX 0 = 0° –> DMX 255 = 395°)
  • II.) If channel 7's value is in the range of a), b) or d), channel 8 has four capabilites:
    • No rotation
    • CW, slow-fast
    • CCW, fast-slow
    • No rotation

So channel 8 changes its functionality (and capabilities) when channel 7's value changes.

Lighting program support

e:cue and QLC+ don't support channels that change behavior depending on an other channel's value yet.

DMXControl 3

Notes: In DMXControl, dmxchannels start with zero. <step> or <range> are capabilities.

There's a special feature for gobowheels and prisms to difference between gobo/prism rotation (speed) and index (angle). For the Martin MAC 700, these functions can be implemented like this:

There are 6 <step>s in <gobowheel> (channel 7). Each of them defines with its attributes the static gobo capability (b), with one <step> the capability for self-rotating gobo (c) and with one <range> the capability for static gobo shake (d).

The capability for self-rotating gobo (c) has the attribute for="goborotation", which declares that channel 8's behavior II should be used. If this attribute is not set or set to goboindex, behavior I is used.

<goborotation> (II) and <goboindex> (I) define the different capabilities for the different behaviors of channel 8.

<gobowheel dmxchannel="6" >
  <goborotation dmxchannel="7" >
    <step type="stop" mindmx="0" maxdmx="2" />
    <step type="stop" mindmx="253" maxdmx="255" />
    <range type="cw" mindmx="3" maxdmx="127" minval="0.1" maxval="8" />
    <range type="ccw" mindmx="252" maxdmx="128" minval="0.1" maxval="8" />
  </goborotation>
  <goboindex dmxchannel="7" >
    <range mindmx="0" maxdmx="255" range="395" />
  </goboindex>
  <goboshake />
  <step type="open" caption="Open" mindmx="0" maxdmx="11" />

  <step type="gobo" caption="Spiral" mindmx="12" maxdmx="15" val="spiral.png" >
    <step for="goborotation" mindmx="36" maxdmx="39" />
    <range handler="goboshake" mindmx="60" maxdmx="71" minval="0.1" maxval="3" />
  </step>

  <step type="gobo" caption="Radial Circles" mindmx="16" maxdmx="19" val="radialcircles.png" >
    <step for="goborotation" mindmx="40" maxdmx="43" />
    <range handler="goboshake" mindmx="72" maxdmx="83" minval="0.1" maxval="3" />
  </step>

  <step type="gobo" caption="Fused Dichro Red/Yellow" mindmx="20" maxdmx="23" val="redyellow.png" >
    <step for="goborotation" mindmx="44" maxdmx="47" />
    <range handler="goboshake" mindmx="84" maxdmx="95" minval="0.1" maxval="3" />
  </step>

  <step type="gobo" caption="Milky Way" mindmx="24" maxdmx="27" val="milkyway.png" >
    <step for="goborotation" mindmx="48" maxdmx="51" />
    <range handler="goboshake" mindmx="96" maxdmx="107" minval="0.1" maxval="3" />
  </step>

  <step type="gobo" caption="Water" mindmx="28" maxdmx="31" val="Water.png" >
    <step for="goborotation" mindmx="52" maxdmx="55" />
    <range handler="goboshake" mindmx="108" maxdmx="119" minval="0.1" maxval="3" />
  </step>

  <step type="gobo" caption="Flames" mindmx="32" maxdmx="35" val="flames.png" >
    <step for="goborotation" mindmx="56" maxdmx="59" />
    <range handler="goboshake" mindmx="120" maxdmx="131" minval="0.1" maxval="3" />
  </step>

  <wheelrotation>
    <range type="cw" mindmx="229" maxdmx="204" minval="0.1" maxval="2" />
    <range type="ccw" mindmx="255" maxdmx="230" minval="0.1" maxval="2" />
  </wheelrotation>
</gobowheel>

(Possible) solution

We define the trigger channel (normal gobo) and both behaviors for channel 8 as three different channels (no real data):

"availableChannels": {
  "Gobo": {
    "type": "Gobo",
    "defaultValue": 60,
    "capabilities": [
      {
        "range": [0, 11],
        "name": "Open"
      },
      {
        "range": [12, 15],
        "name": "Gobo 1 (Spiral)"
      },
      // ...
    ]
  },
  "Gobo Rotation Angle": {
    "type": "Intensity"
  },
  "Gobo Rotation Speed": {
    "type": "Speed",
    "capabilities": [
      {
        "range": [11, 132],
        "name": "Fast-slow (CW)"
      },
      {
        "range": [133, 255],
        "name": "Slow-fast (CCW)"
      }
    ]
  }
}

Instead of using Gobo Rotation Angle or Gobo Rotation Speed directly in a mode's channel list, we define a switchingChannel that says when to use which channel.

"availableChannels": {
  // ...
},
"switchingChannels": {
  "Gobo Rotation": {
    "trigger": "Gobo",
    "channels": {
      "Gobo Rotation Angle": [60, 131],
      "Gobo Rotation Speed": [[0, 59], [132, 255]]
    }
  }
},
"modes": [{
  "name": "2-channel",
  "channels": [
    "Gobo",
    "Gobo Rotation"
  ]
}]

Schema would be changed like that:

+var Range = Array.of(2, DMXValue)
 
+var SwitchingChannel = schema({
+  '?name': [String, null], // null: use channel key
+  'trigger': ChannelKey,
+  'channels': schema({
+    '*': [Range, Array.of(1, Infinity, Range)] // '*' is the channel key of an switched channel
+  })
+});
+
 var Fixture = schema({
   // ...
   'availableChannels': schema({
     '*': Channel // '*' is the channel key
   }),
+  '?switchingChannels': schema({
+    '*': SwitchingChannel // '*' is the channel key
+  }),

Tests

What has to be checked in fixture-valid test:

  • Channel key must be unique between availableChannels and switchingChannels
  • A mode containing a switching channel must also contain the trigger channel
  • Channels mentioned in a switching channel must exist in availableChannels
  • Ranges in a switching channel must not overlap
  • A trigger channel must have the defaultValue attribute set (see later why)

Fixture editor

As soon as this feature is implemented, #77 will get a new item to support it in the fixture editor. At the moment, the fixture editor would not be broken as the switching channel is an optional additional feature. Until we implement switching channels in the fixture editor, we only have to prevent errors when an edited or imported fixture uses switching channels (but edit or import isn't implemented yet as well).

Exporting

The problem is that this feature is only implemented for gobowheels / prisms in DMXCreator 3. When using other channel types or other plugins, we need to decide how to deal with switching channels.

I'd propose to just always use one of the switched channels and ignore the other ones. This "default" channel is the one that would be used if the trigger channel was set to its default value (that's why it is required for trigger channels).

In the above example, "Gobo"'s default value is 60 which results in "Gobo Rotation Angle" being the default channel.

QLC+ output for above example

<Channel Name="Gobo">
 <Group Byte="0">Gobo</Group>
 <Capability Min="0" Max="11">Open</Capability>
 <Capability Min="12" Max="15">Gobo 1 (Spiral)</Capability>
 <!-- ... -->
</Channel>
<Channel Name="Gobo Rotation">
 <Group Byte="0">Intensity</Group>
 <Colour>Generic</Colour>
 <Capability Min="0" Max="255">0-100%</Capability>
</Channel>
<Mode Name="2-channel">
 <Physical>
  <!-- ... -->
 </Physical>
 <Channel Number="0">Gobo</Channel>
 <Channel Number="1">Gobo Rotation</Channel>
</Mode>

e:cue output for above example

<ChannelBeam Name="Gobo" DefaultValue="60" Highlight="0" Deflection="0" DmxByte0="1" DmxByte1="0" Constant="0" Crossfade="0" Invert="0" Precedence="LTP" ClassicPos="1">
    <Range Name="Open" Start="0" End="11" AutoMenu="1" Centre="0" />
    <Range Name="Gobo 1 (Spiral)" Start="12" End="15" AutoMenu="1" Centre="0" />
</ChannelBeam>
<ChannelIntensity Name="Gobo Rotation" DefaultValue="0" Highlight="0" Deflection="0" DmxByte0="2" DmxByte1="0" Constant="0" Crossfade="0" Invert="0" Precedence="LTP" ClassicPos="2" />

As soon as programs like QLC+ support defining multiple channels to be switched depending on another channel's value in a fixture definition file, we will change our export plugins. (It doesn't necessarily mean that a program uses the functionality in user interface but that there is a way to specify it and that it doesn't break current functionality). We are also willing to change our specification if it better suits to the implementation of another lighting software.

Problem with relative urls when index.js is not executed from same directory

Steps to reproduce

  1. cd fixtures - navigate in any subfolder of the repository's root (or basically any folder except the repository's root)
  2. node ../index.js - run the server from this folder
  3. There's an error when visiting localhost:5000: Error: ENOENT: no such file or directory, open 'fixtures/manufacturers.json' (and probably quite a few similar errors on other pages) - the server seems to use the wrong relative urls

Fixture Editor features

(when an issue is being worked on, tick the checkbox and specify the issue number)

Functionality

  • #228 fine channels
  • #563 Suggest common names after having chosen channel type (e.g. the "Red/Green/Blue" for SingleColor or "Color Wheel" for Multicolor) – thanks to @sl1200mk2 for the idea Implemented the other way round: Capability type is generated out of channel name, see also #601.
  • #89 Capabilities
    • #367 Capability wizard
  • #82 Unique mode identifiers
  • Only allow name as additional property for Nothing channels Obsolete with capability types.

Code style

  • #175 use UUIDs to reference channel keys, generate real keys only on submit
  • #175 only set channel name if it differs from channel key

UI

  • #365 Nice category chooser with icons and editable order
  • #361 Edit channel order

Validation

Maybe run fixture_valid test before submitting? Instead automatically spot errors and tell the user about them

  • #245 polyfill Constraint Validation API
  • #245 better error messages for capabilities and ranges (groups of fields that are tested together)
  • #245 prevent channel names to contain "fine", "16 bit", "MSB" etc.
  • #245 prevent manufacturer name at start of fixture name
  • #245 force uppercase channel names

Fixture editor

Submission adds a new pull request in this repository

Ditch manufacturerName in register

Since we have the manufacturer key here and always pass over the manufacturers object, we don't need to redundantly save the name here.

Improve font loading

We should avoid "flash of invisible text" and better use "flash of unstyled text"

We need more style!

  • Style capabilities (#335)
  • style details / summary (#335)
  • expand / collapse all (#335)
  • Add channel type icons and color (#335)
  • Style search page (#416)
  • Manufacturer page (website link) (#291)
  • Latest fixtures (save the 5 fixtures with the least createDate in register) (#271 and #274)

Add Avolites Plugin

They have a huge library!

Though it seems that they use multiple different formats (Diamond 4 .d4, Pearl/Azure/Sapphire .r20, Diamond II/Diamond III .d2, Sapphire 96 .r96, Visualiser .vis). Maybe they are so similar that we can combine them into one plugin?

fully implement all of e:cue's features

There are the attributes Deflection, Header, classicPos and classicEntry that are currently not or only partially implemented. See e:cue's explanation file somewhere in the installation.

cli-import.js does not work from other directories

$ cd tests
$ ../cli-import.js
module.js:471
    throw err;
    ^

Error: Cannot find module '[...]/open-fixture-library/plugins/tests/fixture_valid'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> ([...]/open-fixture-library/plugins/cli-test-dmxcontrol-import.js:5:22)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

display all fixture infos

  • meta (author & co)
  • revisions: GitHub link http://github.com/<username>/<project>/commits/<branch>/<path/to/file>
  • multibyte channels
  • heads

Make links to fixtures from manufacturer absolute

Links to fixtures from manufacturers (like in /cameo) aren't absolute, so they don't have a leading slash (e. g. cameo/thunder-wash-100-rgb instead of /cameo/thunder-wash-100-rgb).

This can be a problem if the url has a trailing slash (which should generate the same page) because relative links will then point to a non-existent subfolder. For example, in /cameo/, the first fixture's href is cameo/outdoor-par-tri-12 which results when clicking it in /cameo/cameo/outdoor-par-tri-12 which gives a 404 error.

Add meaningful tests

  • are all static pages available?
  • do unreachable pages throw a 404?
  • are the fixture files valid JSON?
  • are all fixtures listed in the right index structures?
  • are all short names unique?

fixture import / export tests are coming later

Diff fixture output when editing output plugin

For example when I change the qlcplus output plugin, it's likely that I made a mistake that changes the output in a way it wasn't intended. For that reason, it would be useful to have some kind of tool that diffs the outputted fixtures before and after my changes.

Fix grid layout in IE and Edge

calc((100% - 2rem) / 3) doesn't work with IE and Edge as it rounds the pixels up and the third item is a trifle too long so that it wraps into the next line. Possible solution: change to calc(33.33% - 2rem / 3)

Add search tests

Extend the HTTP test with various different combinations of query parameters

Personal library

  1. add fixtures to personal library
  2. bulk download all of them as a single zip file

make UI responsive

Header should collapse (logo and search in first row, other navigation items in the second row)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.