Although I’m broadly in favour of this, I agree with one of the commenters (RO) that care must be taken to protect sensitive wildlife.

I also agree that care must be taken to enable swimmers to protect themselves. (This is very different from preventing swimmers from swimming!) Here’s what I mean:

In order for people to be able to make an informed judgement about the safety of swimming in a given body of water, there are two things they must have information about, besides knowledge of their own abilities:

1. Physical hazards existing in the body of water;
2. The quality of the body of water (i.e. is it biologically or chemically contaminated).

Point 1 should, I think, be handled as follows. If the hazards are obvious (e.g. white water), then nothing needs to be done, since no-one ought to brave those hazards unless they’ve got the skill and training to do so. If the hazards aren’t obvious (e.g. submerged drains, weirs (which are more dangerous than they look because of the back-currents and aeration they produce), or suchlike) then signposts should be placed nearby warning of the hazard(s). Fortunately, this is already done by landowners or local councils in most places.

Point 2 is trickier, but surmountable. It would be very useful if there were a website one could visit that would be updated weekly with reports of the water quality in popular swimming spots. Visitors to the website should be able to add swimming spots to the list of spots to be checked (much as they add ideas on this website), with all spots receiving at least a certain number of requests automatically being added to the list of spots for the checking agency to consider.

The agency/agencies responsible for checking the water quality at the swimming spots ought to ensure that no time-wasting redundant measurements are made (e.g. multiple measurements close together on the same body of water). Once that’s done, it’s just a case of sending off a bloke in a van (or better still, on a bicycle) to collect samples once a week and bring them back to a lab. The lab would then assess the water quality and post the results on the website.

Those who don’t mind swimming in algal blooms, etc, would still be free to do so; the rest of us, if the website reported the presence of that sort of contamination, could make an informed choice to wait for the contamination to clear before returning to that swimming spot!

A side benefit of the system I’ve proposed is that it would motivate people to consider the quality of their environment. After all, if you learn that your local swimming spot is chemically or biologically contaminated, that’s a good incentive to pressure your council to investigate the local farms, industries or sewage works that might be causing the contamination. This would increase the transparency, of local politics and of the water!

(A quick aside: there are many companies providing copy shop services, some independent, some parts of larger retail chains. The interesting thing about Kinko’s, to me, is that it’s so ubiquitous in the US that (a) Kinko’s has become practically synonymous with copy shop, and (b) people know which services they will find on offer at branches of Kinko’s, and at what cost. This sort of combination of scalability and predictability is, I think, useful for customers, even though it is in other respects a rather sadly homogenising influence on modern consumer culture.)

Now, in an urban environment where room is scarce, flexibility is key, and travelling distances are short, companies like this make a lot of sense. Students, hobbyists and professionals alike may well need the services Kinko’s offers, but may not have the space or the budget to accommodate the necessary equipment or operators. Kinko’s, essentially, allows these customers to time-share their equipment, staff and floor space, on an as-needed basis. Even for those customers who have the facilities to print/scan/etc themselves, having a Kinko’s is useful: it provides a backup option in case the customer’s own equipment goes kaput shortly before a deadline.

That’s all well and good, but let’s get back to fab labs. Increasingly, students, hobbyists and professionals are interested in manipulating 3D information and materials for prototyping purposes, or for very limited production runs. New recipes for rapid prototyping tools like 3D scanners, 3D printers, CNC routers, electronic fabrics and items that can be made using them appear frequently in the pages of Make magazine, Instructables.com and other modern DIY publications. This does increase the affordability of such things but the trouble is, even the basic tools (drills, saws, etc) and materials required to follow some of these recipes take up a fairly large amount of space relative to the size of a small urban apartment or office. If you want more sophisticated options like 3D scanning and printing to be available to you as well, then you need even more space. This is much like the problem once faced by students, hobbyists and professionals who needed 2D information tools like photocopying available to them; the problem Kinko’s business model is based on ameliorating.

I’m going to advocate that someone – maybe even FedEx (the owner of Kinko’s); it doesn’t really matter who – creates a chain of Fabrication Stations that operate on roughly the same principle as Kinko’s. For a small fee, these outlets should offer to perform, either with the customer’s assistance or while the customer waits, such services as:

• 3D scanning
• 3D printing (at least one kind)
• PCB manufacture
• Sewing (using conventional, high-tensile, or conductive thread as desired)
• Drilling
• Cutting
• Grinding
• Sanding
• Buffing
• 3-axis milling/routing

Just as Kinko’s stocks various kinds of paper and ink to run their equipment, so the Fabrication Stations should stock standard PCB boards, commonly-used construction fabrics and threads, and any consumables necessary for their 3D scanning and printing devices.

This isn’t so far-fetched – several universities already have fab labs providing these services – and it needn’t require a large amount of real estate: it’s possible to fit a fab lab into a trailer (and they come in many other shapes and sizes too).

It’s likely that Fabrication Stations having commercial viability as their primary requirement might differ somewhat from the standard fab lab specs, which seem to assume a non-profit environment, but although this might mean they would be slightly less suitable as educational tools, they would appear to be a socially valuable proposition nonetheless.

Why am I writing all this? I’ve got a list of handy things I’d like to create, but I don’t have the time or equipment to make them all. Having a Fabrication Station in my neighbourhood where I could get some of the more equipment-intensive parts of the fabrication completed would tip the balance in favour of getting (these) things done rather than putting them off, and I’m all in favour of the former!

It’s not a lot to ask.

I propose that online music stores should, except perhaps when they are selling solitary songs, sell their records in a format that includes all of this. It would probably be something like a JAR file but for musical records instead of Java programs. Each file would have a copy of the inlay card and cover art as a PDF or suchlike, and a playlist in XSPF or similar. The tracks would also be included in the JAR (or whatever; let’s call it a UZQ file in honour of Michael Paradinas’s best-known alias) file as FLAC files.

How hard would this be to implement? For a major online music retailer like 7digital or iTunes, not very difficult. What about player software? Most player software could very rapidly be extended to accommodate such a file structure.

So, why hasn’t this been done? Is the industry waiting for someone to write a UZQ file format specification? Has someone already written an archive file specification for music based on JAR, TAR, XAR or similar, but it didn’t catch on? Please leave your thoughts and insights as comments below. Thanks!

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.

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.

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.