[PD] software license for pd general patch?

[João Pais]

>> when you put out a new version of gridflow, there are several replies
>> from people that try it out, etc etc.

that point was more about the "general interest of the comunity" argument.  
in any case it's good you don't get that many complaints, which shouldn't  
mean that there are less users.


> Generally speaking, pd-extended made a huge difference in the history
> of pd-list, that caused a large reduction of "can't compile" posts, and
> this decreased the apparent activity of pd-list, because message-count as
> a measure of community activity is about as meaningful as counting how
> many lines of source code. (well, perhaps a bit more on average, but  
> there
> are simple ways to make it lie.)

exactly, that's a great merit. that's why I always ask someone who hasn't  
put their code in there if he wants to - it makes it much more  
centralised, and easier to access.


>> When I put my abstractions out, I get no reply at all. I guess it's safe
>> to say that there is more interest in the pd list for gridflow than for
>> some small abstractions, right?
>
> Hey, I thought that they were big abstractions, aren't they ?

this isn't part of my abstractions (at /extra/jmmmp), it's a "full  
program". it doesn't come with pd-ext, it's on my pd page. I would say  
that it's as big as all my abstractions together, but never measured it.


> Well, despite its potential far-reaching consequences as a tool for
> designing pd patches about anything, gridflow is still almost only seen  
> as
> a video tool you only start to look at when you get tired of trying to do
> something with GEM's [pix]. That somewhat limits the potential of it. Is

the next time I try to update my object list (you might know the "short  
version" from the floss manual, the original is an xls file), I would try  
to include a list of the gridflow objects. I had started talks with a  
friend that does data visualisation to make a patch to automatise the  
listing, but he bailed out. so I have to do the work by hand.


> there something in your abstractions' concept, and the way you write  
> about
> them, that limits their potential because most of its potential users
> don't recognise the contents of your summary of what it's for ? I don't
> have an idea what a click-track is, but I bet I could find a use for it
> anyway.

my jmmmp abstractions are very simple utilities, most of them to spare  
some repetitive code (snaps~, metrum, ...). therefore, it's very simple to  
say in one line what they're supposed to do. of course, that doesn't stop  
anyone to go there, grab the code and use it somewhere else.
for click track look http://en.wikipedia.org/wiki/Click_track. in case  
you're interested in them (if you don't want just to do 10m of 4/4), then  
my patch might be useful for you. or if you have any  
complaints/sugestions, I always want to know how to do it better.

but that goes back to the initial point: this program was made for persons  
that play complex music from score, and can need the help of a click track  
system that lets them reherase/play in concert. that's why I said in the  
beginning that in this list almost anyone fits into that category, and I  
won't try to push it into them, just because I find it a useful tool.