On Tue, 6 Jul 2010, João Pais wrote:
there might be, but a) I have no interest or purpose on doing it, and b) there wouldn't be any really useful abstractions coming out of this. in fact, it might even make my programming slower (because I would have to manage x programs instead of 1), and the whole thing more confusing to manage.
Well, there could be some kind of variation on the idea, such as bundling some things together to save some time and hassle. Generally speaking, never distribute too many things at once. This is why people make libraries by author instead of by topic : it's a matter of source code management, bundling management, etc., so that one person only has to install one library, or at most, a small number of large libraries, rather than a large amount of small libraries.
how does this auto generation works?
See that the file is loading another source file (on its line 3), which you can find at http://gridflow.ca/svn/trunk/doc/locale/english.tcl ... the only important lines are the ones that say "say". (if you want to know more about this, I will tell you more).
Then in the main script, the lines that say "puts" add commands to the pd file, such as object creations, comment creations, canvas header, ... The rest of the lines are there to figure out where to put the objects, how much spacing to put, and whether there are any objects that need mandatory args or that absolutely need to be represented by direct hyperlinks to helppatches, etc.
I would like to keep updating my list, but in an automatic way.
I do write all I can in the ChangeLog, though sometimes there are omissions (usually in case of classes that were originally meant for internal use, but there are other reasons sometimes).
It might be easier to keep it updated automatically, but it depends what you want to write in that file. If it's essentially just the same contents as the GridFlow Index pd file, then I can generate the file you want and bundle it with every version of GridFlow.
I was thinking of an approach of something that goes through the folders and makes a database out of the files(objects) that it finds.
I have a script that browses through GF source code and abstraction folders and compares it with the doc index and helppatch folder, to figure out anything that might be missing. That's http://gridflow.ca/svn/trunk/doc/find_missing.rb and as you can see, I tend to be quite often in between Tcl and Ruby, which doesn't quite help me making things unified. If we keep a version of your file in the GridFlow repository, I could have find_missing.rb also check for needed changes in your file as well, if you have any reason to make "manual" changes (that is, only "semi"-automated).
that's the same thing. then you'll be loosing time by typing a score which has always the same rhythm/tempo. better put a metro with a mod, and you have it. the music for which the program is made is more like:
Ah yeah, that's a good example score-wise.
But then, the problems with such scores are things like the flirting too close to the "uncertainty principle" (tempo is used for a time too short to be really felt) and the "consonance" of tempos (13:10 can be quite hard to distinguish from 4:3 in many circumstances, just like such ratios of frequencies can). But you picked extreme scores, and I can see very well how pieces of much lesser complexity than that can be a lot more followable by the ear _while_ at the same time having much of a use for a complex programmable super-metronome.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801