I'm more of a tester; as such I ironically rarely finish anything :)

i'm more of a devmatic tweaster, in that I build an app for performance which is guaranteed never to crash(on my machine for myself), and then if I need to at the last minute, I'll make only small changes/tweaks.

the 2 apps i made for the monome community C¥¶€R and MonoMahna(project 90-something'r'other here on the c74.com) have reportedly never crashed for anyone(I also performed with MonoMahna and tried it out for a year, never had a crash). The recent app I made for my monome512, ~SerpentEclipse), I took on a small tour to 3 events here on the west coast(just got back yesterday), still never crashed. So for the full-on apps I make, definitely more of a pragmatic tester, but one area I've been running into trouble and do more tweaking in is M4L(it crashes on me all the time, and I don't seem to care enough about Live or M4L to trace bugs; I just end up using it for experiments and to generate sounds).

The pragmatism of a tried-and-true environment has impact on whether I will engage in my own pragmatism or not.

i'm with Raja, but then again, I learned much directly from him.

and then again, since I don't perform as much I guess that makes it easier for me to be a pragmatic tester.

________________________________ *Never fear, Noob4Life was never here!*

How do you know when your patch is finished? Is it ever finished?

You're probably asking Tim the question, but as for my particular experience: i've always thought they would never be finished, but in the case of C¥¶€R and MonoMahna, they really did reach a finishing point: when i moved on to the next app, that's when the old one was finished.

Of course, i have an outline of basic features in mind, once those basic features are in, the app is at a stage of maturity where i can leave it for awhile. What ends up happening then is, upon moving onto the next, i sometimes go back to the old ones simply to use them, not to develop them any further, at which point, i often realize they are even more finished than i originally anticipated because(in the case of MonoMahna in particular), I end up being addicted to the way in which the app works as is. This has only been a recent phenomenon in my life, whereas previously nothing was ever finished in my view and I kept moving on to do better and better because I was constantly unsatisfied.

In short, my apps(nowadays) are finished when they meet 3 basic conditions: 1. the app has the basic feature-set fully implemented which i originally outlined for myself when first beginning its development, 2. my actual use of the app in a state of maturity has led me to believe that i can either do better or do something newer by moving on to making a completely different and newer app, 3. i return to use the app after moving on to develop another and find that it is satisfyingly useable as i left it.

This actually means that no current app I'm using to make art, having just finished development without moving on to make something newer, is something I consider 'finished'. Instead it's more important that it is at a 'state of maturity' or 'useable'(for that art). It isn't until a newer app is started, that I finally glean a 'finished' state for the older one relative to the state of the newer one(s).

Keep in mind, I no longer make that many 'patches' I make what I like to consider 'apps'(the difference being: apps contain full and extensive feature-sets/uses, they 'apply' to a larger set of performance considerations rather than a specific use which a patch might specialize in(at least according to my own experience only; as limited as my experience might be relative to other greater veterans...)). And also, the 3 conditions I listed above are really only according to my own experience of the apps(I make apps for myself first and foremost and then hand them out to anyone else interested, rather than making them for people at large and then finding my own specific way of using it... unless, of course, i'm working for someone else in which case, the few times that has happened, it's all up to their direction (and how happy I am with any compensation given in exchange)).

Hope that helps. All the best in this very interesting survey!

Actually, I don't like calling things finished :) I like to think that everything I do is imperfect and has lots of room for improvement.........some patches start off going in one direction, sort of plateau at some point, then start off in another direction; and I don't usually think of them as different patches, just little idea-journeys that produce interesting things and then evolve into something else.

I don't do any performing with max (yet...) so I don't have any particular incentive to build an entity that does particular things; whether or not those particulars are specific or vague.

I tend to call something "finished" when I get bored of the idea :P Up until that point, whatever it is is probably in a state of flux, but being pedantically tested and messed with to make sure it works properly before my requirements change.

I just like the exploration, maybe I've got creative ADD.

i am a tester.

2000+ abstractions should give you an idea.

and: never change a running system, for example mac os 9.

-110

I guess I live a bit more on the edge. Any patch that has seen more than one performance or installation becomes a living record of last-minute tweaks or solutions to problems that would happen onsite. Eventually, I figure out the parts that always need to be changed and I spend time to make a proper UI for it, but I'm generally better at adaptation than planning.

FWIW I always start out being (or trying to be) more of a tester but the last minute tweaker in me always pops up @ ...the last minute!!

ya, i think what spectro said is true for all. Max is not a finished product, therefore, it's a pretty necessary thing to be a tweaker at some point. I think we're all forced to 'live a bit more on the edge' by it. Living on that edge is probably an easier thing for people who are more experienced at it, therefore not really an 'edge' persay but rather a calculated risk(i know what could possibly lead to crashes or simply cause slower performance and i stay away from tweaking that kind of thing last minute (example, huge pattrstorage organizational changes, etc.))