Question: does NC alter channel data for

[Steve Gase]

When importing a sequence from LOR, Vixen, or LSP – does the work in NC affect channels not defined in the model(s)?  I’d like to use LSP, export/import to NC, add my tree, and export to LSP without affecting the other non-tree channels.
 
In other words, if I build sequences in Vixen that include my fog machine, arches, etc.  and I import that sequence into NC in order to add my megatree -- then export that sequence back to Vixen -- will my fog machine, arches, and existing channels still be around?

[smeighan]

When importing a sequence from LOR, Vixen, or LSP – does the work in NC affect channels not defined in the model(s)?  I’d like to use LSP, export/import to NC, add my tree, and export to LSP without affecting the other non-tree channels.
 
In other words, if I build sequences in Vixen that include my fog machine, arches, etc.  and I import that sequence into NC in order to add my megatree -- then export that sequence back to Vixen -- will my fog machine, arches, and existing channels still be around?

If you imprt from LSP, add models in another range and then export a UserPatterns.xml your original data should be there.

thanks

[Steve Gase]

If you imprt from LSP, add models in another range and then export a UserPatterns.xml your original data should be there.

thanks

Cool!  Thanks.

[JonB256]

If you imprt from LSP, add models in another range and then export a UserPatterns.xml your original data should be there.

thanks

Sean, is there a significance to the "UserPatterns.xml" export?

I know that when I converted one of last year's LOR sequences to xLights xseq format, and then added some RGB data in a range below the existing LOR channels, it sort of worked.

First mistake I made was that I had a "test matrix" defined and a check mark in the "Part of my display" box. That test model overwrote many desired channels in the LOR file (I converted it back and looked at it).

So tonight, I'll make sure that only the models I'm using are checked as Part of my Display, and that they do not conflict with the occupied LOR channels from last year (DMX Universes 1, 2, 3 and 4).

Steve, you and I seem to be at the same point in planning our 2013 output.

[Steve Gase]

Steve, you and I seem to be at the same point in planning our 2013 output.

Planning, maybe...
 
I've got a LOT of work remaining my builds (some boards, but mostly the lighting elements) -- but if I keep at it, I think I'll be ready to focus on sequencing in September.
 
Right now, I'm just imagining all of the problems I might run into -- and fortunately I'm finding the nutcracker team is well ahead of me on most issues.

[smeighan]

If you imprt from LSP, add models in another range and then export a UserPatterns.xml your original data should be there.

thanks

Sean, is there a significance to the "UserPatterns.xml" export?

I know that when I converted one of last year's LOR sequences to xLights xseq format, and then added some RGB data in a range below the existing LOR channels, it sort of worked.

First mistake I made was that I had a "test matrix" defined and a check mark in the "Part of my display" box. That test model overwrote many desired channels in the LOR file (I converted it back and looked at it).

So tonight, I'll make sure that only the models I'm using are checked as Part of my Display, and that they do not conflict with the occupied LOR channels from last year (DMX Universes 1, 2, 3 and 4).

Steve, you and I seem to be at the same point in planning our 2013 output.

Jon; you are right, if you check a model in your display, it will over write any channels you might have imported.
Be sure you only have models that are using.

[JonB256]

It was an accident!  It will never happen again.

I need to make my xLight model channels match my physical reality. It's going to cross into a second Etherdongle's space.

Galaxy Note II

[Steve Gase]

Jon; you are right, if you check a model in your display, it will over write any channels you might have imported.
Be sure you only have models that are using.

Does "any" mean :
1) any CONFLICTING channels
2) ALL existing channels

[smeighan]

Jon; you are right, if you check a model in your display, it will over write any channels you might have imported.
Be sure you only have models that are using.

Does "any" mean :
1) any CONFLICTING channels
2) ALL existing channels

If you import data from 1-1000 channel from LSP

you have a model that starts at 1100-2100
another model 2000-8000

no issue

if your first model start channel is changed to 900 so that it is 900-1900 you will overwrite your original data's channels 900-1000.

[Steve Gase]

Jon; you are right, if you check a model in your display, it will over write any channels you might have imported.
Be sure you only have models that are using.

Does "any" mean :
1) any CONFLICTING channels
2) ALL existing channels

If you import data from 1-1000 channel from LSP

you have a model that starts at 1100-2100
another model 2000-8000

no issue

if your first model start channel is changed to 900 so that it is 900-1900 you will overwrite your original data's channels 900-1000.

In your example you first have an overlap in the channels 2000-2100.  What problems does that cause?

[smeighan]

Jon; you are right, if you check a model in your display, it will over write any channels you might have imported.
Be sure you only have models that are using.

Does "any" mean :
1) any CONFLICTING channels
2) ALL existing channels

If you import data from 1-1000 channel from LSP

you have a model that starts at 1100-2100
another model 2000-8000

no issue

if your first model start channel is changed to 900 so that it is 900-1900 you will overwrite your original data's channels 900-1000.

In your example you first have an overlap in the channels 2000-2100.  What problems does that cause?

oh yeah, bad example.

well the last model processed will just overwrite the channels of the previous model.
so make sure your models do not overlay each other. doesnt cause a "problem", just clips the effect from one model and uses the second.

[JonB256]

I decided that the easiest thing to do would be to move my two matrix models totally out of the Etherdongle 1 address range (1 thru 16,384)  and into Etherdongle 2 range (16,385 to 32,768). My total number of channels, if I use both matrices in my Christmas display, would have exceeded the 16,384 channels anyway. This just made the math simpler.

So, now, all my LOR sequences are safe when I convert them "xseq" and then add in my RGB Matrix effects. No channel gets overwritten.

The bigger matrix (a reformatted version of the big one at The Academy) has gone from 126x32 to a more rectangular 72x54 shape (this was actually picked to get a 4:3 ratio shape). So instead of 4032 pixels, the matrix will have 3888 pixels. Not much smaller, but the shape will be much, much better for Video and Graphics, but still wide enough for nice Text.

This also means that I will never do ANY matrix effects in LOR, only in xLights. Loading and editing that many channels was a lesson in frustration.