Cat2437 wrote:

_nix wrote:

Cat2437 wrote:

I requested a new operator for “mapping” values from one range to another, and @The_Cool_Scratch_Guy (The guy that posted above me) already had this. Here's his code to add to the workarounds: (snip)

Can you link us to the post or project where @The_Cool_Scratch_Guy shared this workaround? Also, how does this look for the workaround's adapted code and text, in the guide? (snip)

https://scratch.mit.edu/discuss/post/8730447/ Here's the original post

Okay, thank you! I've added it to the guide.

Cheezzychiknzzz wrote:

After reading the table of contents, I realized that there isn't a Workaround for the sounds category blocks, which is surprising since every other category has been covered. So I figured I would give my suggestion (note, this trick has been widely known & used. However I suggested it to make the list feel more complete and for people who do not know it)

I've added the “pause sound, unpause sound” worakround too! Thank you very much!

_nix wrote:

Cheezzychiknzzz wrote:

After reading the table of contents, I realized that there isn't a Workaround for the sounds category blocks, which is surprising since every other category has been covered. So I figured I would give my suggestion (note, this trick has been widely known & used. However I suggested it to make the list feel more complete and for people who do not know it)

I've added the “pause sound, unpause sound” worakround too! Thank you very much!

You're welcome, be sure to add in more sound workarounds next time

_nix wrote:

Cheezzychiknzzz wrote:

After reading the table of contents, I realized that there isn't a Workaround for the sounds category blocks, which is surprising since every other category has been covered. So I figured I would give my suggestion (note, this trick has been widely known & used. However I suggested it to make the list feel more complete and for people who do not know it)

I've added the “pause sound, unpause sound” worakround too! Thank you very much!

my sound workaround has been sitting in the dust for almost half a year now TOT

jmdzti_0-0 wrote:

_nix wrote:

Cheezzychiknzzz wrote:

After reading the table of contents, I realized that there isn't a Workaround for the sounds category blocks, which is surprising since every other category has been covered. So I figured I would give my suggestion (note, this trick has been widely known & used. However I suggested it to make the list feel more complete and for people who do not know it)

I've added the “pause sound, unpause sound” worakround too! Thank you very much!

my sound workaround has been sitting in the dust for almost a year now TOT

Oooooo where is your suggestion? Maybe I can tell it to @_nix!

found it

jmdzti_0-0 wrote:

The_Cool_Scratch_Guy wrote:

A partial workaround for fast-forwarding sounds:

define fast-forward (time) seconds of sound
set [pitch v] effect to (500)
wait ((time)/(6)) seconds
set [pitch v] effect to (0)

It's not a perfect skip, but it goes pretty fast. It works fast enough that it can be used for cloud music syncing long as the track isn't too long.
If you don't want the high pitched sound, you could set the volume effect to -100 at the beginning then back to 0 at the end.

Better alternative (better precision)

define skip forward (n) secs
if <(n::custom)=(0)> then 
  stop [this script v]
else
  set volume to (0)%
  set [pitch v] effect to (360)
  set [audio end timestamp v] to ((days since 2000) + (((n)/(86400))/([10^ v] of ((9)/(10))::operators)))
  wait until <(days since 2000) > (audio end timestamp)>
  set volume to (100)%
end

jmdzti_0-0 wrote:

found it

jmdzti_0-0 wrote:

The_Cool_Scratch_Guy wrote:

A partial workaround for fast-forwarding sounds:

define fast-forward (time) seconds of sound
set [pitch v] effect to (500)
wait ((time)/(6)) seconds
set [pitch v] effect to (0)

It's not a perfect skip, but it goes pretty fast. It works fast enough that it can be used for cloud music syncing long as the track isn't too long.
If you don't want the high pitched sound, you could set the volume effect to -100 at the beginning then back to 0 at the end.

Better alternative (better precision)

... // snip
set [pitch v] effect to (360)
set [audio end timestamp v] to ((days since 2000) + (((n)/(86400))/([10^ v] of ((9)/(10))::operators)))
wait until <(days since 2000) > (audio end timestamp)>
... // snip

Thanks both. We totally missed this one, yeah…

Can you explain how the second workaround has better precision? I mean, there's two big differences going on here. One is using “days since 2000” instead of plain “wait…seconds”. The other is, I assume, different math. I'm going to try to express the second workaround in terms of “wait…seconds” to make the math easier to compare.

set [audio end timestamp v] to ((days since 2000) + (((n)/(86400))/([10^ v] of ((9)/(10))::operators)))
wait until <(days since 2000) > (audio end timestamp)> // =
wait (((1) / (86400)) * (((n)/(86400))/([10^ v] of (0.9)::operators))) seconds // =
wait ((((1)/(86400)) * ((n)/(86400))) * ((1)/([10^ v] of (0.9)::operators))) seconds // =
wait ((n) / (((86400) * (86400)) * ([10^ v] of (0.9) :: operators))) seconds // =
wait ((n) / (939782784)) seconds

I mean I have to be doing something wrong here.

From a “keep it simple” perspective, assuming the unit conversion is somehow getting flipped over here, 10^0.9 is approximately equal to 7.94, which is pretty close to 6. Is the intended “equal” workaround supposed to be this?

wait ((time) / (6)) seconds // time/6, less accurate
wait ((time) / ([10^ v] of (0.9) :: operators)) seconds // time/7.94, more accurate

Or is this an accidental distraction, time/6 really is accurate, and the only thing that matters is using “days since 2000” instead of “wait…seconds”?

Sorry, I'm just having trouble pulling the better-precision workaround apart, and would appreciate some guidance.

a bunch of people wrote:

I wrote:

A partial workaround for fast-forwarding sounds:

define fast-forward (time) seconds of sound
set [pitch v] effect to (500)
wait ((time)/(6)) seconds
set [pitch v] effect to (0)

~snip~

Actually it turns out this one is inaccurate (and the other one has way too much math). I did some reading on the scratch wiki a while back and had derived this:

define fast-forward (time) seconds of sound
set [pitch v] effect to [360]
set [old volume v] to (volume)
set volume to [0]
wait (((time) / (8)) - ((1) / (30))) seconds
set [pitch v] effect to [0]
set volume to (old volume)

Ok, let me explain this. First we increase the pitch to the max, which is 360. (I was convinced 500 was the max, but it seems my ears were fooling me.) Then, we turn off the volume so we don't hear anything, then we wait. (We store the volume in a variable to come back to the same volume later.) The math here first divides our time by 8. On the wiki, I found that any increase by 10 is a semitone and 120 is an octave. The latter of these is important, because an octave doubles the speed of the sound. Increasing by 3 octaves, which is our max, makes the speed 2^3, or 8, times faster. After this, we simply account for the screen refresh to maintain accuracy. 1/30 isn't exactly a screen refresh, but it's a good enough approximation.

Speaking of waits, I've been investigating the rest () beats block and think I have the answer to a perfect wait time. Workaround coming soon!

Just something I noticed, 7.94 is annoyingly close to 8. And it's not even the same number base (2^3 vs. 10^0.9)…………..

_nix wrote:

Okay, thank you! I've added it to the guide.

Can you add the extended version with more variables as well? I think it might be easier to understand for someone who hasn't heard of a scale factor before. Also I am confused why you decide to name the second variable “rounded”, as there is no rounding. Maybe “converted”, “scaled”, or “mapped” would be a better name.

_nix wrote:

idk pal i just did some testing and it turned out to work better. the code is not even mine, i found it somewhere and can’t remember the original maker now.

edit: i think i snatched it from @qucchia (?)

Is there a workaround for a block like this:

(key pressed)

Other than the very long way?

TopSecretCodes wrote:

Is there a workaround for a block like this:

(key pressed)

Other than the very long way?

What does this block do?

Cheezzychiknzzz wrote:

TopSecretCodes wrote:

Is there a workaround for a block like this:

(key pressed)

Other than the very long way?

What does this block do?

There are 2 options:
Reports the last key pressed
Reports the key is pressing

The_Cool_Scratch_Guy wrote:

Ok, let me explain this. First we increase the pitch to the max, which is 360. (I was convinced 500 was the max, but it seems my ears were fooling me.) Then, we turn off the volume so we don't hear anything, then we wait. (We store the volume in a variable to come back to the same volume later.) The math here first divides our time by 8. On the wiki, I found that any increase by 10 is a semitone and 120 is an octave. The latter of these is important, because an octave doubles the speed of the sound. Increasing by 3 octaves, which is our max, makes the speed 2^3, or 8, times faster. After this, we simply account for the screen refresh to maintain accuracy. 1/30 isn't exactly a screen refresh, but it's a good enough approximation.

thank you. makes sense! out of interest have you tried this with some simple test audio? like… a sound that has a different percussion effect 1 2 3 4, one percussion per second. 60 bpm, one sound exactly on the beat. and maybe announces the measure number or something. ^^ your theory very much adds up, not doubting it at all, just it's fun to watch things in practice

i had one thought reading your workaround. it's understandable to restore volume to the previous value because you can, but i think it may be better to just mention it as a caveat, next to code that simply “resets” it to 100%. why? because we can't restore the previous value of the pitch effect… unless someone is using a workaround for sounds analogous to the looks-category “color effect reporter” workaround. we could maybe do a “method 2” which shows how to do that. but i think restoring just the volume and not the pitch effect might surprise and confuse people… at least it surprised and startled me

The_Cool_Scratch_Guy wrote:

_nix wrote:

Okay, thank you! I've added it to the guide.

Can you add the extended version with more variables as well? I think it might be easier to understand for someone who hasn't heard of a scale factor before. Also I am confused why you decide to name the second variable “rounded”, as there is no rounding. Maybe “converted”, “scaled”, or “mapped” would be a better name.

no. sorry, the workaround text is final. (“rounded” is absolutely a typo though, thank you for catching that… just fixed) it's a specific math workaround for a fairly specific math operation. i guess we just disagree that the startrange/endrange explanation is clearer. the guide already brings attention to that in the description of the workaround: “…only the number lines can be different length…”… i feel that's sufficient and that someone working out the math for themselves will be able to figure it out, since they have been told why the math is like this / what the math needs to accomplish

jmdzti_0-0 wrote:

_nix wrote:

idk pal i just did some testing and it turned out to work better. the code is not even mine, i found it somewhere and can’t remember the original maker now.

thank you for telling what you know about the workaround you shared

_nix wrote:

jmdzti_0-0 wrote:

_nix wrote:

idk pal i just did some testing and it turned out to work better. the code is not even mine, i found it somewhere and can’t remember the original maker now.

thank you for telling what you know about the workaround you shared

is that… meant to be sarcastic?

jmdzti_0-0 wrote:

_nix wrote:

jmdzti_0-0 wrote:

_nix wrote:

idk pal i just did some testing and it turned out to work better. the code is not even mine, i found it somewhere and can’t remember the original maker now.

thank you for telling what you know about the workaround you shared

is that… meant to be sarcastic?

not really although sarcasm was an aspect of how i felt, since i was a bit irritated to have our writing cut out so unceremoniously… i did appreciate you commenting what you could and wanted to be direct about that

in your post you seemed to be acting in a disdainful way, “idk pal”, sounding like you were upset or affronted. we did assume you were knowledgeable about the workaround since you were sharing it. that was an assumption on our part, but i feel confused why the assumption upset you (or it seemed that way)

since i figured describing these feelings and trying to help you understand, would be imposing a burden you probably weren't too interested in, i just replied directly so that i was not ignoring you

for rotating around x: y:

_nix wrote:

define rotate (degrees) degrees around x: (x) y: (y)
set [direction before custom block ran v] to (direction)
get distance to x: (x) y: (y) :: custom // Check out the workaround for this!
point towards x: (x) y: (y) :: custom // Check out the workaround for this, too!
set x to ((x) + ((distance to position) * ([sin v] of (((direction) + (180)) + (degrees)))))
set x to ((x) + ((distance to position) * ([cos v] of (((direction) + (180)) + (degrees)))))
point in direction (direction before custom block ran)
turn cw (degrees) degrees // This helps the sprite look like it's following the circle.

did you mess up here? is the second set x supposed to say set y?

Another workaround for

distance to x:[] y:[]::sensing reporter

This requires a blank sprite at a location. It does work, though may be ineffective, especially to those who need a lot of these sprites. There is a solution to this however, you move the original sprite to the desired location.

(distance to [sprite v])

Dan0da0man wrote:

for rotating around x: y:

_nix wrote:

define rotate (degrees) degrees around x: (x) y: (y)
... snip :: grey
set x to ((x) + ((distance to position) * ([sin v] of (((direction) + (180)) + (degrees)))))
set x to ((x) + ((distance to position) * ([cos v] of (((direction) + (180)) + (degrees)))))

did you mess up here? is the second set x supposed to say set y?

Eep, yes! Totally an error. It's fixed now, thanks.