Channel extent of Vixen 3.0

[Penfold]

Just out of curiosity what is the extent of channels that Vixen 3.0 could handle? I think that Vixen 2.1 and 2.5 could handle up to 9,999 channels. With the advent of RGB controllers and strings I just wondered if Vixen 3.0 could handle say 32K channels?

[djulien]

I think that Vixen 2.1 and 2.5 could handle up to 9,999 channels.

I think the 2.x limit is actually higher than that, at least for some functions.

don

[Skunberg]

I believe the beta was one more digit 99,999. But the final release?

[aussiephil]

Just out of curiosity what is the extent of channels that Vixen 3.0 could handle? I think that Vixen 2.1 and 2.5 could handle up to 9,999 channels. With the advent of RGB controllers and strings I just wondered if Vixen 3.0 could handle say 32K channels?

I haven't created more than 2k RGB channels in Vix3 at this time due more to the UI slowness as node counts go up but suspect the limit will be far above what even the extreme guys want.

As for 2.x, at least in 2.5 the limit is certainly above 9999 as I just created a 12k, 25ms channel sequence a minute long and filled it using the random function and then played the sequence, no output plugins configured though.

Cheers
Phil

[prof]

Vixen 2.x allows the creation of +10k channel counts. The problem arrises when you go to assign start channels to the controllers you are using. It is these data entry fields that limit you to four digits. The workaround is to manually edit the vixen file to set the correct channel number. This issue was highlighted on one of Ed's Ethcongateway tutorials.

[KC]

Since 3.0 is doing a lot more in a much more complex fashion (not just zipping single byte values around), it's going to be inherently slower in producing results. However, we're working out a caching mechanism to help counter that. Additionally, there could be some facility for compilation and playback that would render everything into simple byte values that later gets read and executed.

Additionally, your hardware will make a big difference. Faster CPU and more cores, of course, are going to improve performance.

So, to actually answer your question, there won't be a set limit. The limits would be imposed by the hardware, but we're trying to make sure that single-core machines can still handle a pretty high channel count with a decent time resolution.

[aussiephil]

Since 3.0 is doing a lot more in a much more complex fashion (not just zipping single byte values around), it's going to be inherently slower in producing results. However, we're working out a caching mechanism to help counter that. Additionally, there could be some facility for compilation and playback that would render everything into simple byte values that later gets read and executed.

Additionally, your hardware will make a big difference. Faster CPU and more cores, of course, are going to improve performance.

So, to actually answer your question, there won't be a set limit. The limits would be imposed by the hardware, but we're trying to make sure that single-core machines can still handle a pretty high channel count with a decent time resolution.

KC

Thanks for that, just a quick note, in all the playing i have done the UI slowness i refer to at least in the sequencer window appears to be tied to the application actually rendering the effect in the UI as once it has rendered it once moving around the sequence time wise is really fast and playback has not been an issue

Cheers
Phil

[Penfold]

Thanks KC for the update!

[djulien]

Additionally, there could be some facility for compilation and playback that would render everything into simple byte values that later gets read and executed.

Sounds a lot like Vixen 2.x.

don

[KC]

Sounds a lot like Vixen 2.x.

don

That's been one point of question -- do we do it as additional layers that eventually result in the same thing that 2.x was doing? Since we know that that's the simplest model and provides the greatest performance, it makes sense. But it also means that the data has to get into that state, and since we're no longer generating data in such a simple state, it has to be compiled or rendered down into that state. Now just how and when that's done...