I enjoy making animation in scratch, and the animations usually involve syncing animations to music. now, for me, thats not all that hard, but almost every time i make animations, i'll sink the animations, and then watch it a few times, and then after a few times, it will be out of sync again! so lets say my animation happens a little to soon. so i make it happen later, and i watch it again and its perfect, but then later i watch it again, and even though I haven't changed anything since the last problem, its now to late! its as if it was good the first time and i made it out of sync, but i didnt! it may be lag, but even if thats so, how can i know which is lag and which is it ACTUALLY being off sync???? any help?
Last edited by dogbloos (2008-08-12 16:23:08)
Offline
I agree with coolstuff. Whenever I synchronize music (usually done with midi blocks) with a sprite's movements I rely heavily on frequent broadcasts. As a rule I found out one message per musical measure (about every four beats) will work fine.
With recorded music it's a bit more tricky. I have only experimented with very short recorded sounds. My guess would be that it's probably most effective to cut a recorded song up into smaller parts and synchronize these with whatever else your project is supposed to do again using broadcasts.
The effect here is that a thread in Scratch will be terminated and restarted instantly upon the event specified in its hat block. This technique therefore works best with musical rounds (where the sound in each thread is always the same but the threads are timed differently). With different parts of a song it might be useful to not only start the next part at the correct moment, but to also stop the (unfinished) previous part from being played. I can think of several methods how to do this, I'm sure the community will come up with even more...
Offline
I've noticed that doing broadcasts seems to have some inherent lag.
Example: in my shooting games I'm currently working on, I found using broadcast when hitting 'fire' saw a noticeable mis-positioning of the bullets from where I expected the start point to be. I actually got around that by capturing the start pos in global vars at the moment of firing, and then broadcasting 'fire' to the bullets, which then referred back to the global vars. (The small delay in firing wasn't really a gameplay problem, but the mis-positioning was. An acceptable trade-off)
So for syncing music etc, it might be better to avoid broadcast altogether by actually changing the value of a global variable (and detecting that change within a tight loop)
However I may be wrong on that, someone who knows how broadcast works 'behind the scenes' might be able to shed some light...?
Offline
I'm not sure if the lag results from the broadcast statement or rather from converting an outside event, such as a keystroke or a mouse click, to a broadcast message first, and setting up yet another script to react to such a "detoured" event.
I have found broadcasts to be amazingly precise and very useful for musical synchronization (With music, you immediately notice if something lags or gets out of synch). Like you, however, I have also noticed that a "when key pressed" or a "when sprite is clicked" hat occasionally lags behind the instant I actually feel like having pressed that particular key or clicked on that particular sprite myself...
Your workaround using a "tight loop" and a variable sensor also sounds like a very good idea!
Offline