Jump to content
Light-O-Rama Forums

Dmx Rgb smart strings?


flogger7

Recommended Posts

  • 1 month later...

Having trouble with non-CCR rgb strings. I drew a bunch 1 at a time.
But after 1000 the prop doesnt always display correctly. When I save it as a prop they dont seem to be all there anymore. Am I missing a trick to this?

Link to comment
Share on other sites

64 is the number saved. But when I generated the xml it had a matrix of 16 * 50. It loaded and displayed each pixel. And the simulation worked too. It took a long time to delete and caused the prop list to go blank. But the sim worked until I saved it and it chopped off all but 64.

I am doing this as a Free toolfor rgb programming. Vegomatic. So I don't expect support to debug anything. Here I am just trying to understand the limts and determine if I did something which I can correct.
Thanks Mike

Link to comment
Share on other sites

ItsMeBobO wrote:

64 is the number saved. But when I generated the xml it had a matrix of 16 * 50. It loaded and displayed each pixel. And the simulation worked too. It took a long time to delete and caused the prop list to go blank. But the sim worked until I saved it and it chopped off all but 64.

I am doing this as a Free toolfor rgb programming. Vegomatic. So I don't expect support to debug anything. Here I am just trying to understand the limts and determine if I did something which I can correct.
Thanks Mike


If you exceed the internal limits of the program, results will be unpredictable. If you are creating the XML outside of the visualizer, I can't be of more help. Sorry.
Link to comment
Share on other sites

ItsMeBobO wrote:

64 is the number saved. But when I generated the xml it had a matrix of 16 * 50. It loaded and displayed each pixel. And the simulation worked too. It took a long time to delete and caused the prop list to go blank. But the sim worked until I saved it and it chopped off all but 64.

I am doing this as a Free toolfor rgb programming. Vegomatic. So I don't expect support to debug anything. Here I am just trying to understand the limts and determine if I did something which I can correct.
Thanks Mike

Bob,
I bumped into lots of maximums when trying to do some perl scripts to simplify my addition of rgb strings.
Basically 64 fixtures per prop and 1024 fixtures per visualizer file.
I found these to be too limiting and ended up using the old animation window to do my rgb, and the visualizer to do my traditional lights. Painful.. very painful.

the posts are:
http://forums.lightorama.com/forum77/28766.html - 64 per prop
http://forums.lightorama.com/view_topic.php?id=28865&forum_id=77&highlight=visualizer+maximum - 1024 per visualizer file

dave
Link to comment
Share on other sites

Thanks for the background Dave. I did not find the 64 limit in the help limits page either.
My program did generate a prop file which could be imported and worked but the LEE containing the prop could not be saved. Oh well.
There may be other arrangements which could be generated and work within the current limits.

Looks like I am back to the animation within SE for DMX, but I plan to take another stab at it for CCR strings which have more support in Viz.

Mike I appreciate the position you need to take on outside tools. No problem, just doing my thing.

Vegomatic thread here.
http://forums.lightorama.com/view_topic.php?id=32778&forum_id=81&jump_to=313818#p313818

Link to comment
Share on other sites

  • 5 months later...

OK, I think I'll be running into this problem as well. If I have 24 RGB (DMX) strings of 50 pixels each, is possible to display this within the visualizer? I have the understanding that a 50-pixel prop will consist of 50 fixtures with their own DMX universe and channel...and 24 strings x 50 pixels = 1200 fixtures. What is the workaround? Thx!

Link to comment
Share on other sites

Wayne,

I've yet to find a viable work around. Things I've experimented with:

- trying various combination of props/fixtures to see if I could trick the 1024 limit - nothing works..

- running multiple Visualizers, each with a portion of the display - does not work, Sequencer to Visualizer communication is unicast. tried various methods of multiplying the unicast feed with no luck (netcat, etc)

- leaving out a portion of the fixtures/props.. skip every other pixel for example - works but annoying.

- using the traditional animation window for RGB. extremely painful to build, but in the end was the best answer I found.

only other thing that I have not played with, and maybe others have, is to hijack the CCR prop somehow. Others may have tried and have experience, but I do not.

dave

Link to comment
Share on other sites

If you REALLY want to run 2 visualizers, We have a UDP splitter program that will allow that to happen.

Right off the bat, I need to tell you that it is 110% not supported. If you try to open a trouble ticket about it, people will go "HUH?". If you get it to work, great. Otherwise, just pretend that it doesn't exist. Beyond these instructions, that's all you get from me :)

The visualizer will only ever store 1 set of parms in the registry, so each time you start the second Vis up, you'll have to change the port. The next time you open the Vis, it will have the settings of the LAST visualizer you closed.

Basically, you set up the SE to send to the splitter. Then set up the splitter to send to 2 separate ports/IPs. Then you set up the 2 Vis's each to accept 1 of the split ports.

I'll attach it sometime today (when I can get to my development machine).

Link to comment
Share on other sites

DevMike,

So, can I ask why there is a 1024 limit on fixtures? Is it because of performance problems? If so, maybe there should be something in the options area allowing people to expand it, but knowing that depending upon PC performance...may not keep up with the music.

2 visualizers is not the answer here. Either the fix is to make a DMX RGB string as 1 fixture (as the CCR's and other light strings are)...or to expand the limitations. As it is, many who have RGB DMX pixel trees won't be able to make use of the visualizer...even for the tree itself, much less the rest of the display.

I appreciate the ideas to come up with solutions, but there has to be a better way. Thx!

Wayne

Link to comment
Share on other sites

Maybe some time in the future we will expand the number of fixtures/etc, but for now you'll have to work around the limitations.

Unfortunately since we don't control how the hardware you are using is made, there is no easy way to create something that is going to work for everyone. We know how LOR CCDs are going to work, so we can design the Visualizer appropriately.

Link to comment
Share on other sites

DevMike, I can definitely understand that you don't know what hardware we are going to be using. For non-LOR hardware, it is pretty much going to be all DMX controlled (except for a couple devices that aren't), so it will come down to individual RGB DMX fixtures for each which the LOR network utility is now prepared for. Still wondering on the 1024 limit though. Is it for performance purposes, storage purposes, bit/byte/word size reasoning, etc? Just wondering if it is a simple change (in the future) or a complex one. Thanks!

Link to comment
Share on other sites

If you REALLY want to run 2 visualizers, We have a UDP splitter program that will allow that to happen.

....

I'll attach it sometime today (when I can get to my development machine).

Mike,

I would love to give this tool a try, and understand completely that it is not supported. Please let me know if it is something you will still entertain letting out.

thanks,

Dave

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...