Giter VIP home page Giter VIP logo

fixture-converter's Introduction

DMX Fixture converter

๐Ÿšซ DISCONTINUED!

โžก See Open Fixture Library for successor project.


Creating fixture files is relatively easy for most DMX control software, as they offer graphical editors for their proprietary formats. But what if you want to try another program?

For this purpose, I created this little script that uses a JSON file to store all fixture data. Other files may be generated from this format or imported into it.

Supported formats

Internal JSON

See fixtures_defaults.js or look at the fixtures/ directory to learn how the JSON structure used by this script looks like.

e:cue (ecue)

Import: Yes
Export: Yes

Website: http://www.ecue.com/

Where do I find my previous fixture definitions?
Main Library: C:\ProgramData\ecue\Library V7.0\MainLibrary.xml
User Library: C:\Documents and Settings\[Your User]\AppData\Local\ecue\Library V7.0\UserLibrary.xml

QLC+ (qlcplus)

Import: Yes
Export: Yes

Website: http://www.qlcplus.org/

Where do I find my previous fixture definitions?
Main Library: /usr/share/qlcplus/fixtures (Linux)
User Library: ~/.qlcplus/fixtures (Linux)

Dependencies

Node.js Modules:

npm install

Usage

./fixtures_convert.js --help lists all possible options.

Note: This script uses destructuring. For older versions of Node.js, you will have to use node --harmony_destructuring fixtures_convert.js --help.

Examples

Typical use: ./fixtures_convert.js -f qlcplus
formats fixtures.json as QLC+ and writes the resulting fixture definition .qxf files to out/qlcplus/

Import: ./fixtures_convert.js -i UserLibrary.xml -f ecue -o out/%FORMAT%/%MANUFACTURER%.json
imports UserLibrary.xml as e:cue format and writes the resulting JSON files (separated by manufacturer) to out/ecue/%MANUFACTURER%.json

Contributing

Feel free to add your own output formats and / or fixtures. Just create a pull request!

New fixtures

Possibly, the best way is to create a fixture definition in QLC+'s fixture editor (try to fill in all possible information) and then import it using ./fixtures_convert.js -i myfile.qxf -f qlcplus. The resulting JSON file in the out directory will probably contain some errors (especially when importing 16bit channels), so check it against the fixtures_default.js. Please also include a manual URL so that somebody can check your new fixture.

New formats

Each format module may look like this:

// required
module.exports.defaultFileExt = 'xml';
module.exports.defaultFileName = '%MANUFACTURER%-%FIXTURE%.xml';

module.exports.formatName = 'e:cue'; // optional

// both functions are optional
module.exports.export = function(manufacturers, fixtures, optionsOutput) {
    // optionsOutput contains the -o command line parameter with %FORMAT% already replaced
    ...
}
module.exports.import = function(str, filename) {
    // str is the string to be parsed, filename is just for helpful error messages
    ...
    // use a promise to allow asynchronous return values
    return new Promise((resolve, reject) => {
        ...
        resolve(objectToConvertToJSON);
    });
}

// optional
function privateHelperFunction() { ... }

Save it as formats/[formatname].js. Your module will automatically hook into the main fixtures_convert.js, so you won't have to bother with command line arguments.

fixture-converter's People

Contributors

floedelmann avatar fxedel avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

yasdfgr

fixture-converter's Issues

DMXControl import / export

See file structure here: v2 and v3 (I don't know if there are notable differences)

We will have to deal with the user interface that's embedded for each fixture. No idea how we get that working...

Handle imports relative to source

When using an input file that isn't in the current directory (e. g. ../fixtures.json) and it contains imports (e. g. fixtures/adj.json), the imports should be handled relative to the input file (e. g. ../fixtures/adj.json) and not to the current directory.

missing manufacturer data when using e:cue import with %FIXTURE%

Steps to reproduce
Import the same ecue file, one time with using %FIXTURE in the -o parameter, one time without and compare them.

./fixtures_convert.js -i tests/desired_out/ecue/American-DJ-Quad-Phase-HP.xml -f ecue -o American-DJ-Quad-Phase-HP-with-manu.json
./fixtures_convert.js -i tests/desired_out/ecue/American-DJ-Quad-Phase-HP.xml -f ecue -o American-DJ-%FIXTURE%-without-manu.json
diff American-DJ-Quad-Phase-HP-with-manu.xml American-DJ-Quad-Phase-HP-without-manu.json 

Result:

2,7c2
<     "manufacturers": {
<         "American DJ": {
<             "name": "American DJ",
<             "website": "http://www.adj.com/"
<         }
<     },

---
>     "manufacturers": {},

Conclusion: %FIXTURE makes the importer "forget" the manufacturer data.

User Interface

Command line is scary / not usable for many people. An UI program would help here.

Let Travis generate all output formats

By just calling node fixtures_convert.js -i fixtures.json -f ecue and node fixtures_convert.js -i fixtures.json -f qlcplus, we could spot errors in the fixture definition JSONs.

Test suite

A test suite would help finding errors in format import/export.

Possible test case: Given an e:cue library.xml, test if consecutive import and export creates the same file again.

Make color recognizing performant

Importing large e:cue files with color recognition (#14) enabled is very, very resource intensive. Maybe find a better way, e.g. a kind of binary search for colors.

Test import

Implement similar to export: Run import commands and check if created files match desired output.

Mention UI in Readme.md

... as I needed some time to discover the command to launch electron:

foo@bar:~/fixture-converter/ui$ ./node_modules/electron/dist/electron .

It would be easier if this would be mentioned in the Readme.

e:cue reimport: handle multiple modes

Problem

e:cue doesn't support modes, so a fixture with different modes is exported as multiple fixtures with "(mode)" appended to the fixture name. So when reimporting a library with fixtures of multiple types, it results in multiple fixtures (and not the more cleaner version of one fixture with modes).

Possible solution

When exporting, add xml attributes for full fixture name and full mode name => will be ignored by e:cue (hopefully), but can be used when reimporting.

Test errors

Check if program discovers the error and throws right exception / sends right console output. Maybe needs to revert #22?

  • non-existent format
  • non-existent input file
  • non-readable input file
  • malformed input file
  • non-writable output directory/file

Custom output file names

Current situation

  • ecue: one file "UserLibrary.xml"
  • qlcplus: multiple files (one per fixture) "manufacturer-name-fixture-name.qxf"
  • import: one file "import_YYYY-MM-DD_HH-MM-SS.json"

Enhancement
It would be useful to specify what the output file is by some reasons:

  • avoid overwriting existing output files, especially when exporting different sets of fixtures to ecue
  • don't have to search for or guess the output file name without reading console output, especially the test script

Implementation

  • Additional comman line option "-X filename" where X is a good character (not "o", it's already used)

Problems

  • What to do with qlcplus, which has to create multiple files? Ignore the option? Force using a placeholder (e. g. "%FIXTURE%") when using qlcplus?

Test command line outputs

Check if Handling %FORMAT% formatting... (if exporting) and all File "%OUTPUT%" successfully written. are correctly printed.

Handle slashes in file name

They should be replaced before writing file because we want one fixture / manufacturer / combination to be contained in one file, not one folder / file.

Package UI app

package the app into a single executable that starts the UI

auto build packages for every version change

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.