PutneyCat wrote:

Great idea!

But why?

Edit: HAHAHA! I'm king of teh page! I should probably add something else…

Would these broadcasts have some symbol next to the name to discern them from normal broadcasts, or would they get their own When I receive block in sounds?

Support
İt would be great for syncronizing music with animation /game

Joyoforigami wrote:

When I make intros, I really need to know when the beats are, and I waste lots of time with lists and timers and recounts. If this was added, I could make intros a whole lot faster

So you support the suggestion?

kriblo wrote:

I suggest a new feature in the sound editor: the ability to add named markers on the timeline of audio clips. These named markers would serve as broadcast messages. When the sound is played and reaches that point, a broadcast is issued.

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.

Edit to to clarify, based on suggestions and questions below:
I suggest the new feature would use the existing broadcast system. So no new code blocks are required. When creating or editing a marker in a sound in the sound editor, a “name” is selected from a list of existing broadcast messages (or a new messages is created, just as with any broadcast handler).

Thank you @CST1229 for making a mockup (posted below). This inspired me to make my own, to illustrate and clarify my suggestion.
Mockup

I think this would be a great idea in my opinion.

Would these markers move with the sound when effects are applied to it, like faster or slower, and reverse in the sound editor or the pitch effect, or would they always stay at the same absolute time unless manually moved?

fdreerf wrote:

Would these markers move with the sound when effects are applied to it, like faster or slower, and reverse in the sound editor or the pitch effect, or would they always stay at the same absolute time unless manually moved?

This is a good question, which needs to be answered if this feature was to be implemented. As you imply, there are several ways this could be handled.

When editing sound with trigger markers, the easiest solution (in my opinion) would be to remove any markers where the timeline is affected, but warn the user and have them confirm the action.

This problem can be solved, one way or another, and I don't think this should be the focus of further discussion. Most users would likely use this feature with a music track, which would not be modified in the Scratch sound editor after being imported.

On a separate note, it should be easy to implement a solution where broadcast time of markers are adjusted based on the pitch used when the sound is played.

Joyoforigami wrote:

When I make intros, I really need to know when the beats are, and I waste lots of time with lists and timers and recounts. If this was added, I could make intros a whole lot faster

Yes! Intros are generally fast and this would be really helpful

fdreerf wrote:

Would these markers move with the sound when effects are applied to it, like faster or slower, and reverse in the sound editor or the pitch effect, or would they always stay at the same absolute time unless manually moved?

That is a good question! It will take some time to perfect the block so there is no lag

M4- wrote:

DarthVader4Life wrote:

kriblo wrote:

DarthVader4Life wrote:

papipupepappa wrote:

That would be great!

Please state why it'd be great.

One would assume for the reasons I give in my original post.

This doesn't matter. On the forums, one must add to the discussion constructively.

Kid, you sound like a disc mod, calm down, this isn't the Soviet Union lmao

But it is true! You need to be constructive in the forums.

DarthVader4Life wrote:

Would these broadcasts have some symbol next to the name to discern them from normal broadcasts, or would they get their own When I receive block in sounds?

I see no reason for them to be anything but “normal” broadcasts, and no need for a separate “When I receive…” block.

If this is to be implemented then I would really like to see it implemented as a separate block. Code should be separate from assets IMO, and there would be confusion if messages could be broadcast from either code inside the code editor or potentially from a sound visible inside the sound editor, which is an area almost completely unrelated to the code editor. A separate message system and block that only works with sounds would avoid this confusion.

kriblo wrote:

DarthVader4Life wrote:

Would these broadcasts have some symbol next to the name to discern them from normal broadcasts, or would they get their own When I receive block in sounds?

I see no reason for them to be anything but “normal” broadcasts, and no need for a separate “When I receive…” block.

I think a good reason would be the below post:

-Rex- wrote:

If this is to be implemented then I would really like to see it implemented as a separate block. Code should be separate from assets IMO, and there would be confusion if messages could be broadcast from either code inside the code editor or potentially from a sound visible inside the sound editor, which is an area almost completely unrelated to the code editor. A separate message system and block that only works with sounds would avoid this confusion.

There would be no confusion if you knew it was from a sound.

Yes, an awesome idea! It would be really useful for things like animation and MAPs. I bet Scratchers could even use it as a sort of timer in a game, where when the background music gets to a certain part the game is over or you move on to the next level or something. I'm trying to think of even more places these could be used in but I don't think there are any, so this is a tremendously amazing idea.

I hope the ST sees this!

Support,even though it's workaroundable. All you have to do is do this block

start sound [  ...v]
wait (Time until it gets to the part of the sound) secs

Although it is hard to get to the exact part and would help me with my recent animation memes

PkmnQ wrote:

kriblo wrote:

DarthVader4Life wrote:

Would these broadcasts have some symbol next to the name to discern them from normal broadcasts, or would they get their own When I receive block in sounds?

I see no reason for them to be anything but “normal” broadcasts, and no need for a separate “When I receive…” block.

I think a good reason would be the below post:

-Rex- wrote:

If this is to be implemented then I would really like to see it implemented as a separate block. Code should be separate from assets IMO, and there would be confusion if messages could be broadcast from either code inside the code editor or potentially from a sound visible inside the sound editor, which is an area almost completely unrelated to the code editor. A separate message system and block that only works with sounds would avoid this confusion.

There would be no confusion if you knew it was from a sound.

I think using the existing broadcast blocks or introducing a new “sound event handler” block is a design choice where there is no right or wrong. While I understand the logic in @-Rex-'s post, I favour using the existing broadcast system, simply because this requires no new code blocks.

kriblo wrote:

PkmnQ wrote:

kriblo wrote:

DarthVader4Life wrote:

Would these broadcasts have some symbol next to the name to discern them from normal broadcasts, or would they get their own When I receive block in sounds?

I see no reason for them to be anything but “normal” broadcasts, and no need for a separate “When I receive…” block.

I think a good reason would be the below post:

-Rex- wrote:

If this is to be implemented then I would really like to see it implemented as a separate block. Code should be separate from assets IMO, and there would be confusion if messages could be broadcast from either code inside the code editor or potentially from a sound visible inside the sound editor, which is an area almost completely unrelated to the code editor. A separate message system and block that only works with sounds would avoid this confusion.

There would be no confusion if you knew it was from a sound.

I think using the existing broadcast blocks or introducing a new “sound event handler” block is a design choice where there is no right or wrong. While I understand the logic in @-Rex-'s post, I favour using the existing broadcast system, simply because this requires no new code blocks.

Yeah, but it should still have the icon. It's the best of both worlds. No new code blocks, and no confusion.

kriblo wrote:

PkmnQ wrote:

snip

I think using the existing broadcast blocks or introducing a new “sound event handler” block is a design choice where there is no right or wrong. While I understand the logic in @-Rex-'s post, I favour using the existing broadcast system, simply because this requires no new code blocks.

We already have this as a separate block:

when backdrop switches to [ v]

Even though it is not necessary, it still exists separately from broadcasts in order to improve readability of the code. Is it really too much to ask for something like this:

when any sound reaches marker [named marker v] :: events hat

I would argue that the second one is more necessary than the first, because at least in the case of the first, a broadcast workaround would still be contained entirely within the code. Adding an extra block wouldn’t change this, but it would at least make it clear to anyone else reading your code.

-Rex- wrote:

kriblo wrote:

PkmnQ wrote:

snip

I think using the existing broadcast blocks or introducing a new “sound event handler” block is a design choice where there is no right or wrong. While I understand the logic in @-Rex-'s post, I favour using the existing broadcast system, simply because this requires no new code blocks.

We already have this as a separate block:

when backdrop switches to [ v]

Even though it is not necessary, it still exists separately from broadcasts in order to improve readability of the code. Is it really too much to ask for something like this:

when any sound reaches marker [named marker v] :: events hat

I would argue that the second one is more necessary than the first, because at least in the case of the first, a broadcast workaround would still be contained entirely within the code. Adding an extra block wouldn’t change this, but it would at least make it clear to anyone else reading your code.

I don't disagree with your arguments. I'm saying no new blocks are needed to implement my suggestion. My main reason for favouring the approach that doesn't require any new blocks is that I think this would increase the chance of it being accepted and implemented. How it is implemented, is secondary to me at this point.

kriblo wrote:

I don't disagree with your arguments. I'm saying no new blocks are needed to implement my suggestion.

Do you agree or disagree with me (i.e., big picture)? In the original post, you stated:

kriblo wrote:

I suggest the new feature would use the existing broadcast system.

You also later said that it would be more intuitive for this feature to use the existing broadcast system, whereas I argue that this is not the case because mixing code and assets without some clear differentiation is not a good idea.

I agree with the merits of this suggestion, so let’s discuss the implementation. Could you further elaborate on why you believe that adding a second message system only for sound so as to avoid confusion would be worse than using the pre-existing system, which I argue should only be limited to broadcast blocks? Sure, adding a new block isn’t strictly necessary, but neither is this suggestion. As I see it, they’re both a convenience (unless you think that having a separate block is less convenient because you want to send the same message from both broadcasts and sound markers, therefore making your code more difficult to understand). There are workarounds to this suggestion, but I think we can mostly agree that lack of necessity cannot be the only reason for rejecting a suggestion.

You might say that adding a new block wouldn’t necessarily add any value to this suggestion, but I say that having a separate block would make this feature more discoverable and widely used. There are also many beginners on this website who may find it more difficult to understand code that mixes traditional broadcasts with sound broadcasts.

Any good suggestion has a clear implementation. Eventually, someone will have to think about it if this suggestion is to be seriously considered.

We can already sync the project with sounds by measuring the timer variable, so if the project is slowing down the pattern isn't offset forever, but with your suggestion, we wouldn't have to measure how long it took to get to the part of the sound when we want the broadcast to activate, we would just choose it from the sound without much work, so that's my reason to support.