addressing DMX fixtures on second universe

O

ONEGREENMAN

Member
Here is a way of translating universes DMX channels with pangoscript.
"DmxOut 1+512, value //" This changes DMX channel 1 on universe 2 without having to count -lol.
Is there a shorter way..? I have tried a few but nothing seems to work as a identifyer of universe "2", IE: "Output 2, DmxOut 1, value //"
so I came up with letting it calculate it plus 512 channels, ...seems to work a treat on sliders etc and an easy copy and paste-)
 
YEP I tried this too but didn`t lessen the load on multiple channels at once. also "// " rems DID make a huge difference. In one case I have 16 fixtures of 64 channels each and lots of sliders etc so I put all channels into script and just rem out the lines I don`t need BUT pango engine seems to "look" at them anyway and is creating a serious delay in delivery of the few channels not rem`d out. So I had to delete all not used rem`s "// " to get it to work faster. Where I have used a slider approach that controls lots of channels it creates a delay of notable length (up to almost half a second) but only on the last section of led I am controlling, the first 3 sections of 16 channels(48) transmits fast but the last section of 16 has the delay.
It does not matter how I present the data 'rem`s' or not, calculated addresses or not, the last section has the delay and it is visible in the monitors too. I have not yet tried to control "two separate sliders" with the "channels spread across them" by a master slider for the two to see if it is still an issue. As I am not using the controls live, but just for setting scenes, I am not concerned but I do like to find workarounds, I will post what I find. Technically it should show same delay under load but I will soon find out -)
 
Last edited:
How big are your scripts in general? We have a task manager in BEYOND which should help find these scripts that slow down the system.Scherm­afbeelding 2024-08-16 om 10.43.04.png
 
Thanks for that did not know that was there for that.
However you may find the results of the test interesting ...I certainly did -).

I had 64 lines of pango Dmx out commands (value) on one slider and the commands span two universes.
I had most rem`d out but were still causing great slowdown "but only on that slider".
I removed all rem`d out lines and got massive improvement (to my surprise), but still nasty delay after 32 lines of "active" Dmxout commands.
So as stated I did a test to distribute no more than 32 lines of Dmxout commands out of 64. put first half on one slider and second half on the other and told them to reference a third "master" slider with no code or connection. Again much to my surprise it totally worked and I have fixed all slider response problems.... curious.. but good. This potentially shows me that there is a 'comfy' limit to slider use but this technique has totally eliminated all isues. Now the sliders have instant response and do not drop Dmxout commands into a delay at all accros universes too. Great result!
 
There may be another answer to my slow down on sliders..but I haven`t tried yet. I found when grouping toggle buttons together and using pangoscript in the buttons they would send the highest value to each channel they referenced in script in the group when I pushed play on the universe window, switched to its page from another page, or on start-up. I made a new button and went to pangoscript and noticed the auto entered text and that it had this:
// PangoScript code template
// .. put you initialization command here


exit // each section always should have EXIT command
.

In my script I removed all that and just had "onclick:" and my code and exit.The buttons worked but with the fault.
It would seem that 'buttons' at least 'assume' an initialization command section exists and therefore requires an exit before "onclick:" even if there is nothing there ?
I did it anyway and the code shows in dmx monitor correctly and no more unwanted dmx signal -)
Normal behavior restored.
I looked at sliders and they too have the same , so I will have a go at re-creating the slowdown and enter the first exit and see if it makes a difference, It looks like it might.
 
You must log in or register to reply here.
Back
Top