[PD] software license for pd general patch?

[Mathieu Bouchard]

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