Merge fixtures from separate shows

[DHoude]

Is there an easy way to merge Lights from other workspaces? I have some lights that I acquired from one workspace and would like to add all that work to another workspace that was already established too.

I know I could start adding the fixtures with the least amount of scenes to a the set with the most amount of scenes to avoid some work. But some of these fixtures have a few hundred scenes. And merging the workspaces with XML is just not user friendly. I can do it and I learned the XML structure, but from what I can tell/read the whole Function ID field has to be grouped somehow to prevent ID conflicts. For example, in my case, one fixture's group of functions could be 0-399 and the other fixture could be 400-699. Then after I change all the function IDs to prevent conflicts, I break the chasers in Virtual Console. Which is again, fixable. But...

There just has to be an easier way to combine fixtures from other established shows / workspaces. I once used a software that had all the Fixtures and scenes as separate XML files and grouped by folders. You could just copy the child folders (or files from those folders) of a one show into the parent show folder (or folder structure) and that was it! Even that was a little advanced for most users, but still very manageable.

[vector]

I can't help but I do feel your pain.
I tried some similar things a while back, dug around in the xml a bit too. Some of it worked some of it broke. Sounds like you got further than me.
What were you using to manipulate the xml? python scripts? The answer may well be to strip out the xml into separate parts, remap using tokens and then re stitch it. Easy to say not so easy to do.
I can think of many reasons why a nice xml to database viewer/editor would be useful.

I think I tried baseX at one point but couldn't work out/have the time to drive it.

[Solander]

Is this a feature more people want? I've been looking into how to contribute to the project and maybe I write a stand alone applikation for this if more people wants it.

If this feature is not implemented in version 5 that is..

[vector]

Well +1 from here . I think its worth a look at at least.
My types of lights stay the same but configurations change with different venues. I thus spend a lot of time creating the QLC workspaces for them.
Cutting and pasting globs of text from the files and carefully keeping track of and modifying the ID numbers is not for the faint hearted.
There are a number of things I feel would be of use if we could "unpack" the xml into a database type interface, query, modify then pack it back up for QLC import.
Would be appreciated.

[SPS]

+1 for me!

[Franzi]

+1

[mcallegari]

QLC+ import function is already available in QLC+ 5.
It's "just" a matter of reaching a usable state and release it.

[Solander]

Sounds great if it's already implemented!

[orrinc]

YES- an XML Editor would be wonderful!!

I'm having a similar issue with some duplicate ID numbers! Are there any rules about ID numbers (other than they need to be non-duplicate)?
Is there a limited range of ID numbers?
Can there be overlap between, for example, a button and a chaser?
Can numbers be randomly assigned?

Somehow, in editing an XML file, I ended up with buttons that had the same ID's as chasers! Not sure how that happened, or if it's the reason some buttons stopped working!

Thanks!

[sandinak]

SO I have some of this functionality in the qlcplus-tools. Coming up on a nice stretch of time to work on stuff like this .. i'll make a discrete tool and post here. (created a PR .. please expand if you have thoughts ) In the meantime.. here's some things I know re: qlc xml:

• Fixture IDs must not conflict ( sort of obvious )
• Fixture IDs do not need to be in numerical order
• Fixture IDs must be consistent throughout the whole file

So .. I have some tooling that generates matrixes and I usually start somewhere north of a number of fixtures i know like 10000. This way I know I won't conflict with any existing fixtures.

The most major issue with merging will be consistency in scenes and such .. but there will be others... like DMX addressing and such. Does sound like a fun challenge tho

[GGGss]

Nice idea - I already posted a IMHO on github.
Somehow QLC+ has to know the highnum for next scene, fixture, schnick-schnack ... so if you could find out the logic behind, you would not be forced to use ID's @10000+...