PDA

View Full Version : HLS - Preview (Visualizer) 2013



JHinkle
12-18-2012, 07:57 PM
I though I would share the direction HLS is moving to following the Holidays.

HLS will remove the Preview function.

A standalone program will perform the Preview task.

Within HLS - you can identify multiple Preview/Visualizer associated with your sequence. Different Preview/Visualizer may be different views of your house or different homes if the sequence is to control lighting on multiple homes.

Communication between HLS and multiple Preview/Visualizer will be via UDP packets. You can have multiple Preview/Visualizer active throught the home --- I am not piping audio at this time - so its only visual.

Designing your Preview scene - you will be able to construct a display object (as an example - a mini-tree). Once it is designed, you can now drop THAT object multiple times on your preview scene - one for each actual mini-tree: We will only need to associate the proper channels to that object.

I'm happy with using vectors to place and divide up pixels in a line (welcome your pro and con comments on this subject).

I'm considering also using "bit map" type blocks to show your lights. Again - welcome your pro and con comments on this subject.

Once your preview scene is designed - as long as the channels associated with the objects don't change - the same preview will work with all of your sequences. This get away from having to save previews in the HLS library and retrieve them for every new sequence.

I just wanted to give you a hint on the direction I am moving.

I am welcome to comments as not everything is lock into stone as of yet.

Joe

budude
12-18-2012, 08:11 PM
Honestly, I'm looking for a generic E1.31 previewer myself but I realize of course that not everyone uses E1.31. This would allow anyone with any sequencer putting out E1.31 to have a visualizer screen. Since your visualizer requires an Ethernet connection anyway - perhaps just make it an E1.31 receiver? For COM based sequencing, spit out an E1.31 version of it as well.

JHinkle
12-18-2012, 08:21 PM
My problem with E131 is that RGB has been broken down into 3 channels so it will take time to rebuild those three channels back into RGB. I would also need to know what channels required RGB conversion.

My plan is to preserve 24 bit color in the communication - making things a lot simpler.

I also get rid of the E131 header overhead.

I try to keep to KISS as much as possible.

I will keep your suggestion on the table - so I am not dismissing it.

Joe

szaske
12-18-2012, 08:26 PM
I really like how you use vectors to represent lights. It makes it REALLY easy for me to "draw" out a string of 150 pixels on a strip. The 2 suggestions I would make are:

1. Allow us to move the vectors after they are placed. My preview has somehow moved about 20 pixels to the left somehow.
2. Represent the pixels as round dots instead of equal length lines. Then equally space those dots along the vector. This would allow for space between pixels...and give a more accurate preview.

Also I found one limitation with your preview, which is there seems to be a limit to the number of vectors that can be used PER CHANNEL.

I created a sign that reads "Happy Holidays" and when I tried to draw that out I was only able to draw "HA" before I ran out of vectors.

Lionking_Tx
12-18-2012, 08:29 PM
Joe, for once you won't hear any complaint from me :)

I like the vectors like they are now, only wish I would have is making them round too (for arches or other things) - my preview arches are now triangles (not really important though).

A separate preview program would be perfect - I like budude's idea of having an E1.31 preview (to sneak in the stream from a different PC and watch what's going on).
Also a UDP would be great, so we can preview without outputting data to the controllers (or pulling the LAN cable). So what about both ?

Hey, never ask users about ideas/opinions...only causes more work :biggrin2:

budude
12-18-2012, 08:31 PM
My problem with E131 is that RGB has been broken down into 3 channels so it will take time to rebuild those three channels back into RGB. I would also need to know what channels required RGB conversion.

My plan is to preserve 24 bit color in the communication - making things a lot simpler.

I also get rid of the E131 header overhead.

I try to keep to KISS as much as possible.

I will keep your suggestion on the table - so I am not dismissing it.

Joe

The only issue then will be that, in addition to the E1.31 stream for the display items, you would have an additional stream of data just for the previewer - so it's a lot of data going out from the PC - - unless of course you don't plan to support both display output and preview output at the same time...

szaske
12-18-2012, 08:33 PM
One idea I had for making Previews really cool, is to ask people to enter the PIXEL type or chip type and then actually try to render the real word dimming curves of these chips.

This is my first year and I've been using some GE CE lights. I'm now noticing that they are pretty bad LED's. They cannot do a lot of colors because they don't have the range. Then when I match the brightness to the waveform a lot of the dimming range (say from 0-20% brightness) all shows up as Off (0% brightness).

I don't know how difficult that would be to reproduce in a preview, but it would be pretty cool if it did.

JHinkle
12-18-2012, 08:40 PM
Brian

My direction right now is SHOW or Preview - not both at the same time.

Once up and running - I can check what impact multiple data stream would have.

In my recent investigation into COM delays - where a COM port took 20 to 47 millisec to transmit, I was able to send four E131 packets --- all within a single millisec.

Joe

jchuchla
12-18-2012, 08:41 PM
I second budude's request. I've been looking for the same sort of universal e131 visualizer. I think if you're moving into a separate app handling data via network, you might as well use a standard so it'll play nice with anything else someone might want to use.
I agree that it'll add a bit of overhead, but it should be trivial. And the preservation of the mapping between hls and the visualizer could be handled by using a common config file.
I'd also think its pretty safe to assume that rgb is always in the same (r-g-b) order since the most common controllers sort that out in hardware.


--Jon Chuchla--

Sent from my iPhone using Tapatalk

dpitts
12-18-2012, 08:51 PM
Will you add sound later? Sound is very important in the preview. Also I was hoping in the future that placement information of elements on the preview could be used to have sequencer draw effects based on position. Will data flow one direction only from sequencer to preview?

JHinkle
12-18-2012, 08:54 PM
Will you add sound later? Sound is very important in the preview. Also I was hoping in the future that placement information of elements on the preview could be used to have sequencer draw effects based on position. Will data flow one direction only from sequencer to preview?

Audio will come from the computer running HLS.

What I was attempting to communicate was if your Preview was running at your next door neighbor's computer - I would not be sending audio to it at first. I'll look into that after other things are done.

Joe

CDN_Diesel
12-18-2012, 09:27 PM
not sure I fully understand where you are going, but I am sure it will be great. Just trying to grasp why you would want your preview at your neighbors computer for any reason. Anyhow, if this makes it so that I an have a preview "window" on a second monitor and watch that while sequencing, that would be the best.

injury
12-19-2012, 12:37 AM
spitballing so to speak...

So preview would essentially be an output device? Interesting, I know I for one don't have any use for piping a preview anywhere HLS isn't running. I run it on the editor to visually check timing when lights aren't in my office, so need music for that to be worth using. I suppose I could see someone using it as an output test to see what HLS says should be showed vs what they are seeing out of their controllers. Though for that to be accurate for such a purpose won't the previewer need to understand all the different output data HLS will be able to output and profile as such?

Beyond that my only real thoughts on moving it out say across the network is that user issues with firewalls or worse multiple firewalls some people end up with then become a support issue for you. When people get to playing with E1.31 I've seen support on different light forums for networks that are already choking "lights running can't browse the internet" type stuff, what kind of overhead would adding this previewer be. Now a solution would be "don't run previewer while lights are running" but that could hamper editing for people that put lights up for halloween and run them through Dec.

Would we have to create an output layout file and then copy it out? If we manage raw channels that would have to be modified or recopied everywhere correct?



I'm considering also using "bit map" type blocks to show your lights. Again - welcome your pro and con comments on this subject.


I was just thinking of this very thing this afternoon while driving around thinking of a pixelplane file editor/creator. Then I wondered about it being a grid of grids, meaning each light was actually 4 units as displayed of a smaller placement grid. My only reasoning for that is for things like arches or denser placements. With placement on a larger overall grid as such it seemed easy to create display wide effects across a larger grid then only the "matte" display light data would be saved.

My ultimate "wonder why" is why are most sequencing tools designed to show only a side on channel viewer for editing outside of a preview. Why not have a face on grid of the lights that advance like animation cells for each frame or a switchable view windows where step A is setup face on like someone envisions, then turned sideways to drag out chases and lengths etc.