I suggest a new hat-block:

when sound [Great Song v] reaches (1.02) :: sound :: hat

Along with this new hat-block, I suggest a new popup dialog showing the timeline of the selected sound, allowing the user to visually pick when the hat-block should trigger an event.

Mockup of the “timecode”-picking dialog:


Additionally, there could be an option to play the sound in the popup dialog (not shown in mockup), to make it even easier for the user to identify the time they want the hat-block to be triggered.

This feature would make it a lot easier for everyone to create animations which need to synchronize with sound. I believe this feature would particularly help inexperienced Scratchers.

I recently suggested broadcast messages could be added to sounds in the sound editor, here. But, after input from @Nishpish, @-Rex-, @the2000, @Scratch-Minion and others, I believe the current suggestion is a better approach. Although these suggestions achieve much the same thing, I post this as a separate suggestion due to the vast difference in approach.

Edit: I changed the title of the post from using “seconds” to using “time code”. For this hat-block to be an improvement over using wait-blocks, the “seconds” parameter should rather be defined as “time code”. An event should be triggered when the identified part of the sound is played. This should be the case regardless of lag or if the pitch effect is used.

I think it's a good idea

Support. This would make it alot easier to make stuff like Friday Night Funkin' projects, or rhythm games in general! Instead of super long complicated charts and stuff, it would be easier to make notes appear at specific points!

I think it's an amazing idea!
It would help a lot when I'm making AMVs.

Full support! It would definitely make it easier for people to make AMVs and such.

For those who didn't see the initial forum(it will help to understand a lot of potential uses of it)
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/523453/

Oh great! This is easier to understand than the last concept and completely fits in scratch.
SUPPORT!

Unfortunately, you've added seconds as the input which destroys some of the main purposes this had(according to me) like.. if it lagged then the seconds block would also lag and results are not as accurate as the broadcast approach. That would be like using a wait block(with the time execution of previous script) and then doing the script than using broadcast instead.

I support the general idea of adding some kind of marker to sound files, which can be used to trigger events.

But I think that we will need to be very clear in defining what “reaching 10 seconds” means, to avoid confusion.

What it should mean in order to be useful, is a certain point in the sound file, which is supposed to me reached after 10 seconds, but might be reached sooner of later.

It should not mean 10 seconds (according to the project timer) after the sound has started playing - in other words the same thing as these blocks:

play sound [Great Song v]
wait (10) secs

I totally agree with this suggestion as it would help scratchers in many projects(like AMV etc.). SUPPORT.

I prefer the broadcast suggestion, because I think it's easier to understand.

QuantumCodes wrote:

Unfortunately, you've added seconds as the input which destroys some of the main purposes this had(according to me) like.. if it lagged then the seconds block would also lag and results are not as accurate as the broadcast approach. That would be like using a wait block(with the time execution of previous script) and then doing the script than using broadcast instead.

Maybe if it supported decimals for seconds, half a second would be 0.5 and so on … but I doubt it'll be 100% accurate.

papipupepappa wrote:

…I think that we will need to be very clear in defining what “reaching 10 seconds” means, to avoid confusion.

What it should mean in order to be useful, is a certain point in the sound file, which is supposed to me reached after 10 seconds, but might be reached sooner of later.

QuantumCodes wrote:

Unfortunately, you've added seconds as the input which destroys some of the main purposes this had(according to me) like.. if it lagged then the seconds block would also lag and results are not as accurate as the broadcast approach. That would be like using a wait block(with the time execution of previous script) and then doing the script than using broadcast instead.

I agree. For this hat-block to be an improvement over using wait-blocks, the “seconds” parameter should rather be defined as “time code”. An event should be triggered when the identified part of the sound is played. This should be the case regardless of lag or if the pitch effect is used.

Edit: To highlight the above in the suggestion, I have edited the original post.

kriblo wrote:

Edit: To highlight the above in the suggestion, I have edited the original post.

Awesome! It is very clear now, and I support it fully!

Support, for reasons I mentioned on the other topic.

Full Mega Support! This will be very useful, and it will be the only sound hat block.
And this will be possible:

when gf clicked
start sound (Chill v)::sound
when (Chill v) reaches (0.1)::sound hat // Another workaround for forever loop
. . .
start sound (Chill v)::sound

Add this plz.

Yes!

Support. I've always wished there to be some way to use data from the “Sounds” section.
Also, a "time reached in “ reporter &&/|| ”pause/play“ and ”start sound from (timecode)" blocks wouldn't be bad.

Support

woah that's a nice mockup

Almost full support.

Uses
This can be used in a lot of ways (like maybe used in projects that are based around music). There isn't really seen any when blocks that are related to sound (except loudness) so I think this would be a nice addition. But because this is a when block I feel like this should be events though because it's a hat block. A sound hat block doesn't really make much sense because the sound category isn't supposed to control when something happens.

Workarounds
The workaround for this is kind of simple but the fact that you can select where you want it to start on a pop up makes it a lot more user friendly. Very appealing if you ask me. I have a feeling it might be a bit hard to select when to start if the song is long (~60 seconds) but that can be solved by manually changing the number which is already an option.
Workaround:

play sound [... v]
broadcast [... played v]
when I receive [... played v]
wait (...) secs
...

Oh my god this is great!! It could be used for music animations, something being synchronized with a sound, and more! Using the “Wait seconds” block is often unreliable, but this would have a lot more reliability!

FULL SUPPORT!

EDIT: I remember being the second post on the page. Which post was deleted?