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.

[NicolasVargas11235]

@oliverdunk and @d-albrecht thank you both for the info! In the end, I am not overly concerned about the frame rate, since I deliberately built animations that don't strongly depend on a certain fps. I did give myself the challenge of producing the animations with proper geometry calculations though, so that's what's been occuping my brain for a while. There was definitely some everyday uses of the Pythagoras in there haha. They were quite a good brain workout but I hope everyone likes them. I will have those submitted soon, like I mentioned before.

[thatmattparker]

Yes, I'm going to try and show every animation people send in.

Regarding frame rate: last time it went at the maximum speed the raspberrypi could handle. But it was doing a bunch of calculations for each 'frame' so that probably slowed it down. As soon as I have the tree set-up to display the csv files I'll run a test and see what fps it actually displays.

Do people have opinions on if i should make sure it runs at a set rate? I could force it to go 30fps or something like that which is below it's maximum possible. Or we could let people specify their ideal frame rate in the header row of the csv? (But I'm tempted to not start messing with the csv format before we've even started using it!)

[NicolasVargas11235]

@thatmattparker from what I have heard (and for me as well), most people have assumed a frame rate of around 60 fps for their animations. I would agree that locking the fps to a certain value/threshold would probably be less intrusive.

On another note, I will be submitting a PR shortly to submit my files. For the time being, I have tried to keep each LED at a max colour value of 100. I am hesitant to increase it any further, and I figured it would still be bright enough to be seen. I hope they files they are well received.

[gentlegiantJGC]

Currently my pull request (which greatly improves the CSV parsing logic and execution) by default runs the animation as quickly as the hardware can run to keep backwards compatibility with the old Harvard code but that can be changed easily.

I think it would be best if you set a reasonable frame rate that the hardware can handle and default to that.

My pull request also adds an optional column to the CSV format that allows creators to specify the amount of time in milliseconds that that frame should be displayed for. If that column is omitted it will use the default value (currently 0ms but like I said that can be changed)

Code can be found in #30

[leukipp]

Do people have opinions on if i should make sure it runs at a set rate? I could force it to go 30fps or something like that which is below it's maximum possible. Or we could let people specify their ideal frame rate in the header row of the csv? (But I'm tempted to not start messing with the csv format before we've even started using it!)

Someone pointed out here #40 that the maximum possible frame rate on a Raspberry Pi 4B is ~35fps.
So if the hardware that it ends up running on is similar, it wouldn't make sense to go beyond that.

@thatmattparker from what I have heard (and for me as well), most people have assumed a frame rate of around 60 fps for their animations. I would agree that locking the fps to a certain value/threshold would probably be less intrusive.

If the frame rate gets fixed (say, to 30fps) and most animations are designed for 60fps, the final video would be twice as long. The maximum file size for a YouTube video is 256 GB or 12 hours, just as a side note.... ;)

[aapo-kossi]

Putting my opinion out here as this issue affects my animation, I would love the frame rate to be set to some constant as my sequence is intended to be played alongside sound (freely playable online and won't get claimed) and I need to know the frame rate before sending my sequence for it to play synchronized. As some others' assumptions, mine was originally 60 fps but if the hardware cannot run that fast I can make do with lower as well.

[d-albrecht]

I get why some simulators default to 60fps (that was for a long time the default monitor frequency after all) but - and Matt may prove me wrong on this - I highly doubt that this is within reach for the RPi to achieve. I'm not 100% familiar with the naming scheme of the RPi versions, but isn't the Harvard tree a more powerful version? And they hardly even did 30fps (confirmed max in one instance was around 35fps, iIrc). I don't own a single RPi myself so take this with a grain of salt, but I'd say 30fps is about the best fixed frame-rate we will be able to do.

[jtbowden]

@thatmattparker I had previously assumed 60fps, but if that is not achievable, I'd rather stick to 30fps and know that the FPS will be what I expect. Also, all of my data so far is at 60fps, so going to 30fps is as simple as dropping half of the data before I send it (in the cases where I care about speed), so just let us know.