And, so, I have decided to try learning again from scratch but, this time, I am not making any progress toward recreating my prior accomplishment. However, I have made a few discoveries that have gotten me close.
- Of course, first and foremost, I watched THIS VIDEO to get me started in the right direction. I remember watching this video before and using that knowledge to create the video last time, but I must be forgetting some crucial step this time because nothing I do is working.
- I believe last time, I dragged the GIF file into Photoshop because I previously learned that doing that breaks up a GIF file into individual layers per frame making it easy to count how many total frames are within the loop. Since then, I have discovered this website,
that not only displays the total frames but also provides other useful information for the gif, such as the GIF length (in seconds), delay (in milliseconds, which I'm sure is what's messing me up but I don't know what to do with that information yet), and just other general information.
- Just recently, I discovered the likes of
which, on paper, should have solved the issue then and there. GifSync boasts the ability for users, namely streamers, to load GIF files into their app, type in the GIF's "Beats Per Loop"* (*more on that later), then after signing in with Spotify, it reads your Spotify Now Playing data to synchronize the GIF to that song's BPM. Simple enough. The resulting synchronized GIF updates live (with a slight delay) per song, and, I suppose it's meant to be used with OBS's URL stream ability to have the GIF of a character dancing to the song that a streamer is playing on Spotify in their stream. But, since that isn't what I was looking for specifically, I realized that I can now save this tempo-synced version of the GIF and it is now... well, saved as a new GIF file synced to whatever BPM it was when I saved it. Pretty useful, and I expressly wanted to share that here in the event anyone doesn't know about it and it might help someone somewhere someday. Unfortunately, it did not help me, and here is why I think not.
- The last bit of information I learned recently came thanks to the Microsoft Bing AI chatbot thing (mainly for reading the forum post for me that I actually happened upon prior to asking it when doing my own Google search but the result was talking about Python code and I didn't really want to read that). Simply, I asked it the AI if there was a way to alter a GIF's speed using Slicex or something (in relation to the aforementioned video chopping video, which it was unaware of at the time), and it responded that I cannot use Slicex for video manipulation, but told me how to convert a GIF's speed outside of FL Studio. In short, it told me to...
- Take the BPM and find the BPS (Beats Per Second) by doing BPM / 60 = BPS.
- Find the SPB (Seconds Per Beat) from the BPS by simply... 1 / BPS = SPB. Right, simple math.
- Find the SPL (Seconds Per Loop) by multiplying the number of BPL (Beats Per Loop) of the GIF. That formula is SPB * BPL = SPL, however, it did not explain how to find the BPL of a GIF (because I don't know about you, but I don't think GIFs inherently come with BPL metadata... unless I'm missing crucial information. No matter! I actually enjoy math and I figured, after doing the math up until this point, my project's BPM is 100. So BPS = 1.67 = (100/60). Finding the SPB is a simple inversion equation, so I converted that decimal into a fraction, roughly being 5/3, and then inverted that to 3/5. So the SPB = 3/5. With that out of the way, I still had to find the Beats Per Loop (BPL). Well, I don't know how to do that. That gif analysis website did tell me how many seconds long the gif was, though. So, if my BPS is 1.67 per second, then how many BPS is the GIF per 1.2 seconds (the length told to me by the website)? Well, that sounded, to me, like a simple cross-multiplication problem. So, I set that up on paper and the result was already concerning. If the GIF is 1.2 seconds long, then that means each loop is 2.004 BPS, meaning the BPL is 2.004... strange number.
Okay, so, I put this number into the GifSync website and it also doesn't work. As it turns out, the GifSync website only accepts whole numbers. Huh. Well, that's fine, I guess, maybe. 30.06 is close enough to 30 that I will just round down. The GIF was set up and I wanted to do some preliminary tests. I Google searched songs in the tempo that I needed, 100 BPM, and played some in Spotify, found one that the app registered as being 100 BPM, and I took that GIF into FL Studio and ZGameEditor Visualizer, and, wouldn't you know it, the GIF is perfect for the first 5 seconds or so. Then it desyncs again. At this point, I'm starting to think that "30ms" delay that the analysis told me about might be coming into play. And I'm already lost and confused about how I was at all possible to accomplish it last time using NONE of this recently acquired information. I just did it.- Using the SPB and BPL, I had to find the SPL (Seconds Per Loop). Alright, well, I know the seconds per loop, it was 1.2. But using the math that I did, the BPL was 2.004 and the SPB was 3/5, so I multiplied the SPB and BPL that I found and got 1.2024.
- I found the MSPL (Milliseconds Per Loop) by multiplying the SPL by 1000, getting 1,202.4.
- Then, I remember that this is a post about Python scripting. The last step I could do was find the "frame_time" my dividing the MSPL by the number of frames in the GIF, which, again, the GIF analysis website told me is 40 frames. So, 1202.4/40 is 30.06.
Can anyone help me figure out how to make a GIF image synchronize to a project's BPM using ZGEVis and, I guess Slicex or something else maybe? Also, I'm wording it like that because in my video I shared earlier where I was actually able to do this, there's a tempo change. From 100 BPM to 150 BPM. When I set up the GIF, I remember spending most of the time syncing it to the 100 BPM and once that was done, it was done. I later realized when I started working on the 150 BPM part of the song in the video that the GIF was already going at the tempo by itself. Whatever I did worked, even through tempo changes.