[PD] Patch Tracker WAS no reverb or delwrite~, delread~ working with -nogui onUbuntu 10.04

[Dan Wilcox]

I like the fact that you're not afraid to ask these questions and don't gloss over the details. I have actually been spending some weeks at work looking into these kinds of issues in how we as a creative community (at work) share information and collaborate.

On Jun 5, 2010, at 9:29 PM, Mathieu Bouchard wrote:

> On Sat, 5 Jun 2010, Dan Wilcox wrote:
>>>> Also endless discussions over help formats seem like such
>>>> trivialities in the grand scheme of things.
>>> Then tell, what do you suggest that we do ?
>> Use help patches directly.
> 
> How directly ?!... I don't understand at all.

I just meant help files in pd patche format as opposed to XML, html, etc. 

>> We should choose the best among the existing formats and use it.
> 
> Yeah yeah, but how do you do that ?... who is we, and what's the decision process, what happens with the people who still don't agree, etc? Those are routinely-avoided questions...

Routinely avoided, exactly!

Who helps makes the decisions and arbitrates things? By we, I mean Miller, Iohannes, Hans, you, externals authors, and anyone else who wants to join. Naturally, it falls to those most active and interested. I for one want to see Pd continue to evolve and be relevant as I plan to use it professionally for years to come.

What's the decision process? I'd say the problem should be identified as well as possible requirements, a time frame give for it's resolution (important!), proposals for solutions made, the pros and cons of each listed, and a solution formulated from the strengths and weaknesses of the best proposals.

Here's my try for this case:
problem: the help system is not consistent or effective in how information is formatted and displayed
possible requirements:
help files as patches (more intuitive)
each object's arguments, inlets, and outlets should be clearly explained
meta information should be encoded to allow a keyword searching system to index help patches
each library should contain the author's contact information
time frame for a resolution: 3 months

It's important that we all agree on the problem and the time frame for it's solution. We should try not to find the most optimal solution, but prefer a pragmatic approach and choose the best available.

What happens when people don't agree? Well, I suppose we can't do much more then try our best to compromise ... this being an open source, volunteer community. Unless we agree upon a single arbiter or  "grand dictator" etc as some other projects have done, we have to *listen* to each other and be prepared to work together toward a possible solution. (Forgive me for "preaching to the choir".) I am very positive we can all agree upon reasonable compromises and *move forward* through well thought out proposals, explaining our ideas in an objective manner.

My whole point for complaining that "we quibble about the details" is that I feel we could achieve quite alot of constructive growth if we can decide upon and implement core elements such as help patches.

>> Surveys from non-technical users
> 
> technical users are also users.
> 
> the perspective of those writing the help files should count at least as much as those who only read them. After all, for help files to be read, they need to be written first. (Because of the number of writers, this means that each writer ought to count more than each reader).

Fair enough. My point was more that the writers should not forget who their intended audience is and should choose ease of writing over readability. The easiest solution from a writer standpoint could be that readers should refer to help in the source header files, but of course that's not practical ...

>> and voting may be required.
> 
> You know, if there was a vote against the GridFlow format, I would not switch to a different help file format. The only format my helpfiles will migrate to, are ulterior versions of the same format.

You are right. Voting is not a good solution. However, neither is the position of "my format or the highway". However, I suppose it was a mistake to say that we should all have a  graphical template to follow and to change all existing help files to it. If I was in your position, I wouldn't want to migrate without a good reason. After all, we all patch differently, we use PD because we love the freedom in how we can work.

One possible solution would be that we can at least agree upon what help patches should contain (argument lists, inlet/outlet descriptions etc) and not bother with exact format of "this text goes here, this canvas header is this big and this color,  etc". I think that would be a good improvement on the many help patches that contain the object, a slider, and a single sentence saying what it does. Then the orphan help patches are improved from there and externals authors update.

I know this is what you guys were already discussing and work has already been done, but I'm using this issue as an example for how we collaborate.

>> I think the input from a few workshops is far more useful then developers squabbling over which canvases and layout look best.
> 
> The automated layout system of GridFlow was designed as such in reaction to people squabbling over which canvases and layout look best.
> 
> If you know those meetings, you know that it wasn't just a developers' meeting.

I hope it wasn't a meeting like :

I remember making the point at PdCon07 that the help browser was confusing to use and I couldn't find the information I wanted (help, references) without going through each folder. A number of people gave me a dismissive look and I don't remember the responses I was given, but they were more along the lines of "it's all there, can't you see?". I got the feeling that since it wasn't a problem for those that had learned the locations of the objects and their names, then it wasn't a problem worth solving. That it was my fault and I should just read more. This did not and still does not sit well with me.

>> Also, the pd gui rewrite offers possibilities such as a menu option to automatically create an svn diff of the current patch.
> 
> where's that feature ? I don't see it anywhere in the menus.

As far as I know, the pd gui rewrite adds the ability for custom tcl/tk snippets through the command menu. This could be just a tcl call to svn diff.

>> That live demo aspect is what I think makes it so intuitive. As you suggest, the basic format is obvious versus XML, html, etc.
> 
> If it were so obvious to everybody, then there would not have been a need for another thread about it (on the pdmtl mailing-list) in reaction to news of a (then upcoming) pdpedia meeting. the thread(s) was short and one-sided : it seems hard to get proponents of pdpedia to answer any questions in public...

Good point. If discussions are not public, we are not obligated to both share and defend our ideas or viewpoints. In doing so, one has to really give thought into what one is doing. To me, it's the difference between to stating an idea then coding it directly and stating an idea, researching it, presenting it others, getting feedback, and then coding it. If we don't collaborate effectively, I feel we waste effort individually.

Also, we as a community look less active which, for an open source stand point, is not good.

>> You don't have to tell me this.
> 
> And you don't have to say things like « will this ever happen for Pd? ».

Fair enough. Forgive me, but I still felt it needed to be answered.

--------
Dan Wilcox
danomatika.com
robotcowboy.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100605/5c8b46fb/attachment.htm>