Cognitive Conga: a blog

Dancing the conceptual kerfuffle shuffle

Ratiocination, n. An instance of [reasoning]. Also: a conclusion arrived at by reasoning. Doubt the applicability of this at your peril leisure.

Archive for the ‘Poor man's patents’ Category

Bundles of musical joy

Thursday, November 26th, 2009

I’ve not tried every online music store nor every music file format, but far as I know, there’s no file format that replicates the experience of buying a physical record, whether that record’s on vinyl, CD, cassette, or some more esoteric format. All I mean by “replicates the experience” is that the file format should provide the songs in the highest quality the medium will allow, should include all the album artwork and liner or inlay card that would come with the purchase of the physical album, and should provide a recommended playlist order for the tracks complete with a recommended gap between each track.

(more…)

Equitable license

Saturday, January 31st, 2009

Not much to see at this point; more to come in future, time permitting!

Rolltop

Saturday, January 10th, 2009

Ever since my mother got a Thinkpad 240 to use for her work, most of a decade ago, I’ve been of the opinion that tiny laptops are really useful for their portability but irritating because of their tiny screens. The ideal thing would be something that was as handy to carry as a book, and with a keyboard just big enough to type on at a good speed (60wpm at least), but which also had a large enough screen that the user wasn’t constantly scrolling and/or suffering from eyestrain.

Some kind of multi-panel, unfolding screen, perhaps.

And all of a sudden, something like this is available on the mass market.

Seeing a real-world manifestation, after a couple of years of harbouring a utopian fantasy in which laptops unfurled giant screens, makes clear that current mass market computer engineering isn’t up to my vision. So I’ve just had a think for a minute about how a manufacturer might narrow the gap.

The answers’s pretty easy: use a resilient flexible display that rolls up around the laptop (like a firehose around its hub, but with fewer coils) and can be unrolled and stiffened with springs, struts or goosenecks for use. A tensegral approach to supporting the unrolled screen would probably be the best for an optimal tradeoff between the twin goals of low weight and high rigidity.

But technology like this is probably still a few years off. In the meantime, the XO-2 will likely be the next best thing.

Earglasses*

Tuesday, June 10th, 2008

Mel Chua’s recent post about communication reminded me that I’m lagging on something I started many months ago: trying to find a filter chain in Wavelab that would let her hear things – music in particular – in a manner closer to that of someone with normal hearing.** A while ago she blogged about her auditory response being like that of a low-pass filter, and that made me think about what the most practical way to mitigate that response would be.

I don’t know what the audio-processing algorithms hearing aids use are, but it’s fairly clear that:

  • the user doesn’t have much ability to modify them, except perhaps in the case of highly expensive models.
  • they probably aren’t terribly powerful, because – judging by digital hearing aids’ power consumption – the processing power available to them is very small.
  • although amplification is one of the primary components of a hearing aid’s processing chain, amplification alone won’t combat most hearing difficulties (certainly not Mel’s).
  • they are optimised for speech, rather than music.

So I set about trying a different approach: CPU-intensive audio-processing using the best algorithms I could lay my hands on (i.e. Wavelab’s plugins), optimised for music. I set up an EQ stage at the end of the chain, modelled on the graph of Mel’s auditory response, and started applying filters before it in an attempt to make the end result sound as natural as possible. I had a hunch that multiband compression might be more effective for this than EQ – certainly more effective than EQ alone – and so it proved. Partly this is because multiple stages of EQ filtering can induce “ringing” (they become resonant – an unwanted side-effect). Although multi-band compressors include EQ filters to split the signal into bands, these filters didn’t seem to suffer from the same side effects, perhaps because the compression was attenuating any resonances that might have otherwise been present.

Anyhow, a few months ago – long after my first experiment, I was blessed with a few minutes of the Mel’s time, and we tried some of the filter chains, with The Decline as the test track (because it was the only CD I had to hand with a mix that I was familiar with). We were somewhat successful, but I haven’t had time to do much more with the algorithms since then.

I mentioned to Mel that I thought it would be cool to make portable Sharc DSP devices so people could carry their audio processors around with them, set up so that they could select and edit the algorithms. This isn’t very far-fetched. There are lots of battery-powered, pocket sized audio processors on the market at affordable prices (for instance, the Korg Pandora). I don’t know if they use Sharcs, but I do know that many price-breakthrough audio processors with pluggable algorithms that I’ve seen hit the market in recent years have used Sharcs, so they seemed like a good bet. (Mel knew the same company’s devices by a different name, Blackfin, and suggested those. Then we worked out we were talking about essentially the same thing :-] The Blackfin is a sibling product to the Sharc.)

And this is how I come to be writing a blog post called Earglasses. Sunglasses – filters for your eyes – are easy to get hold of, and not even very hard to make, but filters for your ears aren’t so straightforward. I doubt Mel and I can’t make earfilters possible by ourselves because we’re both too busy with other things, so this is where a community effort might come in handy. I’d love to see a bunch of people working to make earfilters – affordable, portable devices with an audio input and a headphone output and ton of helpful, user-programmable algorithms running in between – a reality. So making this an open hardware, open software project seems like the way forward.

I’ve registered earfilter.org and will set up a wiki there shortly. It will be a place that people can post their filter chains (from Wavelab, Audacity, etc), links to useful plug-ins, suggestions for hardware architecture, and anything else that’s relevant.

* * *

*It turns out there actually is a company manufacturing what they call Earglasses, a kind of latter-day ear trumpet. Whaddya know. Their engineering reminds me of Big Ears, which I’ve known about ever since I took up the dubious habit of reading Canford Audio catalogues as a teenager. (Actually, I learned a lot from those catalogues – and from CA’s competitors’ catalogues – which included pinouts, specs, regulations, construction diagrams and all sorts of other nutritious information for enquiring minds.)

**Mel’s post was, of course, not just about hearing. I’ve focused on that aspect of it here because of the earfilter.org idea, which I wanted to let the world know about. Mel’s underlying point is about communication, and I couldn’t agree with her more: any barrier to communication or comprehension can be frustrating. One of the greatest joys, for me, of living in the information age, is that we’re better placed than any previous generation to reduce or eliminate those barriers. Another great joy is that there are so many people working passionately and enthusiastically to do just that.

Grep the web from the web

Sunday, May 11th, 2008

I like grep. Grep lets you search within files, using regular expressions. Usually, you can even use wildcards to specify which files grep should search within. This means that when you ask grep to find something, you can give it just about as much information as you know, reducing the chances that it will spend a long time looking in the wrong place(s) or that it will return the wrong result(s).

But why can’t I do this on the web? Well, maybe it is possible, but I haven’t yet found a web site that offers to search the web in a way that lets me use wildcards while specifying which URLs to search at and that lets me use regular expression syntax to specify what to search for. (If you know of such a site, please post it here.)

In the absence of such a site, I’d like to propose creating one. So I’ve registered www.greptheweb.com and I’d like the community’s help to build a site to put there.

The site should, I think:

  • Have a front page with a form that has two fields:
    • Where to search. Here users can enter URLs with Perl regex syntax.
    • What to search for. Here users can specify strings they’re looking for, also using Perl’s regex syntax.
    • User’s should perhaps be assisted in entering their queries by means of a RegexBuddy-style helper, maybe implemented with AJAX techniques.
  • Have a help or FAQ page.
  • Have results pages that are dynamically generated with GET requests. These would be returned in response to a form submission, but would also be generated in response to a direct request, e.g. from a bookmark.

The back end of the site is the hardest part, of course. Web search engines are difficult to implement well. Scaling is an issue. I’ve never built a search engine; I’ve never written a grep-like program. Still, I have some ideas about how the back end should work.

  • It could just use the Alexa Web Search’s “grep the web” service, templating the results in HTML and returning them to the user; or
  • It could be built from scratch. If the latter, then:
  • It should, to begin with, index pages in a simplistic fashion. That is, it should include a robot that can find pages with straightforward URLs like http://www.python.org . Eventually the robot should be made sophisticated enough to find all publicly-accessible web pages.