2.4.10: Export/Import Channel Improved? Confused?

[Jeremy Wiles]

In version 2.4.10 the following has changed (from the help file):

Exporting/Importing Channel Configuration with Tracks Improved

In previous versions of Light-O-Rama, exporting and importing channel configuration from and to sequences that have more than one track could lead to strange, and probably undesired, results. This was due to the interaction between channels that were in more than one track of the sequence and channels that were in more than one track of the configuration file. If the positions of such channels did not match up between the sequence and the configuration file, then the resulting settings of those channels would be changed in a predictable, but probably undesired, way.

In this version, the method of importing has been altered, so as to give (hopefully) better results:

Unlike in previous versions, the first step to importing channel configuration, before any channels are actually imported from the configuration file, is now to check the sequence for channels that are in more than one track. If any such channels are found, then all copies of each channel, except for the first of each channel, are removed from the sequence.

Next, channels are imported from the configuration file. But unlike in previous versions, if a channel is in more than one track of the configuration file, instead of overwriting the settings of an existing channel in the sequence every time the channel is encountered in the configuration file, that is only done on the first encounter of the channel. Instead, on subsequent encounters of the same channel, a copy of the appropriate channel from the sequence is inserted into the track at the appropriate position.

This has two potential side effects to watch out for (although both of these seem minor compared to the side effects caused in previous versions):

First, if a track in the sequence is composed entirely of channels from previous tracks, and the channel configuration file has no track in the same position, then all channels will be removed from that track. Since the track has no channels, it will then be removed from the sequence. However, note that these channels have not been removed from the sequence - they have only been removed from the track. They are still in the earlier tracks.

Second, a channel from the sequence with no corresponding channel in the configuration file could get "pushed down" towards the bottom of the sequence's track, if the channel configuration file contains channels in that track which are copies of channels from earlier tracks.

Anyone else as confused as I am? Anyone care to take a stab at explaining this in different terms? What exactly do I need to watch out for to avoid the "side effects"?

[bob]

Sorry for the confusion. I think the high level summary is: depending on your sequence and your config file, there might be a couple things that happen that might not be exactly what you expect, but (in my opinion) they're not really all that big a deal, nor anything to really worry about. They won't cause any problems for your sequence.

And they're definitely not problems to anywhere near the extent of the problems that could be caused in older versions of the software. Depending on your sequence and config, the older versions of the software could do some really wacky things.

With all that said, here's a shot at explaining what the potential "side effects" are:

Take a look at the attached sequence, "expfrom.las". It's got three tracks.

In the first track is a blue channel, "1.1", for unit 1, circuit 1.

In the second track are two channels: a copy of the channel 1.1 from the first track, and a red "2.2" channel.

In the third track is a copy of 2.2 from the second track.

Make some change to channel 1.1 in the first track - for example turn a cell on. Note that the same change is automatically made in 1.1 of the second track. This is because they really are the same channel, just different copies in different tracks. You can similarly convince yourself that the two "2.2" channels really are the same channel as each other.

I will continue this explanation in another reply, because I don't understand how to get the forum to let me attach more than one file to a single reply.

Attached files

expfrom.las

[bob]

Now check out the sequence that's attached to this reply ("impto.las"). It's got four tracks:

The first track contains a yellow "3.3" channel.

The second contains a cyan "4.4", and a copy of 3.3.

The third contains a green "5.5".

The fourth contains a copy of 5.5.

Like you did for "expfrom.las", make little changes so as to convince yourself that the two "3.3" channels really are the same channel, and that the two "5.5" channels really are the same channel.

Now, note the thing that used to cause all sorts of wacky problems: The order of the "shared" channels in expfrom is different than the order of the shared channels in impto.

For example, the first channel of the second track of expfrom is the same channel as the first channel of its first track, and the second channel from its second track is a copy of the first channel in its third track. But that doesn't match with impto:

In impto, the first channel of the second track has no copies anywhere else in the sequence. And the second channel of the second track is a copy of the first channel in the first track.

For now, don't worry about what kinds of problems this sort of mismatch used to cause - I'll explain that later. Just note, for now, that there is this sort of mismatch between the two sequences.

Again, I will continue this explanation in another reply.

Attached files

impto.las

[bob]

Now, let's say you that you're using the new version of the software, and you export the channel config from expfrom.las, and import it to impto.las. The result will be the file that I am attaching to this reply ("impto-imp.las"). Compare it to both expfrom and to impto, track by track and channel by channel:

The import changed the first channel of the first track to blue 1.1, just like in expfrom.

In the second track, it made the first channel be a copy of blue 1.1, just like in expfrom. But note that it didn't simply change the first channel of impto's first track - for example, note the effects in the channels:

Originally, in impto, the first track's had an on event from time 0.40 to 0.70. The first channel of the second track had an on event from 1.00 to 1.50.

After importing, in impto-imp, the first channel of the second track now has an event from 0.40 to 0.70, just like the first channel of the first track. This is because it really is the same channel as the first channel of the first track, just like in expfrom.

So the import didn't change the settings of the existing first channel in the second track; rather, it inserted a brand new copy of the first channel from the first track. Just like in expfrom.

Make some small change to convince yourself that the first channel of the first track of impto-imp is really the same channel as the first channel of its second track.

Now take a look at the second channel of the second track of impto-imp. It's red 2.2, just like in expfrom. It's got an on event from 1.00 to 1.50, just like there used to be in the first channel of the second track.

So that's potential side effect #1: The first channel of the second track got "pushed down" to be the second channel of the second track, because the import needed to insert above it a copy of the first channel from the first track.

But note that it still imported everything OK - it appropriately changed it from "cyan 4.4" to "red 2.2", and its effects remained the same as they used to be. It just got its position pushed down, because of the copy of "blue 1.1" that needed to be inserted above it.

A similar thing happened in the third track: "expfrom" has the first channel in the third track being a copy of "red 2.2". So in "impto-imp", a copy of "red 2.2" was inserted as the first channel, pushing the existing channel ("green 5.5") down a spot.

And that copy of "red 2.2" is the only channel in the third track of expfrom, so "green 5.5" is untouched in impto-imp (except for having been pushed down a spot).

Now look at the fourth track of impto-imp:

There is no fourth track!

Why? Because the only thing in the fourth track of impto was a copy of a channel from another track, and so was removed from the fourth track as part of the importing process, but there's no fourth track of expfrom, so no channels got imported for it. This left the fourth track without any channels, and so the fourth track was automatically removed from the sequence.

So that's potential side effect #2: If you have a track that contains nothing but copies of channels from earlier tracks, and you import from a sequence that doesn't have that many tracks, that track will be gone.

But the important thing to note here is that the channels of the track will not be gone: impto originally contained a copy of green 5.5, with a fade down from 0.00 to 1.00. That channel is still in the sequence - but only its earlier copy. If you really want it in a fourth track, you can just make a new track and copy it there. You haven't lost any information about your channels.

So those are the potential side effects of the new methodology. For the sake of completeness, I will also show you what would happen in the exact same situation using an old version of the software, so that you can see how downright wacky it used to be. But I will do so in yet another post.

Attached files

impto-imp.las

[bob]

Here's a demonstration of how wacky the similar situation could get using the old software:

The file that is attached to this reply ("impto-impold.las") is the result of doing the exact same export/import using an older version of LOR. As you can see from it, the result is not really very similar at all to what one might expect, in a variety of ways:

The first channel in the first track has become "red 2.2". Note that the first channel in the first track of the channel config file (i.e. expfrom) is "blue 1.1", not "red 2.2".

The first channel in the second track has become "blue 1.1". This matches with the first channel of the second track of the channel config file, which is also "blue 1.1", but that's the only copy of this channel in impto-impold, whereas expfrom also had a copy of it in the first track.

The second channel of the second track has become "red 2.2", which matches with the second channel of the second track of expfrom. But unlike in expfrom, in impto-impold it is a copy of the first channel from the first track. This is because in impold, the first channel of the first track and the second channel of the second track were copies of each other, so they still are after the import - unlike in expfrom.

This is also why the first channel in the first track (surprisingly) became "red 2.2" instead of "blue 1.1": because that channel is a copy of the second channel in the second track.

Now, it gets even worse:

The first channel of the third track has become "red 2.2", because that's what the first channel of the third track of expfrom is. But note that (in impto-impold) it's not a copy of the other "red 2.2" channels in tracks 1 and 2. In tracks 1 and 2, there's an on event from time 0.40 to 0.70; in track 3, there's a fade down from 0.00 to 1.00.

They are not the same channel. They just happen to have the same settings (such as unit and circuit) as each other. This could cause real problems - the two different channels will be competing for control over the same unit and circuit, leading to strange things happening with the lights that are hooked up to that circuit.

For example, in this sequence, unit/circuit 2.2 would be sent a "fade down" command at time zero, but then in the middle of that fade, it would be sent an "on" command, and then an "off" command (before the time that the original fade was supposed to have finished). The lights on unit/circuit 2.2 would behave in a way that is totally different than the way that the lights on any unit/circuit behaved before you imported.

The same is not true under the new way of exporting/importing: All of your lights will behave the same way both before and after the import (though of course perhaps on different units and circuits).

Hope this all helps. Sorry for the verbosity and the confusion. And again, I think the high level summary is this:

The potential side effects (in the new method) aren't really anything to worry too much about, and they won't have any unexpected effect upon the behavior of your lights, whereas the potential side effects in the old method were just plain awful.

Attached files

impto-impold.las

[Jeremy Wiles]

Bob,

Thank you very much for the detailed information. I appreciate you taking the time to clear this up. I need to spend a little time digesting this at this point.

Wish me luck... :-)

J.

[Bowshock]

PHEW!!! That's a LOT to read!!

All I know is that in earlier versions, I had one song that when I imported the new channel configuration it really messed everything up. It moved channels around and had things all mixed up. Last night I installed the upgrade and imported the same exact channel config to the same exact sequence and TA-DA!!!!! NO PROBLEMS!!!

As far as I'm concerned....it's fixed!!

GREAT JOB!!

[iresq]

As an adult ADD sufferer, I will just trust that it works better.