Any information on the animation speed?

[d-albrecht]

Hey guys,

I checked the video and all the linked resources but I can't find any information on the animation speed or frames per second. The only hint is one of the Harvard-scripts that mentions 60fps and 30fps in a comment next to one variable that is never used, Can you make any statements about the (average) speed to load all the 1500 color values onto the tree? As in this year all animations are pre-rendered, I guess the animation speed should be pretty much some constant no matter the actual animation. And if I want to have some effect have specific timings I need this information.

Thanks in advance

[gentlegiantJGC]

Currently the running code runs it as quickly as the tree is able to run it because there is a significant delay when calling the show method to push changes to the tree. This means that the frame rate will vary based on the hardware.

I am currently working on a pull request for the running code to make the frame time configurable within the CSV animation file.
More info here
GSD6338/XmasTree#2

[d-albrecht]

@thatmattparker to draw a bit more attention to this issue: Were you able to run a (random) animation and estimate the time/frame value for your setup?

[gentlegiantJGC]

@oliverdunk I have written an improved runner with a large number of fixes and with support for custom frame times. I opened a pull request on the harvard repository but they are not maintaining the repository so won't be accepting the pull request.

I am going to open a pull request with the same code here in the hopes that you will accept it so that Matt can use it.

[d-albrecht]

That's awesome, but doesn't exactly solve the problem that we still don't know what the hardware is capable of. I can't really use frame times because (a) for my animation one frame should always be the same time interval (so I don't need this feature to reduce otherwise duplicate frames) and (b) annotating my animation with some frame times that the hardware isn't capable of would still not produce the outcome I want to have. If we had an estimate on the hardware's capability, the frame times would be a handy tool (even if for my animation, all frame times would just be the same number over and over)

[gentlegiantJGC]

In the bug report linked above one user worked out that Matt's tree was able to render at a little over 30fps

[d-albrecht]

If you refer to this comment then (a) this is the Harvard tree with - if I got this right - a different RPi version driving it and (b) an animation that wastes quite a few program cycles with printouts; while debugging outputs are great, in production code you should limit the console output because this can actually hurt your performance significantly (in extreme cases).

[gentlegiantJGC]

Yeh that is the one. It shows that the hardware can run at least that. I have submitted some improved code that allows customising frame time for each frame and disabled the printing each frame. Obviously if you put a value less than the hardware limited frame time it won't go quicker than that.

[d-albrecht]

Obviously if you put a value less than the hardware limited frame time it won't go quicker than that.

Not?? How comes?? </irony>

[oliverdunk]

Hey @gentlegiantJGC! Just noting that I've seen this one, I'm going to try and take a closer look in the morning.

[gentlegiantJGC]

Thanks

[NicolasVargas11235]

Hello everyone! I see that many people have had concerns about the ambiguity of the framerate. I have tried to contact @thatmattparker through email with this same question, but I have yet to hear back from him. I see that many people have been working on this, and I am unclear on where we stand for the format of the CSV files. Currently, I have a column for the Frame_ID, but I have also read that @gentlegiantJGC was looking to add a time frame column?

If someone can let me know what the proper, current format for the rows and columns are, that would be greatly appreciated. Also, to submit our files, are we to simply upload them to the examples folder? Thanks you.

[oliverdunk]

Hey @NicolasVargas11235 👋 I'm helping Matt with his GitHub and can try to answer your questions.

I am unclear on where we stand for the format of the CSV files. Currently, I have a column for the Frame_ID, but I have also read that @gentlegiantJGC was looking to add a time frame column?

The official format is described in the video description as follows: "each line of the CSV starts with a frame number and then R, G, B values (one 'column' each) for all of the LEDs in sequence." You can test your CSV using one of the simulators in the README of this repository. That's the format Matt will use regardless of any alternative formats that come up.

Also, to submit our files, are we to simply upload them to the examples folder?

You can submit a PR here, adding to the examples folder, or email matt+LEDs@standupmaths.com. Both me and Matt see those and will make sure they're considered.

Last but not least, on the framerate - my understanding based on people who have looked over the runner code is that there isn't a set framerate, and he just runs through the spreadsheet as fast as his hardware can. I haven't confirmed this with him though so I will try do to that shortly.

[NicolasVargas11235]

@oliverdunk thank you for the clarifications! I have made use of the simulators you mentioned while building my CSV files and have worked in a 60 fps range for the animations. We'll see how it goes haha.

When you say the CSV files will be considered, I assume you mean they will be checked to see if they are appropriate and functioning correctly? I dont exactly know how many files have/will be submitted, but if they are checked before Matt's event, feel free to let me know if there are any issues with my files and I will be happy to adjust them accordingly. I should be submitting my CSV files in the next few days.

[oliverdunk]

When you say the CSV files will be considered, I assume you mean they will be checked to see if they are appropriate and functioning correctly?

I just didn't want to promise Matt would get through all of them in his video. I'm pretty sure he did last year, but no promises in case there are too many :)

As far as PRs - if something works in the simulator I'll merge it.

[d-albrecht]

@NicolasVargas11235 no-one knows for sure so far (we're still waiting for factual confirmation on Matt's specific tree), but all so far seems to confirm the theory that the tree will be capable of about 30 fps (give or take). The pull request from @gentlegiantJGC would enable us/you to configure any lower frame rates (so, for example leaving one frame visible for a whole second or so), but no code will likely be able to achieve much more than 30 fps.

Regardless of the exact frame rate, the new way that the animations are executed on the tree should at least guarantee an almost perfectly constant frame rate overall as each frame involves exactly the same sequence of lines of code being processed (you can't (un-)intentionally stall the CPU between frames as all computation has to be done before the animation is submitted, aka they are pre-rendered).

To be completely compatible with either version of the python code, you should have one column for whatever and then the 1500 columns for the color channels. The first column is either ignored completely (you could even use it to leave any Easter eggs if you like), or - given the PR gets accepted - can be used for frame times. But for now, we don't know for sure if the frame timing python code will be production-ready (as in tested and confirmed working) by the time the video gets shot.