Older blog entries for jmelesky (starting at number 8)

sphair : I think you're talking about gumption, not inspiration. Inspiration is great for realizing the solution to a problem. Gumption is needed to actually implement that solution.

On that note, if i may be so bold to dispense some advice, i would recommend forgetting about it for a bit. When i find that i'm slacking off at work and avoiding my computer at home, i try to take a step back and relax. Then i find something that's completely unrelated to what i should be working on, and let myself get into it. It's good for releasing tension, and lets you be productive on something, which can help you go back to being productive on whatever you were supposed to be doing in the first place.

In fact, i end up doing alot of my fun stuff that way, as a decompressor before hitting the stuff people are expecting from me. Stream of the Web came into existence that way. Give it a shot.

And good luck. :)

raph : The boys at Berlin are definitely dealing with the sort of resolution problems you're worried about. All things drawn to the screen are defined in terms of actual size, not virtual size (inches vs. pixels).

For those of you who don't know, Berlin is endeavouring to be a windowing system that can replace X. Whether or not you think this is a good idea, you should check it out (and possibly even offer to help).

aigeek: Probabilistic grammars are equivalent to Markov chains when the grammar is the trivial case, which is where i am at the moment. ;-)

Seriously, though, my opinion is still that there are plenty of other people in the world writing music generators that are based on Markov-ing and probabilistic grammars (which i generally consider the logical next step), who've been doing it longer and better than i. What i'm working towards involves more on the structural level, more play with themes and motifs, which i'm not convinced work well with those tools. And, besides, i'd much rather make it up as i go along (i came up with all of the ideas behind this project independently so far. only after i had been fiddling for a while did someone point out the similarity between what i was doing and Markov chaining.).

It's certainly the case that doing something from scratch can lead you to reproducing other peoples' work, which is generally considered inefficient, redundant, and bad. On the other hand, knowing a given solution to a problem can often limit your thinking about that problem to ways in which the solution is applicable (give a person a hammer, and everything starts looking like a nail. give someone hash tables native in a language, and they'll use them everywhere -- even when a tree or queue might be more appropriate.). I wanted to go into this project with as few preconceptions as possible. If i reproduced work, so be it. If not, then maybe i'd have stumbled on a novel, useful technique.

Of course, if this were a systems project or something similarly complicated and mission-critical, i'd definitely be grabbing as much outside info as possible. But it's an AI project, so i can do as i please...

That said, probabilistic grammars are something that interest me (in their natural language applications, as opposed to musical). Can you recommend any books on the topic?

Employed! Start tomorrow hacking Perl. Not much on the benefits, but a very nice work environment and the word "Senior" in front of my title (which, though i often claim not to care about such things, is kinda nifty).

Was up for another job, which would have involved working with cooler stuff (some voice tech, lots of user customization stuff), but would have required me to move back to the east coast, which i wasn't really ready to do (although, i admit being courted for the job over several hundred miles was flattering).

Been doing some more Hume work, still stuck in datatype-land. Basically, i've taken the whole grab structure to its next logical step (as far as my uses for it go). Since i use it to track state, and have it represent the probabilities of given state transitions, it makes a great deal of sense for it to evolve into a matrix of states. The major utility increase will be in the groupable grabs, where i will now be able to make groups of transitions that span initial states (e.g. a group named "up a major fifth" can be included, which would then tie together all the transitions of that type across the set of states (notes) that i'm using).

The next logical step, of course, would be to increase the axes of the matrix to three or more, offering more than one level of Markov simulation. However, since others have done Markov before and (IMHO) better than i would, i'm not sure i'll go that route. There are other interesting bits up my sleeve.

Finally, grab.py is all set. Or, at least as set as it gets. It's not much, but it works the way it's intended to. It's even documented.

It's not exactly a unique idea, though i only heard about other instances of it after i had figured it for myself. I wrote it as part of the whole Hume thing, and i figured it was general enough that others might find a use for it.

Anyway, it's late and i'm tired. And i need to repartition my hard drive again.

Well, howdy DeWitt and Jon. You may also be interested in knowing that Bob seems to be at least partially here. It's a smaller world than i was originally given to believe.

I have a real entry, but i'm going to do some more work on it before posting.

First off, i want to thank lilo for accrediting me, and cmacd for offering proof that people really do read these things. Encouraging and unsettling at the same time.

Had a realization today that one of the most important qualities i'm looking for in a job isn't "small company" or "casual environment". It's "no PowerPoint presentations". I can handle lots of things, but i flatly refuse to make ppt presentations (by which i mean "slideshow presentations", ppt being the standard, and easiest to deride).

I'm serious. It's not that i refuse to explain things to people -- i'm happy to do that. Give me a whiteboard and a half-hour, and i'll happily convey the concept of a TCP stack to the most unenlightened of board members. But i draw the line at reducing the problems of a department to three vapid, overgeneralized bullet-points, then following up with three equally vapid and overgeneralized solutions.

I realize that i'm probably painting an unfair portrait of the whole slideshow presentation thang, and i'm sure that, somewhere, they are being used for genuinely useful and appropriate exchanges of information. But that's an assumption -- i have no proof.

On a slightly less rant-ish note, i had the wonderfully cathartic experience of expounding on the sound capabilities of the Apple ][ earlier today on a listserv. I'm convinced i've weirded everyone else out, but it was good to type up some old 6502 assembler. Purges the soul.

Ah, so i've formulated a new theory on the young/old boundary. It's an esoteric thang, and really the only reason i bother mentioning it here is because i think it might apply to software maturity.

You see, the usual idea is that you become old when you're disillusioned with the ideals you had when you were younger. So, if you can look back five years and say, "Wow, i actually believed that. How cute.", then you're probably old.

I propose, however, that you're still young at that point, or at least at some not-young-but-not-yet-old state. Because, i think, there's a point at which you look back five years and think, "Yep, still right." That is when you're old. When you no longer innovate in your own value system.

Ok, ok, it's just a theory, and i haven't really thought it all the way through yet (and, ideally, the theory will obsolete itself in five years as far as i'm concerned). But i think there's something valid there, about how youth is the time when you grow, and growth is about making mistakes (or at least refining truths). And i think there might be a parallel in software development.

You know how it is, when you first start a project, and you whip through the first few iterations before realizing that some of your base assumptions were way out there (whether you whip through it in code, or on paper, or whatever, you usually get through the first few times pretty quickly). Then comes a period of time when you've decided on some basics, but everything else is in flux (should the API be functional or OO, how to group the code, which features should be extended...). Usually that period of time (at least for open source projects) is when the project has hit the "real world", and the changes are made to respond to real needs. That's when a project is really maturing, but can still change drastically over the course of a few months.

At some point, though, that kind of rapid change slows down, or even stops. Eventually, everything's in place, and the only new development is for bugfixes. Sometimes this is a wonderful thing, a venerable perfection, like TeX, or sh. It solves the task given to it with aplomb.

Sometimes, it's old senility, like sendmail, or the Windows Registry. Somewhere along the line, it ceased to be a process of refinement, and became a hack, stretching to fill a taskspace not originally part of the plan.

Hmmm.... i'm no longer sure where i'm going with this, so i'll stop. Analogies only carry you so far before you notice their deficiencies.

But, just for the record, i'm still right. :P

... at least for another couple years ...

The job search continues, and i seem to have stepped in a recruiter. Ugh. Although i like the benefits of employment, i find the whole business of becoming employed rather distasteful.

Work on Hume is continuing well, and i believe i've finally settled on an appropriately flexible framework for the pieces themselves. I need to verify that Python is capable of that kind of function-as-data thing, but i have a few workarounds if not. Things will pick up again when i bother to fix my home desktop.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!