Blinky Lights

39 views
Skip to first unread message

chris usey

unread,
Dec 2, 2015, 12:19:24 PM12/2/15
to lightsh...@googlegroups.com
I remember back in the very first year we used this program there were ways to give weights to channels. In effect a user could specify a weight for a channel to tell the program how much each should blink. The program would also auto-tune the channels for ones that blinked too much or others that blinked to little. With the addition of PWM and fading that went away, and rightfully so. However users that use "onoff" mode instead of PWM with get a whole lot of blinking, which is not always pleasant.

I am not as fluent with the FFT process as some of you, so I am wondering what you guys think on re-implementing this feature or something similar. I say or something similar because I am not sure how possible it is at this point with the current implementation. I have a lot of reading to do to brush up on the changes that have been made over the past year.

I find that the initial playing of a song looks solid, however after a song is cached, the look changes. I think I understand how and why this happens, and Im just trying to work out how we might implement settings to allow a user to adjust the Blin-ikness, for lack of a better word.

Any Thoughts?

- Chris

Todd Giles

unread,
Dec 2, 2015, 12:24:52 PM12/2/15
to lightsh...@googlegroups.com
For sure - I think this newly suggested idea would get us there, and would be beneficial to PWM / fade shows as well:


This would effectively minimize blinking by having a minimum time period a light would be in the on state (in on/off mode) based on some configurable decay factor.

--
http://www.lightshowpi.org/
---
You received this message because you are subscribed to the Google Groups "LightShow Pi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/4F265DCE-882F-4FE3-9BAD-36620B4A6A7F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

chris usey

unread,
Dec 2, 2015, 12:27:09 PM12/2/15
to lightsh...@googlegroups.com
Ah ! Yes, this would be a good solution !


chris usey

unread,
Dec 2, 2015, 1:35:29 PM12/2/15
to lightsh...@googlegroups.com
If Im reading his example correctly, this is very similar to the and “limit”, “limit threshold”, and “max off cycles" options we used to use correct? 

On Dec 2, 2015, at 11:24 AM, Todd Giles <todd....@gmail.com> wrote:

Todd Giles

unread,
Dec 2, 2015, 2:15:03 PM12/2/15
to lightsh...@googlegroups.com
Yes - very analogous to them, but I like his proposal better, it's a bit cleaner and gives responsive off to on transitions, but delays the on to off transitions.  And it's all configured via a single "delay_factor".

chris usey

unread,
Dec 2, 2015, 9:00:18 PM12/2/15
to lightsh...@googlegroups.com
I quickly implemented this this afternoon. It gives a nice effect. While it does help with the blindly lights I find the lights are more ON now than off especially during bigger songs.  I'm thinking it may help to adjust the 0.5 setting that decides of the lights are on or off in onoff mode.  I'll play some more with the code and see if I can't come up with something 

chris usey

unread,
Dec 3, 2015, 2:20:46 PM12/3/15
to lightsh...@googlegroups.com
So while implementing this I found that it would be useful to have a show analyzer. A visual output isn't always available and judging some changes visually just isn't always accurate or very easy. 

I started building an analyzer that initially will can give a user useful feedback about a show. Mainly right now it will tell how often lights are on or off per channel, how much activity each channel sees. Blinking rates vs constant on and off rates, etc.  

I figured this could be useful when developing as well as provide useful info when trying to decide what lights a user would want to map to what channels based on their needs.

As of now it really only works in on off mode but it would be easy to expand to pwm as well to capture brightness data, etc.


What you guys think ? Suggestions, comments, concerns ?

Sent from my iPhone

On Dec 2, 2015, at 11:24 AM, Todd Giles <todd....@gmail.com> wrote:

Paul

unread,
Dec 3, 2015, 3:39:50 PM12/3/15
to lightsh...@googlegroups.com
Chris:
I built something similar a while ago to help test levels and networking. It sort of worked like a spectrum analyzer. That way I could "see" the levels of each channel (up to 16) to work on levels, etc.
I shared it with a few people on the forum last year for them to try to use for debugging streaming options (play music on PC but have pi blink along with it)
it's winders only otherwise I would have made it more available

either way, I think these sorts of tools can be very helpful in debugging and setting up displays.

cheers!
Paul

Todd Giles

unread,
Dec 3, 2015, 3:41:49 PM12/3/15
to lightsh...@googlegroups.com
Sounds like a great idea - I'd still like to get back and implement this related idea:


More specifically the part that would let you "see" your actual show on your actual home for a given song / configuration... 

-Todd

chris usey

unread,
Dec 3, 2015, 4:41:41 PM12/3/15
to lightsh...@googlegroups.com
Could that not be made easier to achieve now that we have network streaming ? Launch the show on the PI and capture the stream on a program running on a local machine?


Todd Giles

unread,
Dec 3, 2015, 5:15:13 PM12/3/15
to lightsh...@googlegroups.com
For sure, the network streaming would make this a ton easier ... I've got lots of ideas ... just not enough time ;)  Maybe Christmas break will provide me with a time to do some binge coding for the project ;)

chris usey

unread,
Dec 3, 2015, 5:21:17 PM12/3/15
to lightsh...@googlegroups.com
I agree thats the goal, but looking at my lights last night it was hard to simply look at what was going on and make adjustments. Playing with the blinkiness led for me needing more insight than I could gain with the eye. So out of that came the analyzer. Its nothing special but does what it needs to do. Ill have to do some cleanup to the code but here is an example of the output. I don’t think I took into consideration all the different aspects that can affect the calculation of the custom channel mapping, its just added here to show how it could benefit a user.




Reply all
Reply to author
Forward
0 new messages