To Todd and the dev group and the community at lagre

[Tom Enos]

I am going to drop the pull request that is currently pending, resync my master then then work down one or two at a time the current issues listed on the master branch and do some minor changes on the stable branch (code cleanup, docstrings, updating the install script)

I have brought over the latest working version of pygooglevoice to bitbucket and converted it to a git repository.

It looks maintainable, only changes to the regex that reads the login.  So now if the api changes we can update it ourselves.  I'll make notes in the docs for it as to give Ken Leidal credit for the initial code changes, but we should be able to handle it from here (as long as google plays nice).

I also think that by the end of july I should have my v2.0 code looking and performing like something that might be brought into the master branch (I used most of the code last Christmas and had no problems). It just need a little cleanup. 

I'm removing the gui for now as it is a sloppy hack that allowed it to work in a thread and the requirement for PyAudio made it hard to install in windows 64bit systems.  I can do it better, even if I have to redo the Lightshow designer I had started.  

Paul's network code was a delight to integrate, some config options and a few pickles and now it logs information and is customizable.

The web ui is going to be some work as it made a lot of changes to synchronized_lights.py,  but I'm sure that I can combine the two in to a full working version, end of July sometime in August at the latest.  

I wrote a simple ncurses editor for the configuration file.  It is prettied up by and editor module that I found on github.  https://github.com/firecat53/py_curses_editor

It works real nice over ssh.

This is just a general "I want to let you know what I am doing thread".  

Any question, concerns, doubts, or "HEY STOP", let me know, I will take no offence (it's hard to offend me, I don't take anything as personal), your project, I'm just part of the team (really just a team play, I will speak my mind, but a team player, democracy in action).

The team should speak up too, we are all working on this together, everyone has a say (the community is the house, the dev team is the senate, and Todd is POLSP (President of LightShow PI)).   Dont' leave me hanging people, encourage my thoughts, shoot them down, or point me in a new direction.  

If nobody responds I will keep making changes and updating to this forum.  But I do hope that people will at least respond @Paul Dunn, @Stephen Burning, @Chris Usey, @Micah Wedemeyer, and @Todd Giles and anyone else that wants a voice.  

[Stephen Burning]

I welcome any progress and getting rid of the issues is a great thing. I have not done any work on this since December, but I personally would love to have a web interface to control and setup everything similar to plex. I think to get to that point a steady code structure needs to be in place and this could be the start of that. So I am with you on this.

[Chris Usey]

Tom,

I look forward to downloading and looking at the changes. Thanks for all the hard work, the community should be grateful ! I don't have much to add on the changes as I have not had a chance to look at them.  I do have some ideas, as always, and I may have stated some of these before but Ill list a few again. 

One of my ideas and a project I hope to be able to tackle in the near future is something I have been wanting to get to for the last few years. That is to create an easy to maintain REST Like API interface first instead of creating the web interface.  I think this could provide a lot of value.  I really like the way the the WebiOpi framework operates in that regard. I have not had the time to dig into it to see if it's something that could be brought in to the project or if it's something we would be better off developing from the ground up. But an API would allow anyone to build their own interface and I would certainly put in the time to develop some cross platform native apps. 

My other goal is to tackle pixel lights. Individually manageable LED strings. I have some ideas in mind about how to go about it, but nothing I have tested yet. My initial thought is that each channel would be its own object, and each object would have its own set of properties that will define how it controls the type of lights assigned to it. Almost to the point where a channel could be assigned a specific driver per say that would control the lights on that channel. That driver would have access to all channels, and would dictate what those lights would do. I have not completely thought this out or had time to sit down and map this out, so bear with me on this idea lol.  But for example a string of Incandescent lights physically wired to SSR #1 would be the first object, and it would be assigned an incandescent blink driver. That object will be assigned to react to certain frequencies only, lets say in this case frequency bin 2.  A sting of Pixel Lights physically wired to SSR#2 would be the second object, and it would be assigned to a pixel lights driver. It would be configured to react to all the frequencies 1-8. The driver would be setup in a way that on frequency 1 it would change to red, frequency 2 it would change to blue, frequency 3, it would go into candy cane mode and so on and so on.  This may be totally undoable in the way I mentioned, it just me thinking out loud.  The main goal would be to have some type of class or driver that a user can implement or modify to say, I have these types of lights and I want them to react in this way for this frequency or I just want them to do this certain pattern regardless of the frequency.  Its something we can sort of do now, I think there is just a better and more easily customizable way of doing it. There may even be protocols out there that we can harness and use already, such as DMX or something.  Like I said this may be totally off the wall, I’m just thinking aloud.

Finally, I was thinking of separating the code that handles the frequency calculations. My Idea here is to allow the user to create their own set of parameters for how the frequencies are processed.  A frequency engine per say. That is to say, separate out the code, and allow the user to write their own or use one thats provided by specifying it in the configs.  I came up with this idea last year.  It came to light when we changed the way the frequencies were calculated to account for PWM and doing fading. I say we but that was Todd’s baby. I really liked the way My lights reacted to our initial implementation and I didn’t have a lot of use for PWM that was brought about in the last implementation, but do to the changes that were implemented to calculate for PWM it changed the way things were calculated in the initial implementation and ultimately the way the lights reacted to the new implementation.  Separating out the frequency calculation code, and allowing the user to write their own if they wish and easily be able to specify what to use in the configs would help make the system more customizable. 

Once again, this is just me speaking out loud and I haven’t tested or played with any of these ideas. At this time I think its more important that we try to fix any issues that we have now and get a stable update out, and then look to implementing some of our other feature ideas. I used our master branch last year and I think we should concentrate on cleaning that up and getting the bugs out first. Im going to look at my schedule and try to carve out some time that will allow me to work on this at least a few hours a week until I can commit more time. Keep moving forward Tom, I don’t think anyone in the community has a problem with that. I for one appreciate the time you have been putting into the project and this project is just as much yours now as it is anyone else’s. Its open source for a reason, and I don’t think anyone wishes to slow you down !

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/0ed2f394-884c-4c6d-a922-ab42d824739b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Enos]

Please keep speaking out loud, I like what I here.  Adding pixel support would be great.  We would either have to write extensions to wiringPi and python-wiringPi or write our own C libraries and python interface to control the led drivers.  There are a few already a few spi devices out there that have the python interface.

With the different pins setup as objects passing the correct function as a parameter could be the option needed.  So it sounds very doable.

An API for interface first.  That should be one of our short term goals.  I have seen several webUi's in the community, all hook-in to lightshowPi in a different way.  @Stephen's webUi makes major changes to the code base (but looks and works great), A RESTful like API would make going forward a lot easier.  Set the structure and then you don't have to worry about changes to the back end breaking features, as long as we follow the API.

More frequency control.  Do you still have copies of the old code, before PWM was added?  I'd like a look.

I have gotten myself some experience recently with the FFT.  I'm porting lightshowPi to java, just to learn java.  I've been doing it for several months now and the fft is a fun puzzle, still working on it, but as least I have an idea of the way it works now or at least I think I do :)  

Separating out the code that does the frequencies is the easy part.  These three lines are what makes it work

    octaves = (np.log(max_frequency / min_frequency)) / np.log(2)
    octaves_per_channel = octaves / channel_length
    frequency_limits.append(frequency_limits[-1] * 10 ** (3 / (10 * (1 / octaves_per_channel))))

The rest of it just processes the custom frequencies and maps.  It could be broken in to multiple methods and call on different variables or maybe different algorithms specified in a config file.

I am looking forward to working with you on these ideas.

I will do some research on spectrum analysis.  

[Tom Enos]

It looks like we are going to start working on an API in the near future that will make doing a webUi a lot easier.

But first code cleanup and bug fixes.   

[Todd Giles]

On Wednesday, June 24, 2015 at 12:39:13 PM UTC-6, Tom Enos wrote:

Please keep speaking out loud, I like what I here.  Adding pixel support would be great.  We would either have to write extensions to wiringPi and python-wiringPi or write our own C libraries and python interface to control the led drivers.  There are a few already a few spi devices out there that have the python interface.

With the different pins setup as objects passing the correct function as a parameter could be the option needed.  So it sounds very doable.

An API for interface first.  That should be one of our short term goals.  I have seen several webUi's in the community, all hook-in to lightshowPi in a different way.  @Stephen's webUi makes major changes to the code base (but looks and works great), A RESTful like API would make going forward a lot easier.  Set the structure and then you don't have to worry about changes to the back end breaking features, as long as we follow the API.

More frequency control.  Do you still have copies of the old code, before PWM was added?

Here is when I took it completely out (i.e. follow the logic when it was not a PWM pin):

https://bitbucket.org/togiles/lightshowpi/commits/339c37490446db8c47ff36384b29d91dd2a1a1f0?at=master

This is currently the logic that now sits in update_lights --- I have had many ideas around making all this more modular, just no time.  Main idea is to do something similar as you've helped put together Tom for the preshow / postshow - namely a plugable implementation of update_lights where we pass in all the data we have and different implementations could handle turning lights on / off differently.  We could do the same for the fft calculations, allow for a more general "analysis" of the audio, followed by the "control" portion... each being plugable.

Others in the group have had similar ideas - but basically the idea is to continue to make the main flow much more modular such that it is easier to put in various implementations of each various stage.

 

I'd like a look.

I have gotten myself some experience recently with the FFT.  I'm porting lightshowPi to java, just to learn java.  I've been doing it for several months now and the fft is a fun puzzle, still working on it, but as least I have an idea of the way it works now or at least I think I do :)  

You may have figured this out by now, but fftw has been the most widely used open-source library for calculating FFTs - there are java ports / wrappers available:  http://www.fftw.org/download.html

You seem fully capable, but if you have questions on this portion, I'd love to stay involved ... I do have a MSEE with an emphasis on image processing from my past where FFTs were basic building blocks of the work done ;)  (in imagery, you're simply doing a 2 dimensional FFT versus the 1 dimensional FFT of an audio clip).

 

Separating out the code that does the frequencies is the easy part.  These three lines are what makes it work

    octaves = (np.log(max_frequency / min_frequency)) / np.log(2)
    octaves_per_channel = octaves / channel_length
    frequency_limits.append(frequency_limits[-1] * 10 ** (3 / (10 * (1 / octaves_per_channel))))

The rest of it just processes the custom frequencies and maps.  It could be broken in to multiple methods and call on different variables or maybe different algorithms specified in a config file.

We're kind of thinking along the same lines, see my comment above.

 

I am looking forward to working with you on these ideas.

I will do some research on spectrum analysis.  

See my comment above, happy to help answer questions in this area that I can...

[Tom Enos]

Great,  after I do the cleanup I'm working on, and tackle a few issues I would like to start to work on making some or the code more modular.  I have a few ideas, I just don't know what the performance hit might be, but that is something that can be worked out.  

FFTW, I looked into that.  I think I disregarded it because it was not going to be easy for the user to install. 

I want to have as few external dependencies as I can

 

I Found this project on google code https://code.google.com/p/audio-analysis/

In particular these two classes 

https://code.google.com/p/audio-analysis/source/browse/trunk/src/com/badlogic/audio/analysis/FFT.java

https://code.google.com/p/audio-analysis/source/browse/trunk/src/com/badlogic/audio/analysis/FourierTransform.java

I'm still studying the library, but I made a few tweaks to them and it seems to work great.  And best of all I don't need to work out the real and imagined parts of the complex numbers, just read in the audio as a byte array, convert to a double array and toss it to the library.  For now it's fine,  after I figure the fft out a little better then I will write my own.    

As it sits now I use four external libraries, the above fft libraries, pi4J, GSON, and argParser4j.  

I plan on writing my own argParser and jsonParser next, and then the fft if I can figure it out.

I had to write my own configParser because of the multiline json in lightshowPi's config file, I could not find anything that would read it correctly. And that has motivated me to reduce my reliance on external libraries. 

As I said it's to teach me java, and what better way to learn is there then to reinvent the wheel.

[Todd Giles]

I've already written FFT from scratch back in college ... don't have any desire to do that again ;)

If you are simply doing it to learn, go at it!  For performance though - benchmarks last I looked still show fftw above any other open source libraries I know ... and a quick search now shows others still feel that way:

http://stackoverflow.com/questions/3287518/reliable-and-fast-fft-in-java

You could perhaps use it as a benchmark to see how well your version does from a speed perspective.

If only I didn't have a day job ... would be diving into this more with you!

-Todd

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/c0d05c79-03cd-41cd-b70d-5c243b037f6f%40googlegroups.com.

[Todd Giles]

Found another java implementation with the express goal of code clarity (and not speed):

http://introcs.cs.princeton.edu/java/97data/FFT.java.html

Might be worth referencing as you are wrapping your head around the fft ;)

-Todd

[Tom Enos]

I have seen this one.  It is a well documented file.  An I have gotten a lot from it.  I just need to spend more time on it.

[Tom Enos]

I will defiantly do that. If my version is slow then there really is no need to use it.