Part Ques not holding channel information

calfredson · Post by **calfredson** » Mon Jan 27, 2014 9:55 am

I have a show that was originally imported from an Ascii file (from an ETC Express). I've noticed that when I create part cues, and then add channels to those parts (using the "set hilited to current part" command), the channel assignments don't hold when I restart the program. The parts still exist, but all the channels have relegated back to part 1. Interestingly, parts imported from the Ascii file (even in the same cue) work fine.

Has anyone else experienced this?

Craig

Post by **admin** » Mon Jan 27, 2014 7:31 pm

I don't find a generic problem with saving parts. Are you assigning parts in Live or Cues mode?

It shouldn't matter. But, in Live mode it can be confusing about which cue you are editing in terms of times and parts. In general, it is going to be the cue you've just recorded or the cue you have just played back.

Also, in Live mode, the parts do not appear in the drawer when it is showing the next cue to be played. The parts exist, they just are not indicated. It is that way because adding or selecting a part applies to the current cue, not the next cue. You will see an indication that the next cue has parts in the live window where it will say "PT" and the time that the longest part takes.

Does this help? Or, is there a repeatable sequence where you create a part, assign channels and save and they are missing when you open the file and look at the cue in "Cues" (blind) mode.

calfredson · Post by **calfredson** » Thu Jan 30, 2014 4:22 am

I always edit the parts in cues mode. The parts run fine when they are first saved, but then all the channels revert back to Part 1 once the program is closed and restarted. All the parts still exist, with timings intact, but the channels are simply not there.

Post by **admin** » Thu Jan 30, 2014 4:04 pm

I'm not able to reproduce this problem. What version of LXConsole and OS X are you using?

Does this happen with a specific file or can you create a new file and reproduce the problem with a single cue?

calfredson · Post by **calfredson** » Sun Feb 02, 2014 9:47 pm

I'm using OSX 10.8 and LX Console v3.3.7, although I originally found the problem while on v3.3.0.

I tried recreating the problem with a simple file and I couldn't, so it must have something to do with the complexity of the show (imported from ASCII).

Is there somewhere I can send the show file for you to see if you can recreate the problem?

Craig

Post by **admin** » Mon Feb 03, 2014 1:53 pm

Send the file to lx @ claudeheintzdesign.com and I'll take a look and see if I can reproduce the problem. If you have a set of steps to apply to the file that shows the issue, that would help a lot.

calfredson · Post by **calfredson** » Tue Feb 25, 2014 10:51 pm

So I've done a bit of investigating, and it would seem that the root of this problem has to do with the fact that the part information doesn't get saved for channels that are at zero in the given cue.

I inferred this from looking at an exported ASCII file, which doesn't list any channels with level zero in the cue. Does this make sense?

Craig

Post by **admin** » Wed Feb 26, 2014 2:25 am

Wow, that's an interesting observation. I looked at the ASCII standard to see if it addresses the issue. And, it does not. What happens is that in the ASCII representation of a cue, any channel that does not have a specifically assigned level, is assumed to be at zero. And, because of this, channels that are at zero are not written to save space. But, the way you know a channel is assigned to a certain part is that it is listed at a level under that part. There's the difficulty: if a channel is at zero, it is not listed and hence it defaults to being in the first or main part of the cue.

The latest build of LXConsole, 3.3.11 (7326A) fixes this in that it explicitly writes a channel at zero when it is not assigned to the first or main part of the cue.

SIDENOTE: I discovered a quirk of the standard in looking at this. The ASCII standard insists that a channel must be able to be in more than one part. It does say that a future draft would provide for an exception on systems where a channel can be assigned to only one part of a cue. This is the way LXConsole works and will continue to work. As there was never a future draft of the ASCII standard, LXConsole is not in compliance with the letter of the standard on this point.

But, I don't see how it is possible to have a channel in more than one part of a cue. Perhaps the authors of the standard had an understanding of a part that is quite different from mine. I view a part like different fingers moving sliders at different speeds on a manual board. To have a channel assigned to more than one part would be like having a slider pushed by more than one finger.

calfredson · Post by **calfredson** » Wed Feb 26, 2014 8:45 pm

Thanks for the update. Once I realized the problem, I created a workaround by setting all the relevant channels to 1% and then the parts saved correctly. I will update to the latest version once this show closes.

I also agree with your take on part cues - I can't imagine how you could have one channel in more than one part of a cue.

Craig