Jump to content
Light-O-Rama Forums

Third-party editor for LMS files


gspence

Recommended Posts

I'm writing an application that will edit LMS files so I can add some features that aren't available in S3. Has anyone worked on anything similar? Have you gotten any pushback from LOR or do they welcome this type of thing?

I can't imagine there would be any legal issues since I'm just modifying an XML file, but you never know.

Link to comment
Share on other sites

I have done some very basic manipulation of LMS files that I bring across from Light Show Pro into S3. LSP exports to LMS but has some issues, so I wrote a quick batch file macro to order the LMS the way I needed, and to correct a common sequence length error. I have no idea why LOR would mind any tools that improve the usability of their software and hardware, and I believe the SuperStar was an external application that LOR adopted into their S3 when they saw its advantages for RGB programming.

What features are you looking to enhance? Have you looked at Nutcracker which is also adding to the tool kit for LOR based systems?

Link to comment
Share on other sites

Myself and others have been doing this since LOR went to open xml. My public programs are here. They create config files, prop files, severa which create clipboard files, and show files. I have other private ones which create bitmaps from animations, rename channels, Look for config problems.

What kind of manipulation are you looking to do? There is talk almost every year about how hard it is to propagate config changes to all sequences for a new season.

I have two new ones planned for 2013 which will do new kinds of sequence effect generation.

Link to comment
Share on other sites

Rather than looking to make a bunch of individual tools that do specific things I'm actually re-envisioning the entire editor. There are a lot of things that I think would improve the usability of LOR and make creating files much easier. Realistically I don't see them implementing a lot of it just because I send it to wish list. However, I think when they see the finished product they'd probably like a lot of it. I don't want to run down the entire list of changes until its closer to being done but I'll talk about a few things.

- Changes to selection: Rather than selections always being locked to the timing grid, I have the ability to also do freeform selection (no snapping) as well as snapping to events like start/end of fades, etc. This can be done independant of the timing grid.

- I'm adding a lot of adjustment features to allow you to make changes to your current selection. This is akin to how you might adjust layers in Adobe Photoshop. I'm adding things such as intensity changes that will preserve the relationship of the selection, but apply a blanket intensity change to all events. I'm also adding something similar to compression in an audio editor where you can adjust max/min levels of a selection without affecting anything that falls within those values.

- I'll probably add some histogram/level graphs similar to Photoshop that will let you adjust brightness and color curves visually.

- Working in RGB will be more similiar to painting with an easily accessible color palette. Things like fades will be done with modifier keys rather than separate tools so painting a fade up/down can be done in a single stroke.

- Fill tools will work more like Photoshop as well, where you can specify gradiants including alpha values so you can fill with fades. One of the thing that has always bothered me about the LOR fill tool is that it goes all the way back to the last event regardless of your selection. My fill tool will work on your selection so you can fill an arbitrary area. If the event prior to your selection is empty, it will just fade down.

Way too much else to list here, but as you can see it mostly has to do with usability. Nothing against the LOR guys, but the interface feels like it was designed by a programmer. It's hard for programmers to step outside of their world and think about how a user wants to interact with things. We typically think about usability in terms of what we are trying to do with the data behind the hood. Most of the time the users don't care about how that data is stored, so to force them to think about fades and effects as descreet events isn't intuitive to me.

Anyways, I don't want this thread to seem like I'm bashing LOR because its far from that. They have done an awesome job and if not for them this hobby wouldn't be what it is. I think that LOR, in general, is a great piece of software. It's just not exactly how I would have designed it so I want to give my ideas a shot.

I'd definitely love to get some feedback from you guys when I'm ready and work closely with people that have large displays to be sure that I'm addressing issues that other people have as well.

  • Like 1
Link to comment
Share on other sites

Keep in mind that LOR can (and does) update their file content on a regular basis. Almost every time a new feature is added it requires additional info to be stored in the file. Keeping up with these changes and possibly supporting multiple file versions could be a lot of work.

This is the biggest reason I’ve stayed with version 2. I haven’t had time to properly address the channel grouping, etc. in the newer file versions and I value my tools more than the added features.

Link to comment
Share on other sites

Keep in mind that LOR can (and does) update their file content on a regular basis. Almost every time a new feature is added it requires additional info to be stored in the file. Keeping up with these changes and possibly supporting multiple file versions could be a lot of work.

This is the biggest reason I’ve stayed with version 2. I haven’t had time to properly address the channel grouping, etc. in the newer file versions and I value my tools more than the added features.

Not really The xml tags have been pretty stable. S3 can create a file nearly readable by s2. IFthe s3 sequence does not have any groups. I think you can just change the fileversion back and it will work. All the other things remembered are in other files.
Link to comment
Share on other sites

I, too, learned to hack the XML files this past year. I wanted to convert my old conventional Mega-Tree sequences, which were 36 channels in 3 colors, to my new Pixel mega-tree, which was 1536 RGB channels (4608 actual channels). So I wrote a python script that did the conversion, and built up groups, a couple different tracks, and assigned all the DMX channels properly for me, saving me a ton of work.

This all gave me a baseline where I could run my old sequences on the new tree and it would work. Of course the resulting sequences didn't take advantage of the pixels at all, so then I went through and added pixel effects where desired.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...