captbaritone
commented
9 years ago Woah! A ton of great stuff here, thanks for all your research. Looks like we have our work cut out for us!
I'll try to address these things in order:
- While I'm a perfectionist, for things like scaling (2x mode), I'm more concerned with what their intention was. If the approach they took caused certain artifacts as a side affect, I'm not too worried about implementing them. However, if they went out of their way to "fix" something in 2x mode, I'm willing to see if we can support it as well. Unfortunately, I'm also a perfectionist about code, and I'm not interested in copying subtle display artifacts if they drastically complicate our code base. :)
- I think my first priority is the pixel mode oscilloscope. Would it be possible to get a pull request branched off of the current master that contains just that code? You have so many changes in that branch (refactor, amplification, scale, pixel mode), it's hard for me to tell what is connected to what. If we could break it into smaller pieces and do lots and lots of small pull requests, I would be much happier. That also allows me to continue working aggressively on the existing code without worrying about creating merge conflicts.
- Having the canvas at 2x also seems to help on my retina display, where I think my OS is doing pixel doubling on everything else.
- There is no specific reason I picked 2048, I just copied the example I was using as a guide. I suppose we should really decide for ourselves how much precision we need. Between this and scaling the spectrogram view, I think I will need to try my best to read up on fast fourier transforms. My brother is a math professor and will be in town for the holidays, so I'm going to see if he can help me understand.
In closing, these are all great things for us to consider, and I'm grateful to have them written down. To get them fixed though, let's do several small pull requests that bite off one little piece at a time. Otherwise, I fear the bite will be so big we'll never get it down, or we'll choke in the process.
...I think I took that metaphor a bit too far, but you get the idea :)
PAEz
So your a perfectionist aye?....well good luck with the osciloper then. ;)
In 1x (not pressing D) mode the osciloper is only 14px high. In 2x its 32px. In 1x mode all values below 71 dont get drawn, I didnt check them all, but alot of them. Try playing a full amped wav of a low tone and youll notice that top gets flattened (prolly longer than it should, prolly being amplified) and the bottom drops of the bottom (isnt drawn at all). So my guess is that its actually meant to be 16 pixels but for some reason its drawn two down and the last two get cut off. In 2x mode it will go all the way down to 0 but the lower values get dithered alot more than the top values do. Try using that wav generator I made and try 71 for instance, that shows it well. Matching the dithering if thats what it is will be dam hard, dont think I could do it. Ive done dithering before, but its not always done the same. When I did the dithering for doing gif's in JS there actually a quite a few algorithms you could use and this is a different kettle of fish.
In my fork I just did a simple pixel mode if you want to check it out... https://github.com/PAEz/winamp2-js/blob/RefactorVisualizer/visualizer.js The scale stuff is coz I wanted to see the difference between having the canvas as 75x16 and 150x32. One thing that showed me is that your prolly better off having the canvas as 2x especially now you got the D working (well done on that...I learnt something new, zoom). My amplify is NOT like winamps, but I like it. ;) Also, was there a specific reason you set the buffer to 2048?..I keep getting different answers when I look on the web, even MDN's page contradicts itself in its examples... https://developer.mozilla.org/en-US/docs/Web/API/AnalyserNode.getByteTimeDomainData ...the example and the example for the syntax are different.