Regarding the general direction of the project, it looks as if you're trying to display the audio frequency spectrum by dividing it into 16 equal bands. Actually that's kind of a bizarre selection, it's typically looked on as 30 or 31 1/3-octave bands, or 10 one-octave bands. If you divide it into 16 bands then I suppose they could be 2/3-octave wide each, of course you CAN do it that way (and digital filters can be created that are just that wide) but it kind of guarantees that the display won't be terribly "relevant" or meaningful (not that it has to be). And I guess this will just be the monophonic combination of left and right? Is the processing just going to send any and all filtered data to the display (more or less "peak-reading") or will there be peak-holding or even sample averaging? (There's a popular type of display that holds and illuminates peaks WHILE the instantaneous values dance beneath them, that actually has some utility as well.) Also I imagine you'll want to make this display logarithmic, with each LED representing 2 or 3 decibels higher level, and maybe even make the lower LEDs represent larger values (so the display comes closer to handling the much larger dynamic range that the ear responds to than just 32 or 48 decibels)? Will there be a provision to "calibrate" this so it can read actual sound levels? How about a "master level" channel to one side to show the unfiltered level? (You ought to think about whether you keep the lowest position always "on" as a kind of visual "anchor", it's commonly done that way anyway.) How is color going to be applied, there's a convention that "acceptable" levels at the bottom are green, levels above that are yellow, even higher are red, will you "go conventional" or do something out of the ordinary? These are all the kind of decisions you ought to think about before taking this to the next stage. (Then again maybe I'm just a LITTLE obsessive about this stuff since I used to design audio gear for sale to pros, back in another lifetime and maybe another universe, I can't really recall right now...)
is making use of an implicitly defined assignment operator, which I believe will only do a shallow copy. (There is a temporary Adafruit_NeoPixel created on the stack, which is then copied into the Adafruit_NeoPixel at strip[i].)
I'm assuming that the Adafruit_NeoPixel is the one defined here:
Perhaps an analogy might help with the pointer mystery:
Consider two ways you could get a package delivered to your house. The normal way: you give UPS your address and they send a cheerful driver in a brown truck to plunk the package down on your porch.
To save your poor driver some time, you could instead make a duplicate of your house, hire a house mover to move the house to the local UPS office where they put the package on the porch and have the mover bring the house back to you. The mover demolishes your original house and replaces it with the house that has your package which you open only to discover it's the wrong color and you have to ship it back....
Passing pointers instead of the whole object is more efficient. Of course there are some down sides to this. Giving your address to some hoodlums who come over and have a huge party and trash the place is not good. In that case, making a duplicate of the house that they can do what they want to with is a good option. You could also lock up certain parts of the house and post big signs that say "PRIVATE KEEP OUT" in those critical areas. Let them do what they want in the tornado shelter, just keep them out of the room with all the expensive antiques.
Pointer to a function? Same idea except now the memory pointed to contains code instead of data. It's like the address of your lawn mower. So you tell your son to work on his homework and every time he finishes one assignment to start the mower and mow one section of the lawn. You also tell him where the mower is in case he forgot. You sit in the garage watching the mower and every time you see it start up you know that another assignment was finished.
If you are still pondering about frequency detection you might conceder using the Goertzel algorithm to detect the energy in the 16 bins. The algorithm is more efficient then an FFT when measuring the energy at specific frequencies.
@JeffL: Regarding the general direction of the project, it looks as if you're trying to display the audio frequency spectrum by dividing it into 16 equal bands.
First let me remind you that if you go back to the beginning of this project, I did say that I don't really have a clue what I'm doing on the audio side -- I'm learning (or making it up) as I go along.
One of my early questions was whether the frequency spectrum (think horizontal axis) should be divided in a linear (equal bands) or logarithmic manner.
@JeffL: If you divide it into 16 bands then I suppose they could be 2/3-octave wide each, of course you CAN do it that way (and digital filters can be created that are just that wide) but it kind of guarantees that the display won't be terribly "relevant" or meaningful (not that it has to be).
I'm not so worried about the display being "relevant" as "looking pretty" -- what I really need is for someone who knows what they are talking about to say something like "OK Max, it's obvious you don't have a clue -- let's say the bottom frequency 'bucket' includes 50Hz and below, the top 'bucket' encompases 16KHz and above, and this is the way you should partition the rest of the spectrum into your remaining 14 'buckets'"
@JeffL: I guess this will just be the monophonic combination of left and right?
I'm intending to drive this from my iPad. I plan on feeding the stereo signal in. I plan on having several modes. One will be mono (I was thinking of sampling both channels, adding them together, and dividing by two) -- in which case the entire horizontal axis could be used to display the spectrum data from this mono channel.
I would also like to play with stereo displays. One way would be to split the horizontal axis into two 8-channel bands. Another way would be to keep the 16 bands, but display the left channel "growing up from the bottom" (to a max of 8 pixels tall) and the right channel "growing down from the top)" (to a max of 8 pixels).
@JeffL: Is the processing just going to send any and all filtered data to the display (more or less "peak-reading") or will there be peak-holding or even sample averaging? (There's a popular type of display that holds and illuminates peaks WHILE the instantaneous values dance beneath them, that actually has some utility as well.)
I was planning with the "any and all" approach to start off with. But then start playing with some more interesting effects like holding and illuminating the peaks -- and then having them gradually fall -- with the instantaneous values "dancing" below. (I wouldn't know "sample averaging" if it crawled up my leg and bit me in an unfortunate place).
Check out my earlier blogs on this BADASS Display tracing my thoughts (including some videos I saw on YouTube) and you will see just how little of a clue I have (Part 1, Part 2, Part3, and Part 4).
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.