Timing control

[chris usey]

So I've had an idea for a new feature, and I'm looking for some input. This came about a few years ago when I created a custom truck and I wanted all of my lights to be off for about a minute and a half, I had to manually edit the file back then and I never search for an easier method. This would be targeted as 2.0. I know there are other issues that need addressing but this is a current issue of mine.

So I started to implement a timing mechanism. The timer starts when I song is playing and the seconds are calculated as it goes. I have not worked out the details but the idea is that a user can define a pin as well as a time and a method such as on off, etc. four example a user can say pin seven off at 0 seconds and on at 10 seconds when the song starts playing channel 7 will not come on until 10 seconds into the song. The user would be able to define multiple channels and multiple times per channel. This would not affect the cache song, as this would be executed during playback before the signal is send to the hardware controller. So there would be no need to re-cache if the settings are changed. I'm initially worried about the additional code affecting the playback and I'm looking for feedback for a couple of things:

1. Should this be done pre-cache so that the values are recorded and stored in the cache file. Or would it be better to leave it the way I have it in the outline above?

2. Should this all be done in the synchronized lights file and handled before the hardware controller is called to switch a light? Or might it be better to decide the state of a channel in synchronized lights and record that in the state.conf file and let hardware controller check that each time it goes to fire a pin? That would involve a lot of reads and writes into the file, but this could serve a greater purpose in the future for checking if a pin is active or inactive during playback at a certain point in the song. Or might there be a better way to store this info instead of in the conf file. Just thinking aloud here.

3. I imagine this could act as a global setting for all songs to create some effects, but I was thinking this would serve a much greater purpose as a per song config. What do you think?

4. I have a proof of concept in the works and initial testing makes me excited to have this sort of flexibility. Would this prove useful to others, and does it fit in with our goals?

I know there is a lot to be taken care of as far as issues etc, but this has been consuming me as of late and I can't help but get this working as I have an immediate use for it. This would provide a lot of flexibility to users who wish to get in and further customize their shows. Do you guys think this is the best method to achieve what I am describing. A lot of thinking out loud here, just wanted to get it out of my head before forgetting it. Sorry for any typos, using dictation as I drive !

[Todd Giles]

On Wed, Dec 9, 2015 at 9:12 AM chris usey <chris...@gmail.com> wrote:

So I've had an idea for a new feature, and I'm looking for some input. This came about a few years ago when I created a custom truck and I wanted all of my lights to be off for about a minute and a half, I had to manually edit the file back then and I never search for an easier method. This would be targeted as 2.0.  I know there are other issues that need addressing but this is a current issue of mine.

So I started to implement a timing mechanism. The timer starts when I song is playing and the seconds are calculated as it goes. I have not worked out the details but the idea is that a user can define a pin as well as a time and a method such as on off, etc. four example a user can say pin seven off at 0 seconds and on at 10 seconds when the song starts playing channel 7 will not come on until 10 seconds into the song.  The user would be able to define multiple channels and multiple times per channel. This would not affect the cache song, as this would be executed during playback before the signal is send to the hardware controller.  So there would be no need to re-cache if the settings are changed.  I'm initially worried about the additional code affecting the playback and I'm looking for feedback for a couple of things:

1. Should this be done pre-cache so that the values are recorded and stored in the cache file. Or would it be better to leave it the way I have it in the outline above?

I think your outline is fine --- this would be a way for people to do their own choreography and not rely on the fft based one.  Takes more time, but once you get the lightshow bug, you always want to improve your show over time!

 

2. Should this all be done in the synchronized lights file and handled before the hardware controller is called to switch a light? Or might it be better to decide the state of a channel in synchronized lights and record that in the state.conf file and let hardware controller check that each time it goes to fire a pin? That would involve a lot of reads and writes into the file, but this could serve a greater purpose in the future for checking if a pin is active or inactive during playback at a certain point in the song. Or might there be a better way to store this info instead of in the conf file. Just thinking aloud here.

Pin state can be checked directly using multiple GPIO tools - so I don't think we need to store current pin state anywhere.  I think it makes sense to me to do this in synchronized lights ... it checks first for timing definitions per channel - if found sets them according to that, and then falls back to the fft based for all other channels.

 

3. I imagine this could act as a global setting for all songs to create some effects, but I was thinking this would serve a much greater purpose as a per song config. What do you think?

per song for sure

 

4. I have a proof of concept in the works and initial testing makes me excited to have this sort of flexibility. Would this prove useful to others, and does it fit in with our goals?

Do you have a sample configuration file to illustrate more what you are thinking here?

Does it fit our goals?  One goal is for us to have fun, so I think it fits that one if you are having fun ;)

My next big project if / when I ever get the time is to re-work the core of lightshow pi (synchronized_lights.py is getting a bit unwieldy for people to continue to hack on)... moving it towards being a service that people can add plug-ins to as they see fit.  Need more time!!! ;)

 

I know there is a lot to be taken care of as far as issues etc, but this has been consuming me as of late and I can't help but get this working as I have an immediate use for it. This would provide a lot of flexibility to users who wish to get in and further customize their shows. Do you guys think this is the best method to achieve what I am describing.  A lot of thinking out loud here, just wanted to get it out of my head before forgetting it. Sorry for any typos, using dictation as I drive !

--
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/47116F6D-DB37-4FA9-94AC-4A70B3FE1911%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[chris usey]

Thanks for the reply. I haven't locked down a sample config yet, I still trying to find the easiest way to implement a config. I'll post something when I figure out a good config method !

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/CAK2Uy1qamSiA9oFeowTZOdbUH9UhaYVPq7Arf-H5Ake9Agzw2g%40mail.gmail.com.

[chris usey]

Ok so for the config this is what I have been playing with. Once a song is cached, a file_name.timings file will also be created alongside the sync and config file. If a user wants to setup special timings they need to set them in that file in the format below:

[second]

channel = mode

Consider the Example:

[1] 

1 = 1

2 = 1

3 = 1

4 = 1

5 = 0

6 = 0

7 = 0

8 = 0

[5]

1 = 0

2 = 0

3 = 0

4 = 0

[10]

1 = 1

2 = -1

3 = -1

4 = -1

5 = -1

6 = -1

7 = -1

8 = 1

at the 1 second mark channels 1-4 will be turned on and channels 5-9 will be turned off and will remain in that state until the 5 second mark is reached. At the 5 second mark all channels will be turned off and will remain off until the 10 second mark is reached, channels 5-8 were already off so it doesn’t have to be specified again at this point. At the 10 second mark channels 1 and 8 will turn on and will remain on for the rest of the song, all channels with a -1 will exit the off state and return to following the conditions set by the sync file.  I have a running version of this and it works pretty well. It will work with setting a specific brightness as well if a user has PWM working, and with a few tweaks I want to make it so that it will fade or grow brighter over a number of seconds specified ! 

If anyone is interested in testing let me know and Ill push this branch to my repo.  I have a little cleaning up to do. Looking for input about the method for declaring the timing configs.  

On Dec 9, 2015, at 12:51 PM, Todd Giles <todd....@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/CAK2Uy1qamSiA9oFeowTZOdbUH9UhaYVPq7Arf-H5Ake9Agzw2g%40mail.gmail.com.