Software used:
Resolume 5.0.0
Hardware:
- Alphapix 16
+ Capable of controlling 340px per output
+ Capable of using 32 universes in artnet mode
- 5V DC 60A power supply
- Lengths of 1m long WS2812B, 60 LED/m pixel strips, all daisy chained on 1 output (= 300px)
I made a fixture for a 1m long strip with 60 LED's (so 1x60px fixture)
Figured i can only fit 2 of those fixtures in 1 lumiverse since that makes 360 CH.
The problem is that when i start a new lumiverse with another 2 fixtures in there, it starts the new universe after the 512th channel of the first, leaving about 152 CH unused!
so i get a big "Gap" in my string of pixels.
This is very frustrating.
I contacted the manufacturer of the Alphapix16,en he told me the "physical" universer flow over from one to another.
So it seems Resolume is the problem in this situation.
Is the any way to spread the load of that last fixture over 2 lumiverses
I can't figure it out since i can only put that specific fixture in lumiverse 1 OR 2.
Making smaller fixtures so it fits is not an option because the scale of the installation will contain 50 strips of 60px...
Just for the record, the Alphapix16 works great with resolume! the probleem seems software related
Help please!
Hope this great community can help me out.
Thanks for reading & helping me think.
Can't overlap from one lumiverse to the next
Re: Can't overlap from one lumiverse to the next
Great to hear that the Alphapix16 is working with Resolume.
Sending video to pixelstrips is a bit of a wild west, frontier situation at the moment. It's relatively new technology, so there's no agreed way to do things yet.
I understand that from the Alphapix16 developer's side, it makes sense to use 'overflow'. Otherwise you're throwing away a lot of data from each DMX frame.
From our side, there is no way of knowing how a specific SPI controller handles overflow. Does it overflow after exactly 512 channels? 512 channels would be 170.66667 RGB pixels. This would mean that the first universe ends on 511:R and 512:G, so the second universe would start on 1:B, which doesn't sound very practical. So maybe they overflow after 510 channels, which is exactly 170 pixels. But maybe they overflow on some other arbitrary number? And what if they support RGBW pixels? This would put the overflow at some other value again. And what if you're mixing RGB and RGBW strips in the same Lumiverse?
And what if we would somehow be able to figure out when to overflow? Would we automatically create a second Lumiverse? What if there is already a second Lumiverse? Would we shift all the existing Lumiverses down? Or should we just overlap the fixtures and let you figure it out?
We can't program for this. There are so many potential variables involved, that it's impossible to come up with an one-size-fits-all solution that handles this for you.
Maybe somewhere down the line, all these SPI box manufacturers will agree on a fixed protocol for this. Then we can perhaps figure out a way to handle this. Until then, I'm afraid you're really stuck with making a second, shorter fixture, that does the overflow for you in the way that the Alphapix16 expects.
Sending video to pixelstrips is a bit of a wild west, frontier situation at the moment. It's relatively new technology, so there's no agreed way to do things yet.
I understand that from the Alphapix16 developer's side, it makes sense to use 'overflow'. Otherwise you're throwing away a lot of data from each DMX frame.
From our side, there is no way of knowing how a specific SPI controller handles overflow. Does it overflow after exactly 512 channels? 512 channels would be 170.66667 RGB pixels. This would mean that the first universe ends on 511:R and 512:G, so the second universe would start on 1:B, which doesn't sound very practical. So maybe they overflow after 510 channels, which is exactly 170 pixels. But maybe they overflow on some other arbitrary number? And what if they support RGBW pixels? This would put the overflow at some other value again. And what if you're mixing RGB and RGBW strips in the same Lumiverse?
And what if we would somehow be able to figure out when to overflow? Would we automatically create a second Lumiverse? What if there is already a second Lumiverse? Would we shift all the existing Lumiverses down? Or should we just overlap the fixtures and let you figure it out?
We can't program for this. There are so many potential variables involved, that it's impossible to come up with an one-size-fits-all solution that handles this for you.
Maybe somewhere down the line, all these SPI box manufacturers will agree on a fixed protocol for this. Then we can perhaps figure out a way to handle this. Until then, I'm afraid you're really stuck with making a second, shorter fixture, that does the overflow for you in the way that the Alphapix16 expects.
Re: Can't overlap from one lumiverse to the next
Thanks for the reply.
I understand that you can't make this compatible with all controllers out there...
It would be handy if you could just define how big a lumiverse would be.
If you need a regula 512ch lumiverse, you make one. I you need a 510 universe, you can make that too.
I might overlook how complicated it would be to program that, but it's just an idea.
I a diffirent controller an option?
If so, what is a recommended multi-universe controller to do this?
I understand that you can't make this compatible with all controllers out there...
It would be handy if you could just define how big a lumiverse would be.
If you need a regula 512ch lumiverse, you make one. I you need a 510 universe, you can make that too.
I might overlook how complicated it would be to program that, but it's just an idea.
I a diffirent controller an option?
If so, what is a recommended multi-universe controller to do this?