21–30 of 42 posts
Book on the subject: Gregory Kramer - "Auditory Display - Sonification, Audification and Auditory Interfaces"
Thanks, ordered. There's a substantial body of research in this area, and we're just becoming conversant with it now.
This is great stuff, congrats on launching. Instead of simply generating a fixed sound for each event, have you considered synthesizing a continuous multi-track score? Like a baseline piece of orchestra music being modulated by the events. Or something like Brian Eno's http://en.wikipedia.org/wiki/Generative_music Also, perhaps consider streams of data other than discrete events: perhaps continuous metrics like CPU u…
Continuous data is one of the very next things we are implementing, partly because a sufficiently dense discrete set of events becomes a frequency, partly to cater for measurements like load. We plan to indicate magnitude with pitch and volume, but there are some complexities in the API and representation that we're working through first.
No doubt a super cool and out-of-the-box idea, but I quite personally would go crazy if I had to hear water droplet sounds any longer than an hour.
I really dig the idea and can see the coolness in hearing analytical data, but is it just me or is the Github real-time demo super annoying? First couple of minutes were okay, but in this instance where there is a constant flow of data playing sounds, it gets really old, really quick. No doubt a super cool and out-of-the-box idea, but I quite personally would go crazy if I had to hear water droplet sounds any longer…
Also, whether any particular sound is annoying or pleasant is complicated (we're just figuring out the parameters now) and subjective. So, we're working on letting users create, edit and share sound packs to see what smarter and more talented folks than us come up with.
I really dig the idea and can see the coolness in hearing analytical data, but is it just me or is the Github real-time demo super annoying? First couple of minutes were okay, but in this instance where there is a constant flow of data playing sounds, it gets really old, really quick. No doubt a super cool and out-of-the-box idea, but I quite personally would go crazy if I had to hear water droplet sounds any longer…
It's not just you - the GitHub demo is a tad annoying. The idea was that we might have people's attention for 15 seconds on average, and we wanted them to get a feel for the full spectrum of sounds in that time. So, it's tuned to be much more intrusive than a production stream might be. Also, whether any particular sound is annoying or pleasant is complicated (we're just figuring out the parameters now) and subjectiv…
1) If a graphical plot turns data into something visual, an audio "plot" turns data into something audible. Your output is an audio file rather than an image or video file. The typical applications of this are to turn a boolean flag into a chime (e.g. text message received). Your important insight is that this can be extended to longer-form audio outputs.
2) When is audio more advantageous than image or video?
- When you cannot look at a screen (driving, working out)
- When there are too many screens (control room)
- In a very dark environment where visibility is impeded
- If you are blind or vision-impaired
Perhaps the most interesting application would be in a car, which is where people spend a great deal of time and have their ears and brains (but not their eyes) free. Some ideas:
a) Could you generate different sounds based on the importance of a text message (doing something like Gmail's importance filtering) signaling that you don't really need to respond to this particular message right now while driving?
b) Could you have audio feedback for important things along the road? For example, the problem with the Trapster app (trapster.com) is that I need to look at the phone to see where the speedtraps are. You can imagine an integrated audio feed that could give information like this and also tell you your constantly updated ETA (via Google Maps API call). Or you could listen to the pulse of your company on the road to do something semi-useful, and drill down into notable events via voice.
c) The really interesting thing is if you could pair this with a set of defined voice control commands. As motivation: an audible plot can't be backtracked like a visual plot. With a visual plot your eyes can just scan back to the left. To scan back and re-heard the sound you just heard requires rewinding and replaying. But it could be interesting to set up a small set of voice commands that allow not just rewinding, but rewinding and zooming. So you hear an important "BEEP" and you want to say something like "STOP. ZOOM" and set up the heuristics such that this identifies the right BEEP and then gives an audio drill-down of exactly what that BEEP represented.
d) Done right, you might be able to turn a subset of webservices into a sort of voice-controlled data radio for the road. People spend thousands of hours in their cars so it's a real opportunity.
Very interesting and highly creative. A few thoughts. 1) If a graphical plot turns data into something visual, an audio "plot" turns data into something audible. Your output is an audio file rather than an image or video file. The typical applications of this are to turn a boolean flag into a chime (e.g. text message received). Your important insight is that this can be extended to longer-form audio outputs. 2) When…
http://alexdong.com/choir-dot-io-explained/
We definitely see Choir fitting in where you can't look at or interact with a screen. Cars and wearable computing are areas we're excited about. First, though, we want to experiment on the desktop, find out what makes a good audio interface, and solve our own burning needs regarding more mundane monitoring situations.
Earlier quoted context omitted.
It's not just you - the GitHub demo is a tad annoying. The idea was that we might have people's attention for 15 seconds on average, and we wanted them to get a feel for the full spectrum of sounds in that time. So, it's tuned to be much more intrusive than a production stream might be. Also, whether any particular sound is annoying or pleasant is complicated (we're just figuring out the parameters now) and subjectiv…
How about applying real-time effects to the audio? Nothing heavy, but just so they're rarely or never exactly alike? Preferably adjusting the parameters depending on something to do with the event (for example, make the "starred" sound less high pass filtered the more projects the user doing the starring has)... and then add the ability to define and control said audio filters to sound packs. Of course this would inc…