Plink-plonk.js – hear webpages render with DOM observer and audio API
gist.github.comI once did something similar. There is this strace-like program for Windows that captures things like memory allocations or mouse movement as part of the Win32 API. I modified the source so it emitted an OSC message on every trace and sent it to PureData which would output MIDI. The result was, well, pure cacophony. But it was amusing to, for example, belt out a dissonant piano piece by typing in VIM or use calc.exe as a (really shitty) drumpad.
Granular synthesis is great for this kind of stuff. Max/MSP, PD, and CSound have support for that.
https://en.wikipedia.org/wiki/Granular_synthesis
http://www.csounds.com/manual/html/SiggenGranular.html
I made a "musical gas" cellular automata the worked that way, which could have LOTS of audio events happening each frame. Kind of like aerosol MIDI.
It was based on a "Billiard Ball Automata" random brownian motion gas simulation, using the Margolus neighborhood.
https://en.wikipedia.org/wiki/Billiard-ball_computer
https://en.wikipedia.org/wiki/Block_cellular_automaton#Neigh...
It had stationary "microphone" particles whose x-position controlled the left/right stereo pan of the sound, and whose y-position controlled the speed (pitch) of the sound, and you could draw "bumpers" or "barriers" out of microphones to deflect and bottle up the gas particles in high or low pressure chambers.
Both the microphones and gas particles had 4 bits of "payload" that would combine to select one of 16 voices (particle payload) and one of 16 samples of that voice (microphone payload). By the pitch and stereo pan, you could tell where the particles were hitting the microphones, and by the voice and sample, you could tell the value of the microphone and gas particle payloads.
So of course I made "laughing gas" with a set of laugh samples, a "stinky gas" with a set of fart samples (to give the laughing gas something to laugh at), and a "scatting gas" (with samples like Cab Calloway singing), plus several other voices too (like Yes and No gasses for representing boolean values), so you could release just a few or any number or ratio of laughing/farting/scatting gas particles (finely tuning the fart:laugh:scat ratios to your mood). Just a few particles, and you'd only hear the occasional sound, but you could spray in a whole lot of any kind of particle to make a high pressure gas that sounded like a huge crowd of people laughing, farting, or scatting at once.
https://www.youtube.com/watch?v=6ZTuYLj5dbk
Another thing that would work well with musical gas is diffusion limited aggregation, where instead of gas particle making a sound and bouncing when they hit a microphone, they make a sound and freeze into "ice" (another microphone). That way you have to keep adding more gas and growing the crystal bigger to make more sound (but you can use an "ice eraser" (hair dryer) drawing tool to melt frozen crystal back into sublimated gas.
Modular synths like Max and Reaktor are great. You can open up the source of random components and combine them in weird ways to make new instruments. I do wish PD was more useable like Reaktor is. NI had a massive assortment of user-created instruments dating back to 2001 to spend hours poring through.
I cannot help but refer to this old, old joke: https://en.wikipedia.org/wiki/Blinkenlights#Etymology
(I used to discern between program stages on 286/386 because sound of power supply was different for different loops)
Well it's true today as well. I know immediately that something's gone wrong if I'm training an ML model and the GPU fan spools down.
Just as electric vehicles can have skeuomorphic “engine” sounds for safety [1] or aesthetics [2], I’d love to see a service that emits “fan” noise to track CPU usage.
[1]: https://en.wikipedia.org/wiki/Electric_vehicle_warning_sound...
[2]: https://electrek.co/2018/03/07/jaguar-i-pace-artificial-moto...
I have my motherboard set to run the CPU radiator fans a low-moderate speed at ~50 degrees C and below, but ramp up rapidly approaching 55+, with no hysteresis or gradual ease-in. I can absolutely gauge CPU usage on a second-by-second basis by fan noise. Any transient spikes cause an easily perceptible (but not overwhelming) wooshing.
I used to have something like that with an old machine with poor, spluttering cooling. You could really tell every time something processor intensive was running.
It was actually quite useful at times. For example, if some webpage was constantly running some heavy javascript, the fans would soon alert me that something was up.
Funny, I once realized my computer was infected with a virus because of the change in sound the HDD would make when launching Windows Commander.
I had AV software running but the virus was new and undetected.
Would love to see a sonic comparison between Todo list apps on the variety of front end frameworks like React, Vue and Svelte.
This appears quite useful for debugging renders in web apps, and also just sounds quite cool.
Little known Xcode feature- you can set breakpoints that, instead of breaking, play any sound!
Supposedly Alan Turing used a tool like this for debugging his programs.
Do you have a link to a source? Sounds interesting
There are these type of posts on HN that I prefer to tag #HNGold.
I love this, wow. It's a great idea and I'm sure you could use it as a fun debugging idea for plenty of things.
A blind programmer named Karl Dahlke does something similar: he pipes linux console output directly to a speaker to get a quick overview. (then he uses text-to-speech to delve into the details.) I think this hack is less discordant than Dahlke's hack.
Anyone have interesting example sites to try it? I thought Youtube would be a good candidate, but very little going on for some reason.
Facebook is a non-stop symphony
Google maps is pretty funny
This is one is my favourite. Zoom in and out and you're a DOM DJ.
I tried with twitch
You can do something similar with an AM radio on a minimalist Linux install with nothing in the background.
Install NetBSD on the radio for extra effect.
https://en.wikipedia.org/wiki/Natalie_Jeremijenko#Live_Wire_...
>Live Wire (Dangling String), 1995
>In 1995, as an artist-in-residence at Xerox PARC in Palo Alto, California under the guidance of Mark Weiser, she created an art installation made up of LED cables that lit up relative to the amount of internet traffic. The work is now seen as one of the first examples of ambient or "calm" technology.
https://web.archive.org/web/19970619144534/http://www.ubiq.c...
>Designing Calm Technology: Mark Weiser and John Seely Brown, Xerox PARC, December 21, 1995.
>Introduction: Bits flowing through the wires of a computer network are ordinarily invisible. But a radically new tool shows those bits through motion, sound, and even touch. It communicates both light and heavy network traffic. Its output is so beautifully integrated with human information processing that one does not even need to be looking at it or near it to take advantage of its peripheral clues. It takes no space on your existing computer screen, and in fact does not use or contain a computer at all. It uses no software, only a few dollars in hardware, and can be shared by many people at the same time. It is called the "Dangling String".
>Created by artist Natalie Jeremijenko, the "Dangling String" is an 8 foot piece of plastic spaghetti that hangs from a small electric motor mounted in the ceiling. The motor is electrically connected to a nearby Ethernet cable, so that each bit of information that goes past causes a tiny twitch of the motor. A very busy network causes a madly whirling string with a characteristic noise; a quiet network causes only a small twitch every few seconds. Placed in an unused corner of a hallway, the long string is visible and audible from many offices without being obtrusive. It is fun and useful. The Dangling String meets a key challenge in technology design for the next decade: how to create calm technology.
>We have struggled for some time to understand the design of calm technology, and our thoughts are still incomplete and perhaps even a bit confused. Nonetheless, we believe that calm technology may be the most important design problem of the twenty-first century, and it is time to begin the dialogue.
[...] (read the whole paper, it's great!)
>Dangling String: Let's return to the dangling string. At first it creates a new center of attention just by being unique. But this center soon becomes peripheral as the gentle waving of the string moves easily to the background. That the string can be both seen and heard helps by increasing the clues for peripheral attunement.
>The dangling string increases our peripheral reach to the formerly inaccessible network traffic. While screen displays of traffic are common, their symbols require interpretation and attention, and do not peripheralize well. The string, in part because it is actually in the physical world, has a better impedance match with our brain's peripheral nerve centers.
>In Conclusion: It seems contradictory to say, in the face of frequent complaints about information overload, that more information could be encalming. It seems almost nonsensical to say that the way to become attuned to more information is to attend to it less. It is these apparently bizarre features that may account for why so few designs properly take into account center and periphery to achieve an increased sense of locatedness. But such designs are crucial. Once we are located in a world, the door is opened to social interactions among shared things in that world. As we learn to design calm technology, we will enrich not only our space of artifacts, but also our opportunities for being with other people. Thus may design of calm technology come to play a central role in a more humanly empowered twenty-first century.
https://www.researchgate.net/figure/The-Dangling-String-by-N...
https://www.ipv6.com/sensors/ubiquitous-computing/
>HISTORY: Media wire
>Mark Weiser in 1988 articulated the idea of ubiquitous computing for the first time at the Computer Science Lab at Xerox Palo Alto Research Center (PARC). He coined the phrase “ubiquitous computing” and wrote several papers on it. The initial forms of ubiquitous computing include tabs, pads, and boards. The first ever known ubiquitous system was the artist Natalie Jeremijenko’s Live Wire or Dangling String situated at Xerox PARC, under the technical leadership of Mark Weiser.
>Mark Weiser suggested the idea of enormous number of ubiquitous computers embedding into everything in our everyday life so that we use them anytime, anywhere without the knowledge of them. Today, ubiquitous computing is still at an early phase as it requires revolutionary software and hardware technologies.
I love how he omitted semicolons so that it cannot be used as bookmarklet.
Just minify it...?
Imagine still using semi-colons in JS source in 2020 and "bookmarklet compatibility" being your reasoning.
Semicolons in JS is how you differentiate between someone who understands that code ambiguity leads to pain, vs someone who shouldn't be allowed near multi-line statements.
Honest question: how often does the code ambiguity due to lack of semicolons lead to non-obvious bugs? I'm nowhere close to being a JS expert, but I've done some JavaScript-heavy pet projects and I've got an ambiguous statement interpreted wrong exactly once, and the cause was pretty obvious within a minute of looking at the error.
In my experience, precisely as often as you write statements that start with a left bracket or paren. E.g.
Statements like that are virtually always errors under ASI, but if you avoid them nothing else causes problems.[1, 2, 3].forEach( ... ) (function(){ ... })()It's not so much how often it happens, but how freaking hard it is to find the problem by inspection when it does happen.
Linters correctly highlight all the ASI-related that realistically happen. (Or eslint does anyway, can't speak for others.)
Good linters correctly highlight all missing semicolons as a symptom of sloppy, negligent, careless programming (or pointless syntactic showboating). It's also technically syntactically valid to omit braces around single statements after if, else, for, and while statements, but idiotic and dangerous to do that, too.
https://wiki.c2.com/?FixBrokenWindows
https://www.rtuin.nl/2012/08/software-development-and-the-br...
https://blog.codinghorror.com/the-broken-window-theory/
https://medium.com/@matryer/broken-windows-theory-why-code-q...
If you accidently write a comma instead of semicolon it can have interesting effects.
Please give a concrete example of this pain that you have actually experienced. I understand that ASI (automatic semi-colon insertion) is in theory ambiguous because you are relying on the compiler, or in some cases many different compilers, to execute the statement correctly. In practice, for over a decade, I have never run into such an issue. I suspect it's due to engineers trying to get too cute with their implementations.
Crockford on Bootstrap's semicolon omission: “insanely stupid code” (github.com)
https://news.ycombinator.com/item?id=3842713
https://github.com/twbs/bootstrap/issues/3057
And don't forget to semicolon-harden your most important mission-critical code:
https://www.bluejava.com/4PN/Semicolons-in-JavaScript---The-...
;;;;;;;;;;;; // protective wall of semicolons ;;var a = 10, b = 20;; ;; ;;function add(a,b) ;;{;; ;;return a + b;;;;;;;; // this function MUST work ;;};; ;;;;;;;;;;;; // protective wall of semicolonsWithout opening your console, consider whether the below code throws or not and why:
var a = [] var b = '' var c = {} [].concat.apply(a, [b, c]);[]... is one of two rules you memorize when you omit semis. It's not even that common of a case, though your own example doesn't even make sense.
I don't really understand the drama, just like people who use semis in place you don't need them. In real code, you should be using a linter anyways. At which point semis or no semis becomes purely an aesthetic concern. Like whether you use single or double quotes.
I haven't used semicolons in over 8 years and never had an issue. And with tools like eslint and prettier, you have no excuse to be making such trivial mistakes, like adding superfluous semicolons like function(){};
I have other more important rules I need to memorize with those brain cells, that I don't need to voluntarily choose to give myself more problems that require me to memorize ridiculous rules and obscure special edge cases to look out for all the time, that inexplicably screw me if I happen to slip up and forget to apply them. I stopped playing "step on a crack, break your mother's back" years ago, when I was old enough to actually have somewhere I needed to be.
A typical response is
Where the program returns undefined. I can only think of these examples as straw men. Not once did I run in to an ASI bug.return falseNote though, that this ambiguity doesn't really affect the whole "whether to use semicolons" debate either way. If anything, it's more likely to occur in code that does use semicolons than in code that doesn't.
Quite right. As do other examples.
Thank you. I have yet to see an example in this thread or anywhere else that did not fall into this category.
foo=arr[i] (counter++)if(foo) doX() doY()Intuitively this becomes:
if(foo) doX() doY();
Intuitively, as a someone who uses C style languages, this becomes:
if(foo) doX(); doY();
Can someone confirm which intuition is correct?
I ask because, to me: it not being intuitive is a problem--even if it is not classified as ambiguous.
It being only contextually intuitive, also seems somewhat problematic--but maybe excusable if it is assumed you know some similar language going into it and it behaves similarly to that other language.
No idea what GP was trying to say, but the C style intuition is correct. The bug in that code is due to omitted brackets, it has nothing to do with semicolons/ASI.
My point was that its hard to tell where the semicolon will be inserted. As well as the intention of the programmer. Here is another example:
if(x) return "foo" return callback (1,2,3,4)I think I see what you're saying, but the context here was asking for cases where omitting semicolons causes non-obvious bugs. I mean:
clearly there's a bug there, but adding in semicolons wouldn't change the code's behavior. So it doesn't affect the "is it bad to omit semicolons?" debate either way.if(x) return "foo"
The linter will tell you there should be a semicolon, and you are like, - no it shouldn't.if(y) return "bar"
For the benefit of the rest of us, can you explain what issues this causes and where/how you are running this code?
Bookmarklets are situationally pretty useful; they’re the easy entry to custom cross-site userscripting, a test drive before going full extension. They’re as legit a use of JS as anything else is.
(That said: if you use someone else’s code, putting up with their style is part of the bargain, even if I think leaving out semicolons is pointless aesthetic bikeshedding.)
> even if I think leaving out semicolons is pointless aesthetic bikeshedding
Bikeshedding isn't when you paint the bikeshed your favorite color, it's the bickering over the shade it should be painted which is actually what you did, especially since the damage has already been done. ;)
This whole thread is insufferable bikeshedding.
Imagine not understanding why bookmarklet compatibility is cool for something like this and putting people down for it with a cheap "it's 2020" meme.
A bash one-liner solves this problem for you. If you think it's "cool" to execute JS as a bookmarklet you are free to distribute your own version of the library. The original commenter was the one "putting people down" by demanding the author do it "the right way".
upvoted, because yes!
but also, violentmonkey
forbes.com is so bad...