Slightly crazy screen
Posted: Sat Apr 20, 2019 11:30 am
I just completed a week long worship conference at my local church using a custom built LED screen out of WS2812 LED's
The screen was 152x64 pixels (designed for 160x64 but it would not fit in the location it needed to go in) and QLC drove both the screen (video things included), and the rest of the lighting rig.
If anyone wants any extra details on the screen construction, I am happy to do a more detailed write up in the future when things have calmed down a little.
The main lighting rig is controlled by a pair of USB to DMX interfaces (ENTTEC DMX USB Pro Mk2)
The screen (as designed, not as deployed, as deployed it was 8 pixels shorter) consists of 6 raspberry pi's running OLA and fcserver, each controlling 2 or 4 fade candy boards.
Each fade candy controls 8 strips, each 64 pixels long (the height of the screen) 20 sets of 8 (designed) gives the 160 px across.
Each Raspberry pi ingested up to 16 DMX universes over E1.31 and outputted via open pixel control to fcserver, that then mapped onto the fadecandy.
Each fadecandy controlling 512 pixels and using 1536 DMX channels. spread out over 4 DMX universes. (cause it was easier to set up QLC up to use 384 channels per universe cause each strip was 64px long, so 192ch per strip, and 2 strips per universe) Total designed DMX channel count for the screen was 30720
The rest of the rig took another 400 or so channels
The method I used for making QLC play video was weird but it worked.
It was to take advantage of the "animation" option for displaying images on an RGB matrix.
By exporting a video as a series of PNG images, then using imagemagick to stitch all the images together to form a really wide PNG file.
QLC was then fed the resulting PNG file and set to "animation" mode on the RGB matrix function with a hold time of 40ms (to get 25fps)
Crazy but it worked.
Thank you Massimo for this amazing and very flexible bit of software.
It is an absolutely central part of the lighting rig that I use.
Also, a second thank you for the multi-thread work in 4.12 because with out that, this setup would not have been possible due to the single thread CPU needs.
Regards
The screen was 152x64 pixels (designed for 160x64 but it would not fit in the location it needed to go in) and QLC drove both the screen (video things included), and the rest of the lighting rig.
If anyone wants any extra details on the screen construction, I am happy to do a more detailed write up in the future when things have calmed down a little.
The main lighting rig is controlled by a pair of USB to DMX interfaces (ENTTEC DMX USB Pro Mk2)
The screen (as designed, not as deployed, as deployed it was 8 pixels shorter) consists of 6 raspberry pi's running OLA and fcserver, each controlling 2 or 4 fade candy boards.
Each fade candy controls 8 strips, each 64 pixels long (the height of the screen) 20 sets of 8 (designed) gives the 160 px across.
Each Raspberry pi ingested up to 16 DMX universes over E1.31 and outputted via open pixel control to fcserver, that then mapped onto the fadecandy.
Each fadecandy controlling 512 pixels and using 1536 DMX channels. spread out over 4 DMX universes. (cause it was easier to set up QLC up to use 384 channels per universe cause each strip was 64px long, so 192ch per strip, and 2 strips per universe) Total designed DMX channel count for the screen was 30720
The rest of the rig took another 400 or so channels
The method I used for making QLC play video was weird but it worked.
It was to take advantage of the "animation" option for displaying images on an RGB matrix.
By exporting a video as a series of PNG images, then using imagemagick to stitch all the images together to form a really wide PNG file.
QLC was then fed the resulting PNG file and set to "animation" mode on the RGB matrix function with a hold time of 40ms (to get 25fps)
Crazy but it worked.
Thank you Massimo for this amazing and very flexible bit of software.
It is an absolutely central part of the lighting rig that I use.
Also, a second thank you for the multi-thread work in 4.12 because with out that, this setup would not have been possible due to the single thread CPU needs.
