Button Input speed for Light Pup

[zatar]

Hi folks ... We are using light aroma for a 44 foot cloud shaped bus we're building for Bernie man.… So far everything's working really well. We would like to add some more interactivity. I'm very interested in peoples experience with the light pop hardware interface. We'd like to make a "keyboard" of about 16 buttons that would trigger different small sequences. Does anyone have any experience with a white pup regarding its response time?… I.e. is it fast enough there for someone we're trying to knock out a rough beat on it but it would respond quickly enough with a very short sequence. For example… If someone wanted a simple layer of lights to light up on a coarse  beat crated by manually hitting a large button.. how much delay would you expect between the button push and the LOR sequece to start ? Is it milliseconds or seconds ? .. COuld this sort of thing work ?  Thanks 

-jc

 

[k6ccc]

No idea what you are talking about as "light pop hardware interface".

As for the speed of interactive sequences, I use then every night of the year.  I can't say I have ever attempted to measure the time from trigger to sequence starting, but it is WELL under one second.

I am using a LOR InputPup for my triggers and it is on a dedicated LOR network.  The only reason that it is on a dedicated LOR network is because my remaining LOR networks are running in Enhanced LOR mode and any input device can not be used on a LOR Enhanced network (I can explain why if you really want to know).

 

[dibblejr]

My experience with the Input Pup was great. I was able to see how well it worked at the Florida Mega Mini and it was very fast. Fast enough that I told another friend that it would really work well on his maze so that if a child gets lost or scared he would be able to use it to light sections to help them find their way back to home.

It was used at the FMM to control songs for my singing faces. As soon as someone selected one of the buttons it changed the song. 

Since I dont know your system I cannot guarantee it would work as well but it did for the singing faces. Matt built a really nice controller box for the Input pup.

Best of luck

JR

[zatar]

3 hours ago, zatar said:

Hi folks ... We are using light aroma for a 44 foot cloud shaped bus we're building for Bernie man.… So far everything's working really well. We would like to add some more interactivity. I'm very interested in peoples experience with the light pop hardware interface. We'd like to make a "keyboard" of about 16 buttons that would trigger different small sequences. Does anyone have any experience with a white pup regarding its response time?… I.e. is it fast enough there for someone we're trying to knock out a rough beat on it but it would respond quickly enough with a very short sequence. For example… If someone wanted a simple layer of lights to light up on a coarse  beat crated by manually hitting a large button.. how much delay would you expect between the button push and the LOR sequece to start ? Is it milliseconds or seconds ? .. COuld this sort of thing work ?  Thanks 

-jc

 

Jim,

    Thanks so much for your response. Very Sorry. on teh confusion. . I miss-typed.. By "white pup" I meant the InputPup you mention in your response. What you say sounds very encouraging.  I am wondering about your comment "The only reason that it is on a dedicated LOR network is because my remaining LOR networks are running in Enhanced LOR mode and any input device can not be used on a LOR Enhanced network" - I'm using an E1.31 controller with 'smart' RGB addressable light strips. The strips are configured as DMX elements in LOR.. not as 'LOR' .. does that present a problem ? 

Any suggestions on where best to look for InputPut examples ? 

Thanks again for your help
-jc

[k6ccc]

You will need to have a non-enhanced LOR network for an InputPup.  Can not run any input device on E1.31.

 

[zatar]

Jim,

   I don't think I understand what that means.… Are you saying that  there's no way to trigger external events into that controller ? .. Or that the lights cominng out of that controller need to be configured in a seperate way ? We are pretty committed to using that controller… -jc

[k6ccc]

No, the InputPup itself MUST be on a LOR non-enhanced network. The InputPup then communicates the triggers to your show computer, and the show computer sends appropriate lighting commands to the various controllers (regardless of what network or network type they are on.

 

[zatar]

Jim,

   Sorry.. still a bit confused. I understand that the InputPup has to talk to the computer over an un-enhanced LOR network and that the computer then sends commands to the controller(s).   Does that mean that if I'm running LOR S5 on the computer it can react to   those  triggers and talk to my E1.31  controller to my RGB smart strips ?

-jc.

 

 

[k6ccc]

Yes

[Steven]

8 hours ago, k6ccc said:

any input device can not be used on a LOR Enhanced network (I can explain why if you really want to know).

Now I am curious. I assume the answer is because input devices rely on polling, in which LOR sends a query and reads the response. The time it takes switching from transmit to receive probably would make the network too slow for enhanced use. Did I guess correctly?

[k6ccc]

Not quite.  In a non-enhanced LOR network, any device on the network (up to 32 per the spec) is allowed to transmit as long as no other device is not currently transmitting data.  That means that every device that is transmitting data has to stop once in a while (many times per second) to allow some other device to transmit.  That wastes a lot of time if only one device will be transmitting - thereby reducing throughput.  In an E-LOR network, essentially what happens is that the show computer or Director sends a command that tells every other device that they are not allowed to transmit and therefore the show computer or Director can transmit continuously.  Since the other devices are not allowed to transmit and the show computer or Director never shuts up, there would be no way for any input device to send the data that a input status had changed.

And no, the input devices are not polled.  They just wait for a gap in the data on the network and blast out their data.

For those that remember old original cable based networks where one cable ran around to each drop and there was either a T connector or a tap device that punched a hole into the cable to make contact with the center conductor and shield.  A RS-485 network operates very similar to that concept.