Anybody have a workaround for hashtables?
One of the first BYOB3 projects was a hash table library. But I guess it hasn't been published.
But I wouldn't call this a "workaround"--this isn't something you'd expect us to provide as primitive. It's too easy and too educational to write yourself! Just look up the algorithms. I recommend linked-list hash buckets rather than rehashing on collisions, which is easy to get wrong.
can someone make a workaround for here's the link to it
I don't understand. Are you saying that 64 bits aren't enough for you? Use the bignum library!
What you want is a simple Finite State Machine library. Read this:
That'd solve your specific problem and be useful more generally. Take your string of keystrokes as a regular expression, turn it into a finite state machine, and send the machine a message every time a character is typed.
I finished it and it works, but I only read a few sentences of the article you gave me. here it is
and here's the script
oh and I used another block in it, here's the other block script pic
Hmm, I don't know your application, so maybe that'll do, but... What if the pattern is A B C and the user presses A B A B C? Those last three letters should match, right?
And it gets worse if you allow duplicates in the pattern. If the pattern is A B A B C and the user types A B A B A B C, on the third A you can't just start over, you have to remember that all but the first two keypresses are still good.
That's why I gave you the (admittedly long) chapter on finite state machines; they take care of that sort of problem.
yeah, that's right
scratch does, I tried it just now. on the third A, scratch makes it start over right when you make a mistake.
This is a Scratch primitive? Why on earth?
Edit: Oh never mind it's because they don't have custom reporters.
you can put the join block in the when  keys pressed in order block on scratch to get your own pattern, that's how I tested it on scratch.
I don't see such a block in Scratch.
in the makey makey extension
atan2 is also supposed to correct the quadrant of the angle. -y/x becomes the same as y/-x which causes a loss in quadrant data. the main problem is because the slope created by each is different, as the first one is in quadrant
IV while the other is in quadrant
II (since they are slopes based around the origin). the most popular use case ive seen is to correctly get the yaw angle of a directional vector.
As for pitching, this is very complicated. Usually this results in trying to find a way to take the same audio data you have and instead compressing it to fit in a smaller amount of space or expanding it to fit in a larger space with the same sample rate.
Pitching without changing the duration of the audio is very very hard, because you need to figure out all the frequencies and transform them by multiplication, and then convert the frequencies back into amplitudes. Usually this does not sound very pelasing though as there are a lot of methods for doing this and most sound scratchy or odd like in Audacity.
It's needed to implement turtle graphics! Specifically, POINT TOWARD.
that block is now in snap 6.0.
Well,an error is better than an alert.