25% and 75% would sound identical alone, but in a mix there often are interplays where it can create a difference. An easy way to hear it is to run two synced oscillators, say a square and a saw, with sharp attack. The resulting sound should be sufficiently different, one side would dampen the attack compared to the other. Furthermore, I think in hardware synths and those that emulate them changing pulse width can cause the module to implicitly shift the signal up or down to ensure consistent average voltage, further complicating things. I am curious what you mean by compression.
Good point. If I have 2 oscillators, and no control over their phase as they mix, then an option to choose 25% vs 75% for one of them would at least offer some variation instead of none.
As for compression, this [0] is a good intro. Most commonly it is applied to a signal deliberately to achieve a desired outcome, but I'm referring to a (generally) undesired speaker nonlinearity [1] near its maximum power handling capacity.
Web Audio is awesome and IMHO people who got the spec out and pushed for implementation deserve lots of respect. You want to make a tracker that runs in your browser and you have all the primitives at your disposal to make it work? A few years ago I wouldn’t imagine it can be possible.
I have a hotter take, that the spec and implementations were rushed and it makes it hard to push past "toy" quality for web apps. I have seen people struggle and wind up moving mountains to get what is basic functionality and performance in native audio apps.
The other thing is that they have made cardinal sins like relying on direct form biquads for basic filters and using an array for parameters. It's good enough to make a demo but falls apart in the situations that you actually care about, and these are things that the pro audio industry (or similar, like gaming) have had solved for a very long time (*)
* pro audio software is a disaster, but for other reasons
It's super cool! Just from short time that I've been playing around with it, it looks like you can push it pretty far. Before too long I hope to have a Show HN post with a link to the tracker out live in production
I agree. There’s a bit of mental overhead related to working with audio worklets (you have to load them from an URL or a blob URL, etc.) but for square waves in particular the logic should be fairly straighforward, the process function just needs to output 1 or -1 for any given sample.
It needs to do a lot more than that if you want to have something that doesn't alias like crazy. And significantly more if you want it to sound like a game boy.
Well, the output of the wave shaper approach in the article is exactly the same sharp digital square wave that you'd get from a trivial square wave generator.
But I overlooked the point that the GP mentions that the processor source code must be loaded from a separate JS file. That's some quite annoying overhead.
What I was trying to imply was that it's not enough to build a square wave generator to sound like a game boy. Even if that generator in the game boy was a perfect square wave generator, which I'm not sure it is.
The sound created by that generator passes through a fairly complicated filter known as The game boy's speaker. To properly create a game boy sound, you need to find or take an impulse response of that speaker and convolve it with the output of your oscillator.
Well, and a single recorded impulse response is probably not enough, either, if you want to be super accurate. The directivity pattern is probably awful and shaping the sound as well.
I know all of that. But I just didn't want to get into these details in this thread.
