DiyLightAnimation
Fun => The Porch => Topic started by: DanHouston on January 14, 2013,
-
I've been toying with a separate visualizer so as I do things in one sequencer or another I don't have to re-draw things in their visualizer...It also might give you a feel for any network latency issues since this would be taking packets off the network to display the results (like any other e1.31 device would).
Anyhow, in case this goes somewhere I thought I'd solicit for ideas on what people want in a visualizer.
Thanks,
DAn
-
I've been toying with a separate visualizer so as I do things in one sequencer or another I don't have to re-draw things in their visualizer...It also might give you a feel for any network latency issues since this would be taking packets off the network to display the results (like any other e1.31 device would).
Anyhow, in case this goes somewhere I thought I'd solicit for ideas on what people want in a visualizer.
Thanks,
DAn
Hi Dan;
I think I would want
a) Picture of my house with elements drawn
b) You will need to model all the string , pixels into physical devices. So if my megatree is 10x50 each string folded and it starts on channel 850 you will need to know
1) channel 850 is first string , pixel 1 of the start of the tree, channel 900 is the top of the tree, channel 901 is strt of tree next strand and so on.
2) If Channel is not RGB, be able to draw the candy cane, Snowman and have it represent the object.
3) If non rgb channel , be able to draw nets over bushes, icicles on eaves.
4) Draw RGB arches or non rgb arches. Vary diameter of arch. Be able to segment arch.
I like LSP's ability to play a sequence fast or slow.
I imagine you would need to capture the packets for a song into a buffer allowing playback at different speeds. Playback must also include the music or it doesnt make much sense. If you captured the packets, know when the sequence starts, have converted all channels back into the objects you still would need to get the music file attached.
I dont think the mp3 data goes over E1.31, so the best would be to prompt for the mp3 in your tool and then align it to the start of the first frame. Maybe you could also prompt for the frame timing that was used so that you could put up tick marks to show where transistions occured. Then a sort of grid culd be made with
mp3+frame timing. The visualizer should help see when a transition is wrong. With a passive monitor like you describe , it will also show lagging in the transmission of the actual data.
If i show an effect coming late, is it because i sequenced it wrong or there was lag in my hardware setup?
The LOR Superstar Pro addin makes an xml file of the objects in your display that includes where each pixel is located.
Here is a snippet for a LOR *.lee file, notice the DrawPoint element is giving the location of the element
<AssignedObject ID="41" Object="493"/>
<AssignedObject ID="42" Object="494"/>
</Item>
</Items>
<DrawObjects>
<DrawObject ID="1" Name="Small Shutter 1 #01" BulbSize="2" BulbSpacing="1" Comment="" BulbShape="1" ZOrder="1" AssignedItem="5" Locked="False" Fixture_Type="3" Channel_Type="2" Max_Opacity="0" LED="False">
<Sample Background_Color="0" RGB_R="0" RGB_G="0" RGB_B="0"/>
<AssignedChannels>
<Channel ID="1" Name="Small Shutter 1 (7-2-0-280)" DeviceType="7" Network="2" Controller="0" Channel="280" Color="255" Sub_Type="0" Sub_Parm="0" Multi_1="0" Multi_2="0" Multi_3="0" Multi_4="0" Multi_5="0"/>
<Channel ID="2" Name="Small Shutter 1 (7-2-0-281)" DeviceType="7" Network="2" Controller="0" Channel="281" Color="65280" Sub_Type="0" Sub_Parm="0" Multi_1="0" Multi_2="0" Multi_3="0" Multi_4="0" Multi_5="0"/>
<Channel ID="3" Name="Small Shutter 1 (7-2-0-282)" DeviceType="7" Network="2" Controller="0" Channel="282" Color="16711680" Sub_Type="0" Sub_Parm="0" Multi_1="0" Multi_2="0" Multi_3="0" Multi_4="0" Multi_5="0"/>
</AssignedChannels>
<DrawPoints>
<DrawPoint ID="1" Type="16" X="3841" Y="330"/>
</DrawPoints>
</DrawObject>
<DrawObject ID="2" Name="Small Shutter 1 #02" BulbSize="2" BulbSpacing="1" Comment="" BulbShape="1" ZOrder="1" AssignedItem="5" Locked="False" Fixture_Type="3" Channel_Type="2" Max_Opacity="0" LED="False">
<Sample Background_Color="0" RGB_R="0" RGB_G="0" RGB_B="0"/>
<AssignedChannels>
<Channel ID="1" Name="Small Shutter 1 (7-2-0-283)" DeviceType="7" Network="2" Controller="0" Channel="283" Color="255" Sub_Type="0" Sub_Parm="0" Multi_1="0" Multi_2="0" Multi_3="0" Multi_4="0" Multi_5="0"/>
<Channel ID="2" Name="Small Shutter 1 (7-2-0-284)" DeviceType="7" Network="2" Controller="0" Channel="284" Color="65280" Sub_Type="0" Sub_Parm="0" Multi_1="0" Multi_2="0" Multi_3="0" Multi_4="0" Multi_5="0"/>
<Channel ID="3" Name="Small Shutter 1 (7-2-0-285)" DeviceType="7" Network="2" Controller="0" Channel="285" Color="16711680" Sub_Type="0" Sub_Parm="0" Multi_1="0" Multi_2="0" Multi_3="0" Multi_4="0" Multi_5="0"/>
</AssignedChannels>
<DrawPoints>
<DrawPoint ID="1" Type="16" X="3961" Y="330"/>
</DrawPoints>
</DrawObject>
I was thinking of this earlier this year. I imagined creating a tool that would start
My Display is made of
a) My house
Megatree RGB
1st tree, 20x120 half megatree
2nd tree, 40x128, full tree
Megatree, non-RGB
3color wrap
4 color wap
Arches
Eaves
Candy Canes
Coro stars
objects, non rgb
b) My neighbors house
tree , wrapped in dumb led
bushes
1) net
2) 3 dumb rgb
All objects I was thinking of drawing in Sketchup (the free version) to give the 3d and walk around my display capability. I hadn't decided which software i would use.
After i had all objects in the Display, I would then assign channels to each object. This is where something like the *.lee file could be imported. Does LSP have an equivalent xml describing where everything is.
One suggestion to increase your user base is to try and export what you create so that LOR, LSP , HLS or Vixen 3.0 could use it. Do not assume people would all use this exclusively to visualize their data. Many people will still want to use their sequencer to do that. So eventually an export feature.
You , focused on a visualizer, might have enough features that people will continue to use it exclusively.
One issue i saw with this method, i was designing my display in february, i did not have an etherdongle built until the end of November. Using Visualizers in the sequencers do not require hardware be complete.
Your method , on the other hand, is the only one that would show the real world timing of the display.
You could get around this by having a second option of reading a file that has
timing channel value data
something like
0.0000 1 123
0.0000 2 0
...
1.1234 1 255
1.2345 17 122
Sequencers (and Nutcracker) could produce such a file from their sequenced data. This data would assume a perfect transmission.
If you made your sniffer produce this 3 column table, then your visualizer could be used from any data source.
Then you would become a universal visualizer, able to work on anyones sequencer.
I could add this channel output type file as an option for nutcracker, if you are interested.
it will be an interesting project.
-
Sean,
Thanks! Great feedback
As for playback I'm not trying to be an individual player, I want to be a visual represnetation of what an e1.31 device might get. So the music and playback speed would still be handled by the sequencer (at least that's how I have it in my head). I'll take one of them and play a sequence at different speeds and see how that affects what I have so far. Do you see a need to be a standalone sequencer player (I'm trying to let the sequencers do what they do really well and just fill a visualization spot...so as you change sequencers you can keep the visualizer).
Thanks,
Dan
-
Sean,
Thanks! Great feedback
As for playback I'm not trying to be an individual player, I want to be a visual represnetation of what an e1.31 device might get. So the music and playback speed would still be handled by the sequencer (at least that's how I have it in my head). I'll take one of them and play a sequence at different speeds and see how that affects what I have so far. Do you see a need to be a standalone sequencer player (I'm trying to let the sequencers do what they do really well and just fill a visualization spot...so as you change sequencers you can keep the visualizer).
Thanks,
Dan
I imagined a visualizer that worked with all the sequencers. This way it could be optimized to handle all the targetss
In the nutcracker, i need to have actual x,y,z dimensions to create effects. I am aware how this starts to get complex.
RGB, Non RGB
Megatreesone string wrapped into multiple strands, start at bottom or rop, wrap cw or ccw.
Matrices. Start at any corner, horizontal and vertical
Stars, all different kinds
Marty Fans
firepoles
eaves, arches,
Since i need to model anything i use, there would be synergy to maybe have an xml standard form for describing the targets. If all the sequencing people could have a standard. It looks like LOR might have started one with their lee file format.
-
I imagined a visualizer that worked with all the sequencers. This way it could be optimized to handle all the targetss
It would work with any sequencer capable of outputting e1.31 data.
In the nutcracker, i need to have actual x,y,z dimensions to create effects. I am aware how this starts to get complex.
Yeah the idea would be you draw and object on the screen (I'm actually hoping to get this to be totally open so people can create and share objects) and provide the information behind that object (channels it represents, RGB or not, start position, direction to move (ccw, cw)).
LOR might have a good format for storing that kind of information, I'll need to dig into that more.
-
I think that the visualizer needs to support a LARGE display that make take a very wide or multiple pictures to represent.
One possible ways to do this would be to have the option to have multiple pictures with a profile tied to each.
I have a corner lot display with a Manger scene on one side, and Santa and all other related elements on the other side. Even with a wide angle shot of the yard the elements show up as very small on the photo. It would need to give me the ability to zoom in and draw the element.
-
You might want to look at this thread over on DIYC. This addin really improved the Vixen visualizer. The code may be available.
Editable Adjustable Preview - lets you change your preview around and easily lets you use predefined images for mini trees, snowflake, mega trees, etc. Has ability to put RGB pixels in place and map to your channels etc.
http://doityourselfchristmas.com/forums/showthread.php?21557-Edittable-Adjustable-Preview-Plug-In
-
That looks very promising and possible to bolt on the packet work I've pulled together....Thanks!
-
Just a screenshot as progress continues.....
A couple of simple types (icicles and a megatree(not a pixel tree yet)).
It is currently picking up the e1.31 stream and animating the display. The tree is capable of clockwise and coutner clock wise rotations. I still have a lot of work to do to get this to even an alpha release that people can play with, but it's moving forward. :)
-
Just a screenshot as progress continues.....
A couple of simple types (icicles and a megatree(not a pixel tree yet)).
It is currently picking up the e1.31 stream and animating the display. The tree is capable of clockwise and coutner clock wise rotations. I still have a lot of work to do to get this to even an alpha release that people can play with, but it's moving forward. :)
Nice, can't wait to try it
Thanks for doing this
Rick R.
-
Cool!
-
I think this might be helpful for even what I did last year. I sequenced everything in chunks. I created 3 separate sequences for each song (megatree, house & arches, DMX) and then combined them into one master. It made sequencing 6200 channels easier for me. With one master visualizer, I could use the same preview for all those. It would be one common preview and prevent me from having to create different ones for each profile/element. Very interested to see what you come up with.
-Keith
-
I've had a couple of PMs recently about where I am with this, so I thought I would update this thread. I got fairly far with it and then before I moved into more of the display items I started doing some performance testing with higher channel counts. Performance fell off pretty bad after about 300 channels due to the way I was doing the graphics....then life got in the way. :)
Then I realized I need to learn DirectX (or a framework on top of it) to get the performance I needed....So I've been doing a lot of tutorials and reading and asking some of the other people who have visualizers in their sequencers what they did/learned.
Over the last month or so I've reworked portions of the drawing code to leverage DirectX and I'm just about to a point where I can add back my packet reading code and do some performance tests again. Depending on how all of that goes (hopefully this week or next) the possibility of having something crude people can play with a little would be on the horizon.
Anyways, that's the current status.
-
I've made some progress and think I have overcome the performance issue. I still need to test with much higher channel counts, but looking good so far.
Here's a short video (no audio):
http://youtu.be/CU_4ufYRvDA
And a new screenshot.
It's still got a fair bit of work before it's ready for others to test, and I have not looked at pixelnet at all (just DMX at the moment) which I know many here will want.
-
Very impressive Dan, are you going to open source it when you get a little further so some of us could help you out with enhancements etc?
I know a couple of folks were wanting to be able to have a couple of different perspectives, and I suppose if we made up a single image with both sides of the house or so.
Great work!
-
That is good so far.
I don't know how many universes of DMX that your demo covers but if you could cover at least 64 universes of DMX you would have pixelnet nailed.
-
I've conducted a performance test with 32 universes of DMX and the software kept up....though my network did not like it. :)
While doing that test it highlighted an issue with how I was threading the application which leads me to a question around universes (DMX and Pixelnet) and pixels....
If you are using DMX can you span a universe with a single string? It seems like you could not since a universe is not divisible by 3 so the data would come in two packets.
I assume the same is true for Pixelnet that a string cannot cross a Pixelnet universe?
This is important to me since I was threading by DMX universe, but when Pixelnet enters the picture (the hardware is combining DMX universes) you could now SPAN a DMX universe inside a single Pixelnet universe....meaning I need to change my threading from universe based to channel based and make sure each thread is handling a channel count divisible by 3.
Am I missing something or do I have the concept correct?
-
It is not so much an issue of spanning packets as it is with spanning interfaces. We do NOT use DMX for our pixels for the very reason that you suggested, not enough channels per universe. In plai DMX, all you have is 512 channels and every packet starts bac at channel 1. We use PixelNet for all of our pixel devices because unlike DMX a pixelnet universe has 4096 channels (8 DMX universes).
-
I have not tried running a set of lights right up to the 4096, but the controllers here on DIYLA only do one of the 4096 universes at a time, the new zeus let you specifiy by string which universe it listens too, so you still could in theory span over with one string coming right up and the next string starting right at 4097.
I would plan on just supporting to the boundry, what's the worst thing that can happen on the visualizer, the one pixel is off color, doubt you would notice it.
Are you splitting the actual decoding of the protocol from everything else so that a plug in architecture can be shared? e.g. a plug in for dmx, one for pixelnet, one for art net, one for whatever comes up later, maybe lor.
-
The way I was planning to listen on the wire it would've actually meant any object that spanned a universe would only show channels in the universe it started in....I'm already changing that so that you wouldn't have the issue of large chunks of channels potentially not showing for large objects (mega trees, etc)....so with the new plan it would mean one node would be the wrong color since part of the data was in a different universe.
I'm reworking the whole listening piece now to hopefully make it not matter, but it may also mean I have to rethink the drawing performance.
Hoping to have something new to show next week with a new interface (setting the stage to have more than one view of your show on the screen at the same time...or for those that do multiple houses) and this issue addressed (with new performance tests to validate).
-
Some of your comments and questions have me curious about your design.
If I were creating something like this I would have the socket receiver code just stuffing data into a raw channel array. Ie, E1.31 universe 2 of 510 channels gets mapped to raw channel ID's 511-1020, etc.. That part should be really fast, it's just memcpy-ing data into an array. Then I would have a thread or multiple threads for pulling data off that raw channel array for each display model and drawing that on the preview display. I think the simplest way to do this would be to 'draw' onto an image with a transparent background then overlay that image every X milliseconds onto the background image. The image could be generated by multiple threads each working on separate models pulling channel info from the raw channel data. Then once the models are all drawn, a single thread makes a single call to draw that image over top your background image.
This way the display code doesn't have to know about universes or pixels split across universes (which I believe is possible with some E1.31 controllers), instead it just deals with models which are based on raw channels. This is how Nutcracker models work.
I think the only assumption you can make about a particular pixel's R, G, and B channels is that they are contiguous. You can't even assume their ordering, that must be defined as part of a display item model. Pixels don't have to end on a channel number divisible by 3 or on a packet-relative channel number divisible by 3. I might have a dumb string with it's RGB channels on 1,2,3 and then another string on the same controller on channels 5,6,7 because channel 4 is bad. I could do the same with two 3-channel controllers or I could be skipping channel 4 in case I eventually want to switch to RGBW.
-
I had bolted the listening and drawing to each other and threaded them together, which is what made all of this matter....which was fine for my relatively small show. :)
I was trying to avoid queuing data (which I guess I still could and say if I don't read it fast enough too bad, but I think I'd like to let the user know that I am falling behind or throwing some amount of data away to keep up). I think it will be pretty straight forward, I just need to break apart that piece of my code.
-
Thanks.
I'm looking forward to seeing/using it when it is out. :) I had been toying with this idea myself but it was a case of too many projects, too little time.
-
So it took me a little longer than I thought, but new interface is there (have not added multiple display panels yet, but it is setup to do it). I also separated the listening from the drawing and tested a single 32 universe megatree with strings that spanned universes.....looking good so far.
Here's a new screenshot...
-
Super excited to throw this into my toolbox as soon as you release it. I think at the very LEAST it would be a great tool to have monitoring your live show from the conductor inside the house to ensure that your show is 'running smoothly' outside without walking outside.
-
I don't think that you will be able to do that. The Conductor does not send show data on its Ethernet port so unless you have some type of interface for this visualizer to pick up data from the Conductors output port, there will be nothing to see.
-
Ah yes - for some reason I was thinking we could put it downstream of the conductor on the E1.31 port, not the ethernet port (aka - between the conductor and active hubs). Silly idea....
-
anything come of this interesting project?
-
Wow! Blast from the past. :)
I had put this to aside for a bit due to some personal things going on. Let me dust it off and see where I'm at.
-
Much obliged Dan, was always curious about this and if a gaming engine could do the graphics work it might be possible to make it VR capable :)