Smart String Controller - software enhancement request

[taybrynn]

I think I've mentioned it previously, but my SS idea/reccomendation  for 2012 is to enhance the Lynx SSC utility to include the ability to use something BETWEEN "string mode" and "node mode" when programming the SSC.

For this example, lets talk about 120 node SS flex strip.  When you program the SSC ... you would enter 120 as you do today ... but then you could select "Group Mode" [ or flexible hybrid mode ] ... and then specify any number that is greater than 1, but evenly divisible into that node count (i.e. 2,4,6,10,12,...) ... not to exceed the total node count itself. 

Then the SSC software would create (n) resulting virtual 'node group' for you ... which could do a few significant things:

(1) it would allows something more than string level control (with just group size=total nodes)
(2) it would still lower total channel count on the SSC considerably
(3) because of #3, could reduce hardware requirements and make sequencing easier ... could also improve performance on certain sequencing software (most)

So in my example, if I wanted to make a SS Flex Strip arch and just build my 10 segments using the SSC "Group Mode" ... I would pick 120 nodes and then a group size of 12.  Then each group of 12 RGB LEDs is represented by a channel (or group of 3 rgb channels).  SO this way, I can have an arch with 12x3=36 channels instead of 120x3=360 channels.  And it gives a lot more control than string mode does, but using a lot less channels than node mode would.

I see this is just an extension of string mode, because string mode just takes the total node count and makes a group with the same size.  If we could vary the group size, this would be VERY powerful and could save people in cases when maybe they need some control, but not node level control ... and could save them from hitting total channel counts which end up costing them in terms of extra hardware or hitting software limits, etc.

I could see cases where you would use this on roofline of the house ... to get some control ... but realistically, you don't need node level control.  I also see than with arches, you might not need 120 nodes, but find that 10 sections is pretty acceptable.  This then translates to a lot of obvious benefits and capabilities.

So like RJ has time for any of this (doubtful) ... but I'd still like to put it on the 2012 wish list for the reasons stated.  I think the validation used could be simple.  Validation#1: MOD(#nodes,group_size,0)=ZERO  Validation#2: group_size must be > 1 (node mode) and < #nodes (string mode)

FOr someone maybe looking at 50,000 channels for the whole house roofline, this might be able to reduce that channel count down considerably ... and I think even in 2012 ... a lot of our software won't be able to handle 50k channels and maybe could handle 16k or 32k channels.

[wildwillie]

Agreed. It's an excellent request.  I've delayed my migration over to RGB's because I can't even begin to think of the sequencing all those nodes.

[Gary]

Don't LOR's and LSP's software allow for grouping to make sequencing like this easier?

[sielbear]

You can group nodes in lor, however, keep in mind that using a software grouping only overcomes the programming challenges. It will not overcome the systemic issues related to 5,000+ channels. While you only see perhaps 1/10th of the number of channels in the sequencing grid, the software must still render / send data for 100% of the nodes.

If node grouping is implemented in hardware, you can then setup 1/10th of the channels in the software package. When playing your show, opening / saving files, and performing copy operations, you'll be working with much less data overhead.

That's the biggest reason for the request to implement in hardware.

[mykroft]

As I mentioned in another start hard coding the group size in the setup util is less desirable idea.

My idea was like the hybrid mode, ex 120 flex, you have 120 x 3 plus 3, 360 for indv mode and 3 channels for string mode.

My suggestion was something based on the hybrid mode, 120 x 3 plus 1 for grp division.  This way you can still control indv if you need, and also set channel 361 to split the string up - ex 12 on channel 361 would split the 120 flex into 10 grps of 12.  This way the grp can be changed dynamically during the sequence as needed.

Myk

[sielbear]

I was thinking of something similar earlier tonight. Have a dmx control channel. One consideration is that using the ssc in a matrix would mean the dmx  control channel would need to be non sequential as most software requires the matrix channels to be sequential with no interruptions between the start and end of the matrix.

Not sure what's really ideal honestly...

[mykroft]

Not if you use a SSC per matrix line, you would just tell lsp the start channel #, number of nodes, etc.  Next line would either need to skip 1 channel for its start, or 3 channels.  As the Grp channel control could be treated like a null node maybe - I am not sure...

One thing i was just thinking is this could be setup either way.  Util to setup grp mode/# of nodes in grp - this would cut down on # of channels require or the other way like i describe above, it would use 363 channels.

But it all depends on if the current pic, or a circuit compatible pic that could do it.

Myk

[sielbear]

I know with lsp you must define a contiguous address space if multiple sscs are required to fill out the matrix.

Interesting thoughts...

[taybrynn]

yes, you can do this in the software (and I am) ... but if you want a smaller channel count or a smaller sequence size ... this is the way.  Meaning, the way that I actually am using many of these RGB items is not really the node level and not really the string level ... so If I can program that at the SSC level, I've made sequencing PERFORM faster ... because doing it in hardware is always going to be faster than doing it in the software.  So its a choice.  You can always reprogram the SSC later if you decide you boxed yourself in too much.  But I think if this capability is basically the same as the string mode, but instead of the group size = #total_nodes ... you make it variable with minimal validation rules ... and you can get big performance gains and lower the software requirements.  Because unlike a sequence grouped in LSP vs. LOR S3 ... which are not compatible ... if you grouped it in the SSC, it would work with either software, including vixen which lacks this grouping capability in the software.

[mykroft]

Hopefully this will be possible.  Maybe RJ will chime in and let us know if the current hardware can even do this..

Myk

[taybrynn]

If you introduce null nodes in the middle of groups, then it becomes very complicated, or I think it would/could.

To me, just allow the variable group size ... and then if you choose not to use some nodes ... do that in the software (don't use them) or mark them as null nodes and either hide in a null nodes group or just know that you don't sequence them.