individually controlled rgb leds

[Tom Enos]

Test code

https://tom_...@bitbucket.org/tom_slick/lightshowpi.git

git fetch && git checkout lightshowpi-led

It is tested and working with APA102's and WS2801's and it should work with LPD8806's 

This is not production code.  It will work with led strips or gpio pins, but not both at the same time.

This is just to work out any problems with strips.  Paul Barnett has offered to work on this with me.

After we work out all the bugs I will make it so that we can use led strips and the gpio pins at the 

same time. 

It might be worth writing a few animations that could be trigger by frequency.  They could be used for things like leaping arches, spirals wrapped around Paul Dunns tomato cages, a star make up of a few pixies, etc.....

 

[Paul Barnett]

I have a specific design in mind for next Christmas, using this:

http://www.thelashop.com/4-ft-clear-led-lighted-spiral-christmas-tree-cool-white.html

It's on clearance at $20 right now, with free shipping.

All the LEDs are on the same 2-wire circuit, but I suspect they alternate polarity.   The "animations" are variations on two subsets of lights.  Since they are powered by 3 AA batteries, I might be able to connect them to a GPIO port with a level shifter.  But, I didn't buy it for that reason -- I removed the lights, including the 11 in the star at the top.  The full length is 44 feet, so I should be able to replace it with 7 RGB LED strings from Adafruit (each has 25 LEDs, 6.25 feet in length), using the plastic "cable tray" as a guideway.

I'll explain my plan -- if we can enable it in the code, that would be great...  but only if it can be done in a way that is useful to other people.

I haven't committed to AC light control, but if I do so it will be for a string of lights on our house.  I'm not yet sure of the power requirements, so I may have to spread it across multiple SSRs.  However, all I want to do is simply bring up the lights to full intensity in "idle" state, and dim them to 30-50% when the "show" starts.  

For the "pre-show", I'd like to implement some animations, but only on the spiral tree.  I have a few in mind, but the most "specific" one is a few pixels racing up the spiral and "exploding" at the star, which dims as random pixels flash in a descending shower.  It's supposed to look like launch of fireworks.  

So, with this in mind, I have a few specific suggestions for implementation, in no specific order:

1. Tom has already said he wants to be able to use LED strips and GPIO pins in the same configuration.  I'll suggest something simple:  assign LED 0 to "channel" 100, and increment from there.  I don't think we can put more than one strip on an RPi, but is it possible to network multiple RPi's and drive each one separately?   I haven't yet looked closely at the new networking functionality.
2. Allow specification of a "plugin" function in the preshow configuration.  It would make it much easier for someone to write a custom animation.  It could be as simple as a *.py file following a template, imported at runtime.  The animations that Tom suggested could be seeded as examples, along with ON and OFF "animations" -- and I could write a FADE animation.  Could we use the same methodology for frequency-triggered animations?
3. Since the RGB strips offer such a wide variety of colors, users may want an alternate color map for different occasions (Christmas, Halloween, etc.), or to match the other lights in their display.  After looking at Tom's use of the color map in bibliopixel, I'd like to provide a way to specify an alternate color map.  It is most easily built in Python, so a plugin function would be appropriate.   As a stretch goal, maybe we could add a color map parameter to the playlist, and users could choose different ones per song.
4. Some of the LED strips have a very small pitch.  I found one with 60 LEDs per meter, or about 0.65 inches apart:  https://www.adafruit.com/products/1138.  Yes, that's overkill, and I'm not sure bibliopixel would support it.  But, I wanted to make the point that a user might want to map a channel to multiple LEDs to increase the apparent size -- either adjacent or distributed among the strip.  For instance:  map 25 channels onto a 100 LED strip.   I THINK that can be done with custom_channel_mapping, but if not -- we should implement a way to do it.

BTW, Tom has reported that he has tested up to 200 LEDs on a strip.  I just tried 500 LEDs, and it's working fine on a RPi 2 B+, after I ran an initial pass to create the cache file (which is 116 MEGAbytes, and takes a while to load).   CPU utilization is solid at 67-69% (of a single CPU).  So, Tom's color map optimization is a HUUUUUGE improvement.  :-)   

Of course, I have no way to know if a 500 LED strip actually looks right, as I can only display the lowest 10 channels.  The data is shifted serially from the first LED to the next until it reaches the end of the strip, and it may not be synchronized to the music by the time it reaches the last LED.

Tom, my Python skills are a bit rusty, as it has been a few years since I've written anything significant.   But, I'm willing to take on any of these tasks, provided that you point me in the desired direction so you don't have to do a lot of rework.

I'm planning to procure the first of my hardware next month, and continue the procurement through the summer.  Since we are both retired now, I have to stay within our monthly budget!

On Friday, January 22, 2016 at 10:30:52 PM UTC-6, Tom Enos wrote:

Test code

https://tom_slick@bitbucket.org/tom_slick/lightshowpi.git

[Tom Enos]

Tom has already said he wants to be able to use LED strips and GPIO pins in the same configuration.  I'll suggest something simple:  assign LED 0 to "channel" 100, and increment from there.  I don't think we can put more than one strip on an RPi, but is it possible to network multiple RPi's and drive each one separately?   I haven't yet looked closely at the new networking functionality.

I was thinking along these lines.  But was thinking of starting at 1000 to leave room for other i2c and spi devices.  But it really doesn't matter where we start it's all the same.  I'm working on this right now.  I'll have something up for testing in a few days.

Allow specification of a "plugin" function in the preshow configuration.  It would make it much easier for someone to write a custom animation.  It could be as simple as a *.py file following a template, imported at runtime.  The animations that Tom suggested could be seeded as examples, along with ON and OFF "animations" -- and I could write a FADE animation.  Could we use the same methodology for frequency-triggered animations?

It's already part of the code.  The preshow can launch an external script.  It might need a little tweaking to work with led strips, but it's already there.

Since the RGB strips offer such a wide variety of colors, users may want an alternate color map for different occasions (Christmas, Halloween, etc.), or to match the other lights in their display.  After looking at Tom's use of the color map in bibliopixel, I'd like to provide a way to specify an alternate color map.  It is most easily built in Python, so a plugin function would be appropriate.   As a stretch goal, maybe we could add a color map parameter to the playlist, and users could choose different ones per song.

Easy to implement and a good idea.  The hard part will be coming up with a color pallet that looks good.  While the current color_map works.  I still am not quite happy with it.  I'm thinking maybe taking a smaller sampling of colors. 

Some of the LED strips have a very small pitch.  I found one with 60 LEDs per meter, or about 0.65 inches apart:  https://www.adafruit.com/products/1138.  Yes, that's overkill, and I'm not sure bibliopixel would support it.  But, I wanted to make the point that a user might want to map a channel to multiple LEDs to increase the apparent size -- either adjacent or distributed among the strip.  For instance:  map 25 channels onto a 100 LED strip.   I THINK that can be done with custom_channel_mapping, but if not -- we should implement a way to do it.

I was thinking of something like this to.  Something like a pixel group.  

[Tom Enos]

I have updated my repo.  Now supports using led strips and the gpio pins at the same time.    

I even managed to eek out a performance gain.  

Changed the color_map to reflect Paul's testing.

A big refactor of hardware_controller.py.

Now a class, each channel is an object and individual options can be set. 

No overrides for led strips, as coded they would not work right anyway.

Changed command line options, I was working on an experimental version and just used that, run sudo python hardware_controller.py to see changes.

sage: hardware_controller.py [-h] [--test] [--flash] [--fade] [--cylon]
                              [--dance] [--step] [--random_pattern]
                              [--lights_in_group LIGHTS_IN_GROUP]
                              [--pwm_speed PWM_SPEED] [--cleanup]
                              [--lights_on] [--lights_off] [--light LIGHT]
                              [--sleep SLEEP] [--flashes FLASHES]
optional arguments:
  -h, --help            show this help message and exit
Hardware test:
  Run a basic hardware test to insure everything is working
  --test                Run a basic hardware test
Test patterns:
  Different patterns to display
  --flash               Fade lights in sequence
  --fade                Fade lights in and out in sequence
  --cylon               Lights one channel at a time in order Then backs down
                        to the first rapidly
  --dance               Start at each end and dance to the other
  --step                Test fading in and out for each light configured in
                        pwm mode
Random_pattern:
  Display a random pattern of lights
  --random_pattern      Display a random pattern of lights
  --lights_in_group LIGHTS_IN_GROUP
                        number of light in a group as an int
  --pwm_speed PWM_SPEED
                        time in seconds to full on or off as a float
States:
  Different states that the lights can be left in
  --cleanup             Reset GPIO to default state
  --lights_on           Turn on the lights
  --lights_off          Turn off the lights
Option:
  Options that can be used with all of the above except Random Pattern which
  has it own options
  --light LIGHT         the lights to act on (comma delimited list), -1 for
                        all lights
  --sleep SLEEP         how long to sleep between flashing or fading a light
  --flashes FLASHES     the number of times to flash or fade each light

My goal is 300 leds on a B+,  a 2B can do over 500 leds right now  I am upto about 260 on a B+ (I test on my weakest hardware) and if I keep banging at the code I know I can reach my goal.

Even with Paul's suggestions I still don't like the colors and brightness, better but still missing something.  

For the most part I see these led strips as a tool to create objects to use with the show, not for the show it self.  I am trying, but cpu power is the limiting factor.  Frequency triggered animations would be easier to program, easier on the cpu, and allow for more flexibility, unless you want to map 200+ channels in custom_channel_frequencies and custom_channel_mapping.

On Friday, January 22, 2016 at 8:30:52 PM UTC-8, Tom Enos wrote:

Test code

https://tom_slick@bitbucket.org/tom_slick/lightshowpi.git

[Paul Barnett]

Tom, I've checked out this version, and it's working fine for me.  config/defaults.cfg needs an update:  it still says gpio and led strip support are exclusive.

With respect to the colors/brightness, one thing you might consider is the calculation of brightness in update_lights():

brightness = matrix - mean + (std * 0.5)

brightness = (brightness / (std * 1.25)) * (1.0 - (attenuate_pct / 100.0))

Changing the multipliers to std may yield a result you like.  

Reducing the color map to a set of primary colors may help.   My first public display will probably be on July 4th, and I'm experimenting with a color map that is exclusively red, white, and blue.   I'm not quite sure how I will distribute it.

Another possibility is to leave the brightness at maximum at all times, and simply select from the "rainbow" color map.   Depending on how the LED strip is used, it may be appropriate.

I've just ordered a subset of the hardware needed for my build (an RPi 2B and 50 LEDs), so I should be able to better evaluate the various alternatives. 

I noticed one idiosyncrasy, with:

gpio_pins=  (i.e. none), 

led_count=3

and running py/configuration_manager.py, I get:

gpio_pins=[1000, 1001, 1002]

But, if I set:

gpio_pins=0

led_count=3

I get:

gpio_pins=[0, 1000, 1001, 1002, 1003]

There's one extra "pin" for the LED strip.   I took a quick look at the code, and I don't see an obvious problem.  And, I'm not sure that it has any ill effects, as the debug log shows that it calculates the frequencies for 4 channels.  For that matter, configuration_manager.py also shows:

gpio_len=4

[Tom Enos]

Tom, I've checked out this version, and it's working fine for me.  config/defaults.cfg needs an update:  it still says gpio and led strip support are exclusive.

I just haven't gotten around to it.  Work in progress

 

With respect to the colors/brightness, one thing you might consider is the calculation of brightness in update_lights():
brightness = matrix - mean + (std * 0.5)
brightness = (brightness / (std * 1.25)) * (1.0 - (attenuate_pct / 100.0))

That will affect the gpio results so not an option.

As for setting gpio_pins = 0 that is the way it is suppose to be.  Use gpio pin 0 in the show.

gpio_pins is a list of the pins to use, for example gpio_pins = 0, 1, 2, 3, 4, 5, 6, 7, 21, 22, 23, 24, 25, 26, 27, 28 

[Paul Barnett]

On Friday, January 29, 2016 at 12:21:14 PM UTC-6, Tom Enos wrote:

With respect to the colors/brightness, one thing you might consider is the calculation of brightness in update_lights():
brightness = matrix - mean + (std * 0.5)
brightness = (brightness / (std * 1.25)) * (1.0 - (attenuate_pct / 100.0))

That will affect the gpio results so not an option.

Yes, I know.  But, maybe a different algorithm could be used for the LEDs.  

 

As for setting gpio_pins = 0 that is the way it is suppose to be.  Use gpio pin 0 in the show.

gpio_pins is a list of the pins to use, for example gpio_pins = 0, 1, 2, 3, 4, 5, 6, 7, 21, 22, 23, 24, 25, 26, 27, 28 

I don't think I explained it well:  what I observed that adding a GPIO pin, also added a LED pin, i.e.:

gpio_pin=  yields:  gpio_pins=[1000, 1001, 1002]

but:

gpi_pin=0 yields:   gpio_pins=[0, 1000, 1001, 1002, 1003]

So, the length of gpio_pins[] in the second case is 5, although there is only 1 GPIO pin and 3 LEDs.

However, as I noted -- the configuration manager reports gpio_len=4, so that's correct.  As long as every reference to length uses that value, rather than the length of gpio_pins[], all will be fine.  But, if anything uses len(gpio_pins), it will be processing some extra pins for LEDs that don't exist.

I dug into the code, and I found it in configuration_manager:221:

self.gpio_len += hrdwr["led_count"]

hrdwr["gpio_pins"].extend([_ + 1000 for _ in range(self.gpio_len)])

hrdwr["pin_modes"].extend(["pwm" for _ in range (hrdwr["led_count"])])

In the second line, it's using self.gpio_len to extend the list.  But, it's already been incremented by led_count.  So, in the case above, it's extended by 1+3 elements, instead of 3.

The following line is similar, but it uses hrdwr["led_count"] instead.

Am I missing a requirement elsewhere for that?  After making that change, it's working fine for me, but I have a limited configuration.

It appears to be benign, but in your quest for optimization I thought it might help a little if any other code doesn't use self.gpio_len.

[chris usey]

Wow this is great stuff, spent a little bit of time today trying to catch up on what you guys have been doing. I have intentionally been staying away in order to get some other things done. Have started working on my masters degree this semester, so that is at my forefront at the moment.  But this is exciting. Great job, looking forward to checking all of the stuff out really soon. Tom, also seen your comment regarding the XML configuration plan to look into that or a little later and respond to you.

- Chris

--
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/0b7c4675-aa16-4fa9-ad5a-fcb800a1ca46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Barnett]

Tom,

I built a new Raspian SD card today, for a new RPi that should arrive Tuesday.  I started from NOOBS, as I couldn't clone my existing one for some reason.

In doing so, I discovered something that should be added to the ToDo list, if you don't already have it:  the spidev package must be installed.  

I also had to enable the SPI module in raspi-config, under "advanced options".

If you like, I can look at the install script and figure out how to add these.....

[Tom Enos]

I'll add it to the installer. We just need to add the package name to the list.  As for enabling the SPI module we should leave that to the user todo.  Not all users will want to use SPI, some will want to use those pins for other things.

[Tom Enos]

I just checked and it's already listed in the installer.  Are you sure you needed to install it?

[Paul Barnett]

Oh, crud.  I just repeated what I remembered was needed, and forgot to look at whether spidev was already installed when I ran apt-get.  It was probably there, but I've already pulled the SD card and rebooted with the original one.

And, I understand the issue with enabling SPI -- we can just add it to the config file....

[Tom Enos]

The installer installs it through pip, so if you used apt-get it would install again.

[Tom Enos]

Updated the code, I used every trick I knew to speed things up.  I will now support over 500 leds after cache.  I also added the command line option --createcache, it creates the cache without playback which speeds up the process.  

On Friday, January 22, 2016 at 8:30:52 PM UTC-8, Tom Enos wrote:

Test code

https://tom_slick@bitbucket.org/tom_slick/lightshowpi.git

[Paul Barnett]

I'm planning to download this in the next few days and test it -- probably on Monday.  This weekend is shaping up to be busy.

I just got a new RPi 2 and another 50 LEDs, so I now have a total of 60 (eventually, I expect to have 185).  Once I secure the lights to the top of a spiral tree, I'll experiment with different color maps and thresholds. 

I went to an auto parts store yesterday to buy wire, connectors, fuse block, fuses, heat shrink tubing, etc.  The guy at the register looked at my pile of stuff and asked:  "what the heck are you building?!".  :-)    I explained that it was all 5V, but 12V parts would work fine.....

For what's it's worth, you can easily convert a newer ATX power supply (with a 24-pin connector) to power multiple RGB LED strips and an RPi by simply shorting pin 16 to ground (simulating Power-On).  That's enough to get mine to start up, and I can use the various +5V lines to power everything.   But, I highly recommend fusing the 5V lines, as the power supply will be happy crank up the amperage....  mine will put out 30A in the absence of any other load on 3.3V or 12V.

[Paul Barnett]

I had a few minutes this evening, and installed the latest version.  It's working great for me, and I really like the new --createcache option!

Tom, if you like -- I can send you some code that uses the glob package, so that you can specify a pattern for the filename, i.e. *.mp3.   Then, you can build the cache for your entire library at one time.

[Tom Slick]

I have code that will build the cache for an entire playlist, I just didn't include it because I was only testing with one file and changing the led count.  I didn't need to cache multiple files.  

On Sat, Feb 6, 2016 at 4:18 PM, Paul Barnett <paul.thom...@gmail.com> wrote:

I had a few minutes this evening, and installed the latest version.  It's working great for me, and I really like the new --createcache option!

Tom, if you like -- I can send you some code that uses the glob package, so that you can specify a pattern for the filename, i.e. *.mp3.   Then, you can build the cache for your entire library at one time.

On Friday, February 5, 2016 at 5:46:13 PM UTC-6, Paul Barnett wrote:

I'm planning to download this in the next few days and test it -- probably on Monday.  This weekend is shaping up to be busy.

I just got a new RPi 2 and another 50 LEDs, so I now have a total of 60 (eventually, I expect to have 185).  Once I secure the lights to the top of a spiral tree, I'll experiment with different color maps and thresholds. 

I went to an auto parts store yesterday to buy wire, connectors, fuse block, fuses, heat shrink tubing, etc.  The guy at the register looked at my pile of stuff and asked:  "what the heck are you building?!".  :-)    I explained that it was all 5V, but 12V parts would work fine.....

For what's it's worth, you can easily convert a newer ATX power supply (with a 24-pin connector) to power multiple RGB LED strips and an RPi by simply shorting pin 16 to ground (simulating Power-On).  That's enough to get mine to start up, and I can use the various +5V lines to power everything.   But, I highly recommend fusing the 5V lines, as the power supply will be happy crank up the amperage....  mine will put out 30A in the absence of any other load on 3.3V or 12V.

On Friday, February 5, 2016 at 10:29:17 AM UTC-6, Tom Enos wrote:

Updated the code, I used every trick I knew to speed things up.  I will now support over 500 leds after cache.  I also added the command line option --createcache, it creates the cache without playback which speeds up the process.  

On Friday, January 22, 2016 at 8:30:52 PM UTC-8, Tom Enos wrote:

Test code

https://tom_...@bitbucket.org/tom_slick/lightshowpi.git

git fetch && git checkout lightshowpi-led

It is tested and working with APA102's and WS2801's and it should work with LPD8806's 

This is not production code.  It will work with led strips or gpio pins, but not both at the same time.

This is just to work out any problems with strips.  Paul Barnett has offered to work on this with me.

After we work out all the bugs I will make it so that we can use led strips and the gpio pins at the 

same time. 

It might be worth writing a few animations that could be trigger by frequency.  They could be used for things like leaping arches, spirals wrapped around Paul Dunns tomato cages, a star make up of a few pixies, etc.....

 

--

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/be75add9-dc5e-4e05-80f3-4f60d144a953%40googlegroups.com.

[Paul Barnett]

I tried the script in the tools folder to build my entire cache, but had an issue with it.  It wasn't that important, so I didn't pursue it.  

However -- with this new parameter, you can do it with a shell-script now:

for f in music/*.mp3; do 

  python py/synchronized_lights.py --createcache --file $f 

done

But, one thing that would be nice about adding a pattern match:  you could specify an expression that matches a subset of files.  That might not be that interesting for creating the cache, but could be used to play a set of mp3's at one time.  I don't know if that's ever been a requested feature, but I realize that doesn't fit with the current .playlist file and playing only one .mp3 at a time.

I add the filename globbing out of habit, as most of the Python scripts I wrote years ago were to read many files of data and transform them into a single file that was more understandable, or at least could be loaded into Excel.

On Saturday, February 6, 2016 at 6:24:52 PM UTC-6, Tom Enos wrote:

I have code that will build the cache for an entire playlist, I just didn't include it because I was only testing with one file and changing the led count.  I didn't need to cache multiple files.  

On Sat, Feb 6, 2016 at 4:18 PM, Paul Barnett <paul.thom...@gmail.com> wrote:

I had a few minutes this evening, and installed the latest version.  It's working great for me, and I really like the new --createcache option!

Tom, if you like -- I can send you some code that uses the glob package, so that you can specify a pattern for the filename, i.e. *.mp3.   Then, you can build the cache for your entire library at one time.

On Friday, February 5, 2016 at 5:46:13 PM UTC-6, Paul Barnett wrote:

I'm planning to download this in the next few days and test it -- probably on Monday.  This weekend is shaping up to be busy.

I just got a new RPi 2 and another 50 LEDs, so I now have a total of 60 (eventually, I expect to have 185).  Once I secure the lights to the top of a spiral tree, I'll experiment with different color maps and thresholds. 

I went to an auto parts store yesterday to buy wire, connectors, fuse block, fuses, heat shrink tubing, etc.  The guy at the register looked at my pile of stuff and asked:  "what the heck are you building?!".  :-)    I explained that it was all 5V, but 12V parts would work fine.....

For what's it's worth, you can easily convert a newer ATX power supply (with a 24-pin connector) to power multiple RGB LED strips and an RPi by simply shorting pin 16 to ground (simulating Power-On).  That's enough to get mine to start up, and I can use the various +5V lines to power everything.   But, I highly recommend fusing the 5V lines, as the power supply will be happy crank up the amperage....  mine will put out 30A in the absence of any other load on 3.3V or 12V.

On Friday, February 5, 2016 at 10:29:17 AM UTC-6, Tom Enos wrote:

Updated the code, I used every trick I knew to speed things up.  I will now support over 500 leds after cache.  I also added the command line option --createcache, it creates the cache without playback which speeds up the process.  

On Friday, January 22, 2016 at 8:30:52 PM UTC-8, Tom Enos wrote:

Test code

https://tom_slick@bitbucket.org/tom_slick/lightshowpi.git

git fetch && git checkout lightshowpi-led

It is tested and working with APA102's and WS2801's and it should work with LPD8806's 

This is not production code.  It will work with led strips or gpio pins, but not both at the same time.

This is just to work out any problems with strips.  Paul Barnett has offered to work on this with me.

After we work out all the bugs I will make it so that we can use led strips and the gpio pins at the 

same time. 

It might be worth writing a few animations that could be trigger by frequency.  They could be used for things like leaping arches, spirals wrapped around Paul Dunns tomato cages, a star make up of a few pixies, etc.....

 

[Tom Enos]

That tool is out dated.  

You do know that you can create a playlist and then play it continually with the start_music_and_lights script in the bin folder?

and bash can do arrays

for f in music/*.mp3 music/*.wav music/*.ogg; do  

    python py/synchronized_lights.py --createcache --file $f
done

[Paul Barnett]

Tom,

I ran into a strange end case.  I'm not sure that anyone else will encounter it, but I'll explain it and you can decide whether to pursue it.

The case is:  there's a SINGLE channel:  either one GPIO pin, or 1 LED, i.e a configuration like this:

[hardware]

gpio_pins=

led_strip_type=WS2801

led_count=1

It throws an exception here:

Traceback (most recent call last):

  File "py/synchronized_lights.py", line 964, in <module>

    play_song()

  File "py/synchronized_lights.py", line 879, in play_song

    update_lights(matrix, mean, std)

  File "py/synchronized_lights.py", line 242, in update_lights

    for pin in xrange(len(brightness[:i])):

IndexError: invalid index to scalar variable.

The reason:  brightness is a scalar value, not an array where len(brightness) = 1.

I should note:  this problem only appears to occur AFTER the cache file is created.  So, maybe the cache-loading is the real issue?

You are probably wondering:  why would I want to do this?  I'm experimenting with a different way to use the LEDs:  rather than assigning a different frequency band to each LED, I'm treating the entire LED strip as a single channel and using the amplitude of the full audio spectrum to set the brightness.

Then, I'm writing an "animation" to occur at the same time -- something like a shifting rainbow or subset of colors.  So, the amplitude will vary in time with the music, while the colors shift.  It's still a work-in-progress, but once I have a working example and have constructed the first part of my planned display, I'll upload a movie to demonstrate it.

I added a dummy GPIO channel, then used custom_channel_frequencies to map the full audio spectrum to the LED channel.   So, this isn't impeding me at the moment.  If you don't get to it first, I'll go back and look at the cache loading and see if that's the source of the problem, and keep digging if it's not.  But, I want to follow through on this alternate methodology first.

On Friday, February 5, 2016 at 10:29:17 AM UTC-6, Tom Enos wrote:

[Tom Enos]

Fixed.  just needed to explicitly set the default minimum shape when the cache is loaded. 

[Ken B]

I've done a few days of testing with minimal mods based on Tom's lightshowpi-led and the AllPixel board ( http://maniacallabs.com/allpixel/ ) and the results are very promising. It drives a large number of leds ( ~300 easily ) with what appears to be low CPU utilization ( at least on a Pi 2 ), and has the capability of driving a wide range of chipsets. Currently selling for about $28. It's a usb-serial based device that drives the data wire or data and CLK wires. Some soldering is required to get it going. The power supply ground must be tied to the board GND, btw. It's been rock-solid on 8 x 36 pixels after lowering the refresh rate to half of the GPIO rate, running for hours at a time without issue, and very acceptable perceived "framerates"