Importing Channel Configuration File, with Tracks

[Amie]

I've gotten pretty good over the years at keeping my main track the same on adding new channels at the bottom only. I call the track, Transfer Track - Don't Touch This. I keep this track closed all of the time, except when I need to add new channels at the bottom. Then my 2nd track is called, Working Track, which is always an exact duplicate, but rearranged every year to how I like it.

I am not sure how everyone else does it, but I have a total of 19 tracks now, split up so I can handle the 256 channels we have this year. What I would like to understand is how LOR handles tracks when I do an 'Input Channel Configuration' into an old song that I did a few years ago. The first track is fine, and everything seems to look okay at first glance, but the tracks are messed up. I now have all the same names of tracks that the new channel configuration has, but they all have extra New Channels in them (some 2, some 4) and some of the channels have additional channels that shouldn't be there from the main track.

Should I be paying more attention to what the tracks look like? Are they supposed to be exactly the same? For some reason, I thought that it didn't matter.

Thank you.
Amie

[bob]

Well, it's pretty complicated.

The short but not-entirely-accurate explanation is that the settings of the first channel of the first track of the config file are applied to the first channel of the first track of the sequence, those of the second to the second, and so forth.

The complicated but hopefully more accurate explanation is this:

Step 1: All tracks in the sequence are "flattened" down to just channels (i.e. get rid of channel groups, RGB channels, and the like, replacing them with their constituent channels). This is done in a depth-first manner, and if any channel is in multiple places within the track, those copies of that channel other than the one first encountered are ignored.

Step 2: If, after flattening the tracks, any channel is in more than one track, it is removed from all tracks except the first track that it is in.

Step 3: For each track in the channel config file, starting with the first and going to the last, the following happens:

Step 3-A: The track is flattened (similarly to how this was done in the sequence in Step 1).

Step 3-B: If there is no track at the corresponding position in the sequence, a track is created there.

Step 3-C: Some track settings (such as the track's name) of the sequence's track are set to those of the config file's track.

Step 3-D: For each channel in the config file's track, starting with the first and going to the last:

Step 3-D-i: If this channel has already been mapped to some corresponding channel in the sequence, that corresponding channel is inserted into the corresponding track in the sequence at the same position as the config file's channel is in the config file's track.

Step 3-D-ii: Otherwise, if there already is a channel at the same position in the corresponding track of the sequence, that channel is mapped to this channel from the config file, and its settings (such as unit ID) are set to those of this channel from the config file.

Step 3-D-iii: Otherwise, a new channel is created at the same position in the corresponding track of the sequence, that new channel is mapped to this channel from the config file, and its settings (such as unit ID) are set to those of this channel from the sequence.

Step 4: For each track in the channel config file, starting with the first and going to the last, the nesting structure of the corresponding track in the sequence is built as follows:

Step 4-A: The track from the config file is "unflattened"; i.e. the flattening that was done in step 3-A is undone.

Step 4-B: For the corresponding track from the sequence file, any channel, channel group, RGB channel, etc. that was mapped to by some channel (etc.) of the config file is removed from the track, leaving only those that were not mapped.

Step 4-C: For each channel, channel group, RGB channel, etc. that is in the track from the config file, the following happens:

Step 4-C-i: If the channel (etc.) was mapped to some corresponding channel (etc.) in the sequence, the corresponding channel is inserted into the sequence's track at that same position.

Step 4-C-ii: Otherwise, a new item of the same type (e.g. RGB channel for RGB channel) is created and added to the sequence's track at the same position, mapped to by the one from the config file, and its settings (such as its name) are set to those from the config file. Then, for this new item, we go back to step 4-C, acting upon it rather than upon the track, thus building its nesting structure.

Step 5: The sequence's animation is set to be like the config file's animation.

Step 6: If, after all of that, there are tracks in the sequence that contain no channels, RGB channels, channel groups, and so forth, all such tracks are removed from the sequence.

[Amie]

Sorry, I am just getting back to this topic. Thank you for responding and WOW, that is not at all how I thought tracks were handled.

Our light show is on hold because of the issues we are having because of tracks. I think the issues started with the previous version of the software, but I am still trying to fix the mistakes it created and the programming I lost because of it.

For some reason I had it in my mind that the first track was the only track that could contain unique channels and that every other track could only contain duplicates of channels from track 1. That way, when working in any of the tracks, your work would always reflect back into the channels in the first track.

The problem I am having I think started when I was using the last version of LOR (3.0.?)/ Additional channels were being created in tracks and I didn't realize that they were not the same as the channels located in the first track. When I wrote the programs, using tracks, it was not being reflected back into the first track, or the 'real' channels that I had assigned box unit and channel numbers to. These new 'fake' channels were blank, without any connection to any box. When I finally ran the songs outside, 1/2 of the things I programmed are missing and I have been digging through, trying to figure out why.

Looking at the xml code, I find that one channel will have several different savedIndex numbers if I have it located in different tracks.

I realize that there isn't anything that can be done about my mess. I'm just going to have to fight my way through each song and hope I can recreate them quickly without going insane. I'm just frustrated, that's all. Really, really frustrated.

[Amie]

In looking through my lms files, I think the current version of LOR, version 3.1.2, is still creating problems for me. Unless I really don't understand how the saveIndex works ... which is possible.


I have a megatree with 32 channels on it, 16 red and 16 white. I've called the red channels 'megatree red 1' through 'megatree red 16' and the white channels 'megatree white 1' through 'megatree white 16'. When I search in the xml file for 'megatree red 1', I get the following:

Line 2477:         
Line 3719:         

When I search for 'megatree white 1' I get the following:

Line 6210:         
Line 6499:         
Line 7017:         

Both the red and the white megatrees are located in 4 tracks. The only difference between them is that in the first track, I have grouped the megatree red 1-16 together and have not grouped the megatree white1-16 together. I've treated them the same in all of the other tracks.

I have this issue with quite a few of my channels, this was one example.