Just some random thoughts of yet another someone who went to OCAD

I had my first stab at generating some sound today. It was a total flop: Not only does it not sound like the real thing, it doesn’t in fact sound like anything that is not random noise. (But I was pleasantly surprised to find that once I had all the data in .npy format, access becomes instantaneous so long as I specify 'r' in numpy.load(). Converting all those .vtu files to .npy was not in vain.) I need to figure out a way to make something that sounds less random. The question is how.

Something has changed. Last year when I told people which program I was in most people just drew a blank: They had never heard of our program. This year people might not know a lot about our program, but they seem to have at least heard of it. Last week when I slipped into the Student Union office to ask about volunteering I was asked if I was in the undergrad program or the grad program. Today I was chatting with someone else from the SU and I was again asked which program I am in, and when I told her she called our program “the mystery program”. And she asked me how classes were going and I told her I am quite worried because all the courses this semester are basically “do your thesis”, “one way to help you do your thesis”, and “another way to help you do your thesis”. (“But you are just second year. Are you sure you’re not third year?”) Oh, and I told her we don’t actually call it a thesis. But what answer did I get? “That’s a thesis. It takes a whole year to do, right?” People still aren’t aware this is a two-year program, or why it’s a two-year program for that matter. But our program has graduated from being the unknown program to “the mystery program”: That is an improvement.

I finally figured out what’s wrong with my setup: I need to use the copy of python that comes with Paraview, which is a 64-bit version, and not the copy that came with MacOSX, which is a 32-bit version. I kept running out of memory not because the arrays were so huge, but simply because 32-bit python can’t handle these arrays. So I have converted everything to .npy files and I’m now ready to start try synthesizing some sounds!

I set my code to track 1000 random points, and after 2006 seconds (unattended, of course, and only at the 7th point attempted), it errored out complaining about not able to find the point it was looking for: The best point was over 2.0 pixels away. Let me try to relax the constraints a bit and see how it will do. But the question now is: How does Paraview do it?

So some sort of tracing code was in place and I ran it the first time with the full data set. The computer started crunching the numbers and then a few minutes later it spat out

python(54674) malloc: *** mmap(size=587386880) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Traceback (most recent call last):
…
MemoryError

I was only trying to trace three points and it still ran out of memory. I’ll need some other way to do this.

Today is August 30, the last day for submitting an entry to a certain design competition, but I’m not going to submit anything. Nor will I likely submit anything two months from now when the other competition closes — one that, if this means anything, I would probably not do well in any case but was still really excited about — in my eyes, it’s all about identity and EGD. And if you asked me, I was really disappointed when I found this other competition to be “equivalent to spec”: I was talking about my ideas with one of the docents at The Power Plant and neither of us thought there’s anything wrong with that competition. I had dug through hundreds of discussion postings on spec-vs-no-spec before I had any connection to the AIGA, but I have always felt real contests — especially those that are clearly branded as student contests, one that you find on your art school’s job board even — had to be some kind of an it’s-still-ok-even-though-it’s-kind-of-grey area. But compared to AIGA’s pretty much advisory position, RGD’s position leaves little room for interpretation. In a sense, the RGD’s much stricter position forces you to think more, so it’s a good thing, I guess. My program’s program director likes crowdsourcing, thinking it to be possibly a good way to get those pesky accessibility problems solved. But crowdsourcing in tech circles isn’t really the kind of taboo it is in the graphic design world. So who in my program will worry about spec? Probably very few. In any case, September is coming, and I will be back in the ceramics studio very soon. If I’m fortunate enough to be able to log sufficient time to enable me to produce some decent work before I finish my thesis in what now appears to be May, then maybe — just maybe — I might be able to show my work in some less controversial venue.

It looks like I’m now at the point where I’ll have to rewrite everything in python. I’m going to have to deal with multiple data files with multiple huge arrays, and perl is just not going to cut it. And then I’ll have to worry about interfacing with OSC. Of course, if I’m going to switch over to python, I should be able to use normal VTK functions and not worry about rolling my own file parsers. The problem is that two years after taking NLP at Coursera, I have already forgotten how to code in python. This is going to be a problem.

There is an exhibition going on at The Power Plant called Postscript: Writing about Conceptual Art, featuring a number of contemporary art pieces with a strong connection to the spoken and written forms. I went to see it last Sunday and yesterday, and I think I have now seen all the pieces — not meaning I’ve understood them, of course, just that I’ve seen them. One of the pieces is an installation consisting of a book with Braille and a video of a blind person reading aloud from that book. Or at least that’s what the description says. The blind person read from multiple spreads in the book, but at The Power Plant the book is locked inside a glass case, so even if I were a blind person I wouldn’t be able to read the Braille. Except that a person who is not blind can actually read the Braille — with difficulty of course, but for sure can read. Last Sunday when I spotted the piece I tried hard to read it. The lighting (and the fact that it’s in a glass case) makes it really difficult to read, but I actually managed to make out all the words on the spread. I was surprised I could actually read it, but I was more surprised by a couple of other things: First, the Braille is in the wrong language, and second, there are errors in the Braille. First, anyone who can read some Braille by sight soon figures out the Braille on the book is in English. But the blind person in the video was reading in Spanish. The Braille in the video is virtually impossible to make out, but yesterday I managed to make out two words in the video, and I had no idea what they meant — they were, I assumed, Spanish words. The blind person in the video was reading from a Spanish book, yet the book in the exhibit is in English. And when I tried rereading it yesterday I couldn’t figure out what the first letter was, and after a few minutes I figured out why: The first symbol was not a letter at all, but the uppercase indicator — a non-English uppercase indicator with two dots, not the one-dot uppercase indicator used in English Braille. Aside from the two-dot uppercase indicator, when I tried reading it last Sunday I got stuck on a word — or rather a letter: dots 1-2-6. I was thinking “Ugh, I can’t read Grade 2.” Then I realized all other words were in Grade 1, so there couldn’t be a single word that’s in Grade 2. In other words, it wasn’t a Grade 2 symbol at all; it’s a typo. What I saw was just the letter “h”, and the word was just the word “the”. So why the uncorrected mistake? Is it because whoever made the book (who might or might not be the artist — it might have been just someone helping the artist) thought no one was going to be able to read it so it wouldn’t matter? Which brings us back to the glass case: Why the glass case? Why make it inaccessible to people who would actually be able to read the book? Is the book with Braille just a gesture? Is the uncorrected mistake borne out of a prejudice?

Just got notice that there’s another deadline in two and a half weeks. I really feel this is being rammed through. Maybe not for others, for those who have succeeded in keeping up with all the previous deadlines (which, in theory, are all reasonable and laudable); but I just barely managed and I’m no longer keeping up. I have barely even finalized my direction, and now I have to formalize this direction which hasn’t even been finalized. I wonder if I’m going to make it ever, and if I do manage to, what kind of work I’ll produce. I suspect it won’t be very good work. The first professor I talked to (I don’t even remember who that was) who discouraged me and tried hard to talk me out of it was probably right all along.

Some time ago I had the chance to talk about ATutor with one of its developers, or perhaps that was not the right word: I had a heated argument with one of its developers was more like it. Until that point, I never knew we hold such divergent views on web accessibility. The crux of the heated argument was, in essence, ATutor’s reliance on Javascript for one of its most basic and essential functions, namely to log the user in, for what amounts to, technically speaking, no justifiable reason; it was, in a very real sense, a deliberate exclusion put into place. For someone who had primarily been a text browser user until just a few years ago, this was unacceptable, and this was doubly unacceptable when ATutor claims itself to be usable with text browsers. This is in effect, one could argue, a textbook case of “inaccessible” — it doesn’t matter if you can use its other functions, it is inaccessible if you can’t get in. I had, and still have, the opinion that if a web site — unless it’s an online game — relies on Javascript for any essential functionality, the site must have serious design flaws somewhere. The flaws might be hidden from view or latent and yet to be discovered, or the flaws might even have nothing to do with the “Javascripted” functionality; but, I maintain, some serious flaw must be present and it must be fundamental, because such use of Javascript demonstrates a fundamental flaw in the developer’s mentality. This was, or should I say is, not the opinion of ATutor’s developers. To them, Javascript is fair game because any “modern” browser would have it. Besides being insulting (I still consider w3m modern, thank you very much, and people who consider Javascript a security threat still exist), less than a month ago I happened to run across a BBC article about a UN accessibility report on web sites that stated quite bluntly that one of the “key shortfalls” for 73% of web sites tested was that they “relied on JavaScript for important functionality“ because “JavaScript does not work with some screen readers used by those with impaired vision.” [emphasis mine] Were ATutor tested, the UN testers would have failed it for relying on Javascript for, quite literally, its most essential functionality. This was vindication for me: I was told they didn’t consider Javascript reliance an accessibility problem; the UN thought otherwise. Some time ago I was told Pina can’t use ATutor: there could not be anything more revelatory than this. And I still maintain that there is no essential functionality — zero, nada, zilch — in ATutor that absolutely requires Javascript. What’s worse, I looked at their code base and their code is not amenable to automatic testing. In our program we claim to aim for Agile, but Agile relies in a large part on automatic testing (in the form of TDD or BDD). Short of a major code overhaul, there’s no way TDD could be performed on ATutor’s code. Thus the false claim that ATutor works for text browsers (most likely it used to in an earlier version) when in fact it doesn’t and no one noticed. Two months ago when I was looking at its code I wrote it was a “genuine piece of crap.” Their developers claim integrating small patches is expensive, but ATutor in its current state can’t be tested; of course the integrations are expensive. It wouldn’t be an exaggeration to say that the mentality of how ATutor is developed flies directly in the face of everything taught in our program, in particular designing for the extremes and disability as a condition caused by design flaws in the environment. Unless ATutor’s developers have a change in mentality, I don’t foresee ATutor achieving any semblance of true accessibility any time soon, if ever.