# I found out that the "frequency" block stops working after you do this

There is a bug where running this code below prevents the "play frequency" block from working:

Attempting to run the "play frequency" does nothing. And when you try to run the "stop frequency" block, I get an error:

What's happening and can you fix this?

What do you expect to happen when you ask to play a note at frequency = ∞ ?

I expect it does nothing and it'll continue to work.

Why on earth would someone do that anyways?
I've noticed that you keep reporting bugs that no one would encounter during regular use. Maybe report bugs that the average user might encounter?

the issue is that when you play a frequency of infinity, it breaks the play frequency block. You can no longer play frequencies, and you can't stop frequencies. This only breaks if no other frequency is playing.

Yeah, fine, it's a bug, at very low priority. That was joecooldoo's point; we have plenty of things to work on without the ones that are problematic only after the user has done something silly.

It seems to happen with any string too, so that may be a problem

But the slot is a number slot; you can't bug it out without deliberately inserting a block that reports text.

yes, but if you stick a string in a number input, it's usually used as 0. It should be the same for the frequency block.

Yeah, fine, but it's hard to come across just by using Snap! normally.

not really, since this can be pretty easy to come across, since it's basic math to produce infinity.

Hmm, I guess that's true... @bh?

Well, it obviously won't come up in any sensible music program, because a frequency of 0 (a constant output level) is inaudible, and an infinite frequency is unachievable. So I'm not worried. Maybe Jens will feel differently.

when making a project, not every step of the way is a working project, or one that handles whatever a user might do. it doesn't give a good impression to drag around some math and suddenly blocks stop working.

when trying to make projects i run into all sorts of "low priority" bugs where the issue can be fixed by me not doing a thing, but it takes me hours to find out what the thing was.
imagine how long it would actually take someone to figure out why simple blocks stopped working in a complex program.

why does priority even apply to this? it's a 3 line fix. most of the time it would take to fix it is just finding where the frequency block is in the code and testing to see if it works.

If we check for errors in every possible situation, Snap! will get slow. Jens grumbles about error checks even in higher priority cases (things that users do a lot). Priority is an issue because there are bazillions of possible user errors that we don't catch, and this one is pretty obscure.

But I agree that if the error actually breaks Snap!, as opposed to just giving an unhelpful Javascript error message, that's worth paying attention to. So, maybe I'm wrong about its priority. Jens is the decider; when he's back from vacation and caught up on email and stuff, maybe he'll fix it.

have error checks ever been slow before in testing? i don't see how they would be slow, and from my experience snap is always slow because of specific blocks like stamp or play sound (play sound when the project first loads can take a significant amount of time on the one block)

are any of the error checks remembered for being slow very complicated? what i'm talking about here is just some if statement to check if a number is in some range, it's an extremely basic operation and the browser jit compiler would almost definitely optimize it as much as possible

No, it's not a question of complicated tests. Those two lines of JS code take a lot of time if they happen to be in a loop that loops thousands of times. That's what Jens tells me.

there's no reason to use the frequency block more than once in a frame, and a frame is 16ms
these kinds of optimizations would make sense for things like move and stamp blocks, where they actually get used like this (i could really use faster stamp/cut/paste)

but let's optimize anyways!
here's a flame graph recorded after putting a few blocks in a loop:

filter should not be taking that long

if (!this.freqPlayer) {
this.freqPlayer = new Note();
}
note = this.freqPlayer;
...
if (stage) {
stage.activeSounds.push(note);
stage.activeSounds = stage.activeSounds.filter(snd =>
!snd.ended && !snd.terminated
);
}


every item in stage.activeSounds is a reference to the SAME freqPlayer object, so even though a sound ends, it gets reused, put in the list again, and the filter doesn't remove anything, just scan the increasingly large list.
it also doesn't make sense to push a note that has just started right before filtering it, it should be after.
zooming in on that flamegraph:

BaseAudioContext.resume is called 3 times because all of these functions do it. i can't figure out any reason why the audiocontext would ever need to be resumed in the first place, but if it does, then move the resume out of that function and to where it actually needs to be.

these optimizations should more than make up for comparing a number.

PLEASE use benchmarks, not rumors and guesses.

Okay, then you have to wait for Jens's official word on this. All I know is what he says when he yells at me. :~)

Sigh. I get it, y'all know "if". Bravo!

You keep using the word "frame" as if it meant what you think it does. But your imagination doesn't even begin to envision the kind of awesome legitimate time-critical uses people have for the frequency block (e.g.: encoding photographs inside a frequency spectrum of hundreds of scan-lines made simultaneously using hundreds of clones is just one exercise we're actually doing with kids in school, hundreds of threads = hundreds of "frames"). Just because some forum folks can cause a tiny hiccup by entering a nonsensical value doesn't mean I'm changing a primitive. Come on, y'all are using "real" programming languages that can be crashed and completely broken by much lesser lapses all the time.