General issues about redesign Pd Official Documentation

[emviveros]

This issue is related to an effort in create a pattern design for Pd Documentation. The initiative is started because Documentation Rework issue started by @barnabywalters.

To centralize the issues here I rewrite below some discussions that have already started that I thought were important:

@emviveros says

Particularly I think the @barnabywalters idea of start to discuss a unified new model of documentation can be helpful. It doesn't have to be done in a hurry and updating little things in documentation as Porres has been doing is necessary to make Pd better for new users right now. But despite @porres' efforts, we still need better documentation.

If we are able to reach a consensus on the best way to document Pd things, the work of creating documentation should be much lighter for everyone, in addition to making life easier for those using the documentation, since navigating in the help patch will always be similar.

I suggest:

1. start by answering what is the profile of the Pd user and what he needs within the documentation. Who knows we can start a topic on the Pd list. There are many Pd teachers, and users of course, who can provide very useful insights.

2. With this information in mind, start thinking about an organization that contemplates the maximum possibilities raised in the previous step. It is possible that we need to create specific online documentation on the Pd page, which has as a positive point the possibility of translation into multi-languages.

3. Document.

@porres says

@emviveros I agree that bringing this to the Pd list can be better to have more input.

@umlaeute says

you might start by not assuming that "the Pd user" is a white male academic.

@emviveros answered

hahahaha!! Yes! Please!!! Maybe we have to extend the answering to Pd Facebook Groups. Maybe there we can expand the scope of the research.

Looking for documentation of softwares created by people who do not understand themselves in the scope of white academic men can be another possibility.

[porres]

Ok, what are the general issues? I can think of one:

• a way to have a visual cue in the patch that the data is coming out.

Sometimes an atom box/GUI is not enough. Unless we have an object like [else/display] (similar to [PRINT] from extended), we have to rely on [print]. I think adding bangs is a dirty hack. For things like floats, maybe we can add a flashing parameter/option (like in [bng]) for when an atom box receives a float. Atom boxes are now highlighted when you select it and use it, we could have a thicker line for a moment as a way to 'flash' and say it received data. But then, this would be yet another request.

[porres]

this would be yet another request.

done https://github.com/pure-data/pure-data/issues/1321

[mscotthouston]

I would love to help with this project. I have been using Pd since my undergrad days over a decade ago, and since then I have taught it with undergrad students (complete beginners to both music making and programming). I have first-hand experience of what it's like to learn Pd with no formal training in computer music, and I have first-hand experience of what it is like to teach Pd to a class of beginners.

I can't fully answer the question of "what is the profile of the Pd user?" but I can say this:

• Not all Pd users are academics or have any formal training in western music practice and theory, in particular electronic music practice and theory. Furthermore, not all Pd users have any formal training in programming, math, or any of the other disciplines which Pd encompasses.
  • If the documentation is going to be using technical terms from these disciplines (and I think it should!), they should be used consistently and they should be well-defined within the documentation.
  • As much as possible, there should be interesting and interactive examples included in the documentation so that a new user, who may have no idea what, e.g., "sequencing" means, can see/hear what that concept means when put into practice.
• Not all Pd users speak English as a first language. Many Pd users will have little to no English.
  • Anything we can do to make the documentation more accessible to non-English speakers or English-as-a-second-language speakers, without thereby reducing the accuracy, depth, and breadth of the documentation, ought to be done.
    • Leveraging the Graphical aspect of Pd is one way to achieve this. And this is why I agree that it is a good idea to include visual feedback in example patches as much as possible. New users may not know to check the console. They may not realize that the console even exists. They may have no clue yet how the words in the console correspond to the patch.
    • Making it easier to localize the documentation would also be a huge benefit. I agree that online documentation would greatly aid in this.
• Pd users are diverse in how they process information, process data from their senses, even in how they use and interact with their computers.
  • The documentation should be made as accessible as possible. Sheri Byrne-Haber's very recent book "Giving a Damn about Accessibility" (2021) is a great resource for thinking about this.

I think a lot about the lecture (available on YouTube) that Miller gave ten years or so ago where, at the beginning, he talked about how computers were designed and built to be really good at doing calculations for finance and war--accounting and launching weapons. I love Pd for how it leverages that strength but bends it away from accounting and war and towards the much greater and humane work of research and art-making. When my rural and poor undergrad students were first introduced to Pd all they saw was an arcane piece of software that seemed to force them to do lots of math. They weren't yet able to see how that was actually powerful and liberating! The documentation should strive to make this possibility more apparent.

[porres]

Unless we have an object like [else/display] (similar to [PRINT] from extended), we have to rely on [print].

I'm now proposing that as a separate request in https://github.com/pure-data/pure-data/issues/1325

[designerfuzzi]

Just try not to distinguish user experience level at all. What is more interesting is if someone would want to know more about a detail of any object it could easily be found without overloading a software with zombie documentations. What makes even more sense is if the documentation for each object is a community effort instead of another experts point of view creating more zombie documentations. Which means a focus could also be to properly document stuff in code, so DocGen could generate properly different levels of depth up to the full depth of trying to know everything about a specific object. Because as soon you start making judgments what has to be known for whom and what not when reading the docs you are in fact starting to shift the focus from do with objects what ever you want to what you have to use them for from a creators point of view. The whole magic of pd is, this is not a given fact. So trying to hide distinct levels of depth in docs is evil.

There are a couple of things that are not very well documented at all.. just like it was never very good documented in other patching software environments.

like data flow.. right > left, top > down. documenting this properly would also explain why pd files contain coordinates. and that is just one example.

So if there are different user groups at all then it are some of the following.

people who look into code from command line or workbench (possibly even to learn C) people who look into docs and start programming files after reading. people who look never in docs and know how to drag and drop and download things and have healthy ears or eyes. people who look into patches from patch environment side only people who look into patches from a different environment, like a third party software. people who look into code not knowing C, C++ at all but about Javascript, maybe python and similar looking for a web-app people who know C, C++ and more and develop what they think is missing and read, understand and test code like snacks but have to relay on patched examples called documentations.

They all have something in common. The informations they relay on has to be correct, short, expandable, accessible and well structured as possible.

Because when you say documentation, you often mean patches in patches without a depth structure. Where informations lay beside each other without explaining the relation ships as they are a graphical feature.

[porres]

just wanna say we really need to give more love and attention to https://puredata.info/

[porres]

Another issue is having a quick reference for message types for each object and things like that. An idea to have a reference for each object as html (like max) is also interesting. We could also have it in a subpatch for the help files; here's my first rough draft on this.

[Lucarda]

An idea to have a reference for each object as html (like max) is also interesting.

This is an approach to have html reference and translations.

https://lucarda.github.io./

https://github.com/Lucarda/Lucarda.github.io

[porres]

Nice to have you onboard @Lucarda! Great stuff you have there. Just let me see if I got it straight, you have a way to automatically look into the source and generate these html files?

Now, as it is, I'd call these actual 'help-files' and not a 'reference'. For the reference per se I'm proposing something like max's and somewhat in the direction I'm heading here, as a way to quickly reference to what message types it takes, arguments and stuff. The help files are Pd patches with examples on how to use the object. The reference can be an html file and also live on the internet.

Now, I wasn't thinking of the help files examples being there too... but... why not? Your stuff is great and the best thing is what you're proposing here to add translations, and it'd be great to translate the help file examples. But what do you think about my 'reference' idea? I'm also proposing a [pd reference] subpatch as part . On your proposal, we could have both help file examples and a quick reference.

[Lucarda]

But what do you think about my 'reference' idea?

I like it and it won't hurt anybody. I know this is a lot of work but you are well known for entering in your super-mantra-patching power and have 500 help patches edited in 2 days. :)

---

Answering about the html (may be this is later moved to another thread). EDIT: done moved to pure-data/pure-data#1326

you have a way to automatically look into the source and generate these html files?

Unfortunately not. the procedure should be:

• put the title inside a <h2> ... </h2>

• copy the text of each pd comment inside each <p> ... </p> (one comment, one <p>)

• try to do ASCII art of the objects and messages inside a <pre> ... </pre>

No images here as this is no translatable. Just text. If the help patch has sub-patche(s) add like:

<h2>[pd reference]</h2>

<p> blabla </p>

and so on until all sub patches are covered in the same html file.

The help files are Pd patches with examples on how to use the object. The reference can be an html file and also live on the internet.

We might mix them in the same internet file.

[emviveros]

@mscotthouston says

Not all Pd users speak English as a first language. Many Pd users will have little to no English.

About that I reinforce the great of html documentation, online and shipped with Pd for offline context.

Not all Pd users are academics or have any formal training in western music practice and theory, in particular electronic music practice and theory. Furthermore, not all Pd users have any formal training in programming, math, or any of the other disciplines which Pd encompasses.

It can be achieved through dedicated tutorials to, which document how to build a specific "device" and redirect the learner to another tutorial like "Making abstractions" ?

• Making it easier to localize the documentation would also be a huge benefit. I agree that online documentation would greatly aid in this.

We can think in a Welcome to Pd patch or popup, which will direct newcomers to right documentation. [ref]

[designerfuzzi]

directing newcomers is nice but as told you will have splattered docs, after a while some will be outdated or the link is broken then. I like that ideal world approach but the past tells its better to be prepared for changes. What about expanding pages?

[emviveros]

Yes until have a newcomers welcome we need to ever redirect newcomers to official Pd pages like puredata.info where we have splattered and updated docs mapped and in understandable way disponible. Centralizing it in one page we can maintain with less hassle without having to take responsibility for updating outdated content

---

[EDIT] disponible = available hahaha sorry... my spanish took me by storm

[emviveros]

@porres your first draft is almost perfect in my view.. I ever think about colors importance, but now I'm thinking in acessibility, and this layout is simple enought to avoid some of them without being beatiful in vanila way.

@Lucarda I reinforce @porres in to be happy that you are also facing this. I would like to share this: http://www.cooperbaker.com/home/code/pd spectral toolkit/ . This have some things like disponible source code to reading, and is simple enought to think in a vanilla like beatify or not beatify..

What do you think a possible Max Reference like that should be made should contain? Do we already have the maturity to think about these aspects without neglecting the discussions about accessibility mentioned above?

[designerfuzzi]

http://www.cooperbaker.com/home/code/pd%20spectral%20toolkit/

[porres]

Yes until have a newcomers welcome we need to ever redirect newcomers to official Pd pages like puredata.info

Pd already points to puredata.info under the help tab

where we have splattered and updated docs mapped and in understandable way disponible.

well, like I mentioned, we could give some love and attention to puredata.info and update it. I feel It still represents Pd extended too much

[emviveros]

Pd already points to puredata.info under the help tab

Yes... But not in a compreensible way for newcomers. The welcome to pd idea can be a tutorial which point and explain how to access documentation. Maybe here will be good a tcl tk pop-up to be posible multi language support

[porres]

A tutorial, a way to access the information, a link to puredata.info, we have all that and we have tons of things already. Let's hold on for a moment and take a breath before thinking about more of that and a popup here or there.

Also, do you have a reference of the way some other application works for this. What are you thinking? MAX? Ableton Live? Do You want something like a "Welcome to MAX" aka Max tour, which is also found under help menu?

Well, a "quickstart tour" could be nice, but that's conceptually a tutorial for newcomers finding their way in.

Now, try to think yourself as a newcomer, someone who opened Pd for the first time. How do you expect this to hit you? Should it be a popup with a "hey, you're opening Pd for the first time, do you want 'tips'? A 'tour'? And then we can have a checkbox for "no, stop suggesting me this, I've been using this thing for over two decades, I'm fine"?

Now, what if you don't have that, as we don't. Say you're new to this and you know nothing. What would be your intuition to look for something like this?

The 'About Pd' has some info already that points to quickstarts, tells you where the documentation is, links to puredata.info... well, usually this section in sofwares will just tell you the version and lincense/copyright. Pd goes further, which is cool, but we can revise this information and also put it somewehere else.

I think people who open software for the first time usually check the 'about software' tab. At least I do, but let's say you don't, where else can you go?

Help Menu... anyone who opens Pd for the first time and are clueless can find this tab and click on it

I mean, not sure if we need a popup, in a sense that if we do not provide it, people will never be able to find it. I'm fine with it, but I just want to organize this plan and start with first things first. So a pop up can be saved for later.

I'm checking processing. Under help, they have this:

So, there's a 'welcome to processing'. So I guess we can add the same, a 'welcome to pd', which can later be a pop up for first timers. And this can open a 'mini quickstart welcome to pd tutorial for dummies', as a patch, with links and stuff...

And the most important stuff is actually deciding what this stuff is, and also considering we already have this 'stuff' around. So let's focus on the content, on what we have, what can be reorganized, what can be updated.

So, yeah, before thinking about adding yet more noise. What is actually wrong with what we have already?

One can easily open the 'Pd help' option in the Help Menu, which opens the 'Pd Documentation' hmtl, which quite quickly also points you to some tutorials around. What's wrong with that? I have criticisms myself, I'm not challenging you to find problems, but I want to stimulate people to this kind of discussion, because it seems more to the ground, more concrete, objective and more fruitful...

brainstorming can be fun, but also time consuming and counterproductive.

Back to earth, is the 2.control.examples easily found? Is it a good tutorial for newcomers?

As soon as we pinpoint changes to what we already have, we can start fixing it by working with what we have, and later on we can add more stuff, that's my plan...

[designerfuzzi]

Ableton's approach is nice, an unhidden tiny box on the lower left telling you what you need to know. Featuring informations similar like tooltips work.

Max help sites is massive.. can't even start talking about it.. the only thing i remember is the yellow circle you can click to get to know more and from there you can click the tabs to more info or external links. Basically it is the extreme overloaded side from PD in color. For beginners difficult to navigate.

by the way.. in Xcode: Cmd+Ctrl+Click on items/words routes the user to declarations to read, The very right side is reserved for detailed read up in users language and from their links into the documentation as popup with element grouped by frameworks/language/theme opening subpages on the right of the popup. Pretty straight forward not super difficult to understand what to do to get informations..

So if i could re-invent the docs of PD i would make the browser more interactive by extending it with a object list where clicks open pages on the right.. and who wants to jump to pages of other PD elements clicks one with CMD+Ctrl+element. When you get lost, click a back button. Not like it is the moment in PD where you have to close sometime even the same elements pd-file docs twice and accidentally close your own last work too..

[designerfuzzi]

So to speak: i am missing breadcrumb path feature that guides users back to the root if they got lost in info

Breadcrumbs paths have something magic. They force you to structure content.

[emviveros]

@porres says

Let's hold on for a moment and take a breath before thinking about more of that and a popup here or there.

I think in simple things.. Nothing like animations, pointing you to menus.. That's too distant of vanilla things and how the community has done everything. If the popup idea persist, it can be like this:

And the two links point directly to specific documentation. Maybe "Basics" to html doc embedded with Pd and "How to Learn" to https://puredata.info/ specific page with the list with updated tutorials and warnings for the issue of outdated tutorials.

In favor of using popup, we have which the probability of a newcomer of any age know the popup communication workflow is higher, and against using popup we have probability of a anyone knows the popup nightmare communication workflow is higher.

Now, what if you don't have that, as we don't. Say you're new to this and you know nothing. What would be your intuition to look for something like this?

Get away. People expect people language, in their native language in a familiar way. Only show a list can be very uncomfortable, but it will become lot useful after the first meet and there is only to remember where the things were.

So, there's a 'welcome to processing'. So I guess we can add the same, a 'welcome to pd', which can later be a pop up for first timers. And this can open a 'mini quickstart welcome to pd tutorial for dummies', as a patch, with links and stuff...

Yes. Totally agree with this way

So, yeah, before thinking about adding yet more noise. What is actually wrong with what we have already? Much of the links we get up in this discussion already exist. The problem in my point of view is how to present it which is insufficient to include a wider range of interested users. Listing:

• What you can expect from Pd
• How to search and ask information about Pd
• Update info in puredata.info (the most critical part
• Default layout for all help patches
• online/offline References (need more discussion about what we can put in it)

Back to earth, is the 2.control.examples easily found? Is it a good tutorial for newcomers?

I think it is more about Pd syntax than tutorial for newcomers. For that we need something less expositive, like: 1) Hello World:

• open new patch
• press ctrl+2 and write hello world
• press ctrl+1 write print, connect them,
• press Ctrl+e and click in the message [Hello World(, see the console window.
• Congratulate and explain the concepts evolved.
• point to specific reference session get the idea (simplified exposition about how to patch, not all)
  • get the idea can point to 2.control.examples 2) Make some noise
    • tutor the construction of the patch
    • point to specific reference session get the idea (simplified exposition about synthesis options, not all)
    • get the idea can point to more complete references 3) Simple Controlerism
    • tutor programming some MIDI controlerism
    • point to specific reference session get the idea (about some simple structures of control)
    • get the idea can point to more complete references (maybe 3.audio.examples)

---

[EDIT]: Something I see in 2.control.examples I forgot to mention, when I open the first patch, 01/PART1.hello.pd, it opens upside Pd Console window. A newcomers which click in the message will don't see anything happening unless have the divine idea of moving the window you’re using to see what’s behind.

[emviveros]

@designerfuzzi says

Ableton's approach is nice, an unhidden tiny box on the lower left telling you what you need to know. Featuring informations similar like tooltips work.

Yes this can be nice to consult, but how we can implement something like this in Pd? Is very difficult to redesign all Pd interface, it can be very heavy for developers to create it and mainly for actual users radical changes it can be very annoying. But we can map something we don't realize yet. What information you miss? Can you think how we can make it disponible with less existing users harshness?

by the way.. in Xcode: Cmd+Ctrl+Click on items/words routes the user to declarations to read, The very right side is reserved for detailed read up in users language and from their links into the documentation as popup with element grouped by frameworks/language/theme opening subpages on the right of the popup. Pretty straight forward not super difficult to understand what to do to get informations..

Are you thinking like programing IDE (like VSCode) popup with references about the method writed? Intellisense stuffs? I can think it great if we have the reference subpatch infos in a popup when called with mouse click and some key on the object. It can be much time saver. My point against it is only how to implement it without duplicate the information, because it can quickly become a mess with mismatched references between patch help information, html reference and keyboard shortcut and mouse click popup.

So if i could re-invent the docs of PD i would make the browser more interactive by extending it with a object list where clicks open pages on the right.. and who wants to jump to pages of other PD elements clicks one with CMD+Ctrl+element. When you get lost, click a back button. Not like it is the moment in PD where you have to close sometime even the same elements pd-file docs twice and accidentally close your own last work too..

I think we can achieve this with the html pd reference. You search for object and you wave it. A list of the objects categorized like help-intro.pd be a good help to find too:

Or better think about what we need to put in the new html Pd Reference to organize it using breadcrumbs to organize.

[emviveros]

@porres says

As soon as we pinpoint changes to what we already have, we can start fixing it by working with what we have, and later on we can add more stuff, that's my plan...

Exactly! I think your first sketch of patch excellent. I vote to go in this way. In the ideal world, it would be best to start with 2 or 3 objects with different needs of patching. Something simple, like [float], something more extensive, maybe [expr~] or better [pd ] subpatch and something more hard to understand, which need to comunicate more with text against in interactive way, but try to make interactive, like [choice]? Once we have this 3 types of help patches in the new layout, submit to feedback of the Pd community.

About the html Pd Reference I think we need more discussion about what it will be.

[Lucarda]

About the html Pd Reference I think we need more discussion about what it will be.

no need for html reference in english only

I think there's no need for html reference in english only. No need at all. The only interesting about the html thing is that it can be translated. (.pd files can also be translated but we can think of that in parallel or later).

While a nice looking and professional html can be done we should not go that way.

We should go for the simplest and minimal html we can think.

To extend why we are not going the "nice and professional html":

html can get really complex and unfriendly to edit. For example go to https://docs.cycling74.com/max8/refpages/number and right-click on the page and select "View page source".

How would I ask you to translate that to Portuguese?

Now go to https://lucarda.github.io./en/adc~_dac~-help.pd.html and select "View page source".

Did you get what has to be translated?

I'm thinking the htmls we are going to handle should ideally not include image files and the fewest links possible.

I'm thinking this because as I said above I'm only biased on translations.

[porres]

it would be best to start with 2 or 3 objects with different needs of patching. Something simple, like [float], something more extensive, maybe [expr~]

How about this?

As for the reference, [expr] has an online manual that I think we can update and include as part of Pd like the [slop~] html reference, so maybe no subpatch for that, right? See https://github.com/pure-data/pure-data/issues/1327

[emviveros]

@Lucarda says

Now go to https://lucarda.github.io./en/adc~_dac~-help.pd.html and select "View page source".

Yes seems easy to translate.

I'm thinking the htmls we are going to handle should ideally not include image files and the fewest links possible. Avoid images encumber the effort of improve access to Pd documentation. But I'm not satisfied in overload the documentation with one image per language. I think in workaround... Is so crazy, but perhaps it can work...

we have a pd plugin which convert a patch to SVG file. Is possible modify SVG files with javascript. Maybe we can write an automation to analise pd patch and modify the text inside #X text in patch file. Perhaps we can generate json files which can be added per language and edited. Need some sweat... I will think and test it idea better...

[Lucarda]

@emviveros says:

Avoid images encumber the effort of improve access to Pd documentation. But I'm not satisfied in overload the documentation with one image per language. I think in workaround... Is so crazy, but perhaps it can work...

I don't think it encumbers the effort. You are seen the objects and the connections in the patch while you have web-browser window with the translation at the other side of the screen.

[porres]

you know Pd seems to run now on web browsers right? Just saying it... ;)

[porres]

I actually don't get what this thread is about... is t about redesigning the help files? It a general discussion about Pd's documentation?

It seems ambiguous and more of a Forum thread... so, I don;t know, maybe we can split into different more localizd thread, like 'Pd Manual, 'Pd Help Files redesing', 'Pd Documentation'

[porres]

So, yeah, created a new issue for general documentation issues https://github.com/pure-data/pure-data/issues/1331

[porres]

new thread for the help files redesign https://github.com/pure-data/pure-data/issues/1332

[emviveros]

Thnx @porres for organize this issue which became more a: general issues about redesign pd official docs.

I dont know if rename the issue crash the url link outside github. If not I'm happy in rename it.

[porres]

I dont know if rename the issue crash the url link outside github. If not I'm happy in rename it.

you can rename it

[designerfuzzi]

I may have to tell first that i distinguish PD as unit to be able allocate and calculate buffers full of pointers and values - from tcl/tk as workbench. So acknowledging this fact and what ideas came up here does lead me to a couple of assumptions:

A) PD documentations suffer in general from its tcl/tk workbench limitations. HTML will never solve this, html is an external source to go to or some of the sites are stored in the app folder to be accessed from a Webbrowser.

B) Multilanguage support is not an PD problem. It is only a linking and link scheme problem. Because every content can be written in different languages or even extended by translations later on and just need a hint which one (and a fallback if language is not available) is presented to the user.

C) tcl/tk || PD can be extended to support a search field and output accordingly routing to content or opening a file as is the moment with all subpatches that are clicked. To hook up input from the user there are several things existing in PD with tcl/tk already . 1) when you type commands in a object box, the input gets verified to start allocating objects 2) or msgs can be parsed on specific objects. So PD is capable of acting on users request for sure. 3) or the Help menu object browser or object list offer a layout that can be improved without disturbing the whole help system i think.

Sidestory: i am thinking what if there would be an PD object/external that can parse commands and open PD files or outputting a link scheme/ array of links by similarity of typo / breadcrumb.. and another one taking such output and switching content instead of opening new windows. Because i think the main problem is not directly missing content or language, the problem is accessibility from within a patch while you work and learn. As i remember my first days in PD.., i got always lost in PD files trying to make sense of whats happening, super short comments telling things that make no sense, windows popping up that don't show what i look for nor show what i can search for or even worse - hiding objects i need to know to make things work.

So by "browsing" help files or creating content with the help of html we always refer actually to the browsing experience to be able to go back from where you started and also to link back to where you came from or to go to.

Here just as inspiration the docs browser from xcode.. On the top a search field to browse and get results and auto completed links On the left structure of frameworks, objects, subobjects, message types, On the right content with fixed structure what is declared, where its valid (hint: vanilla), what is needed and some words to inform what is special with the thing you present. plus extra links where to go from there or even examples to download. Looks huge, but is basically a docgen generated output based on comments inside the code of those objects.

So PD is not far from that, but as told extremely minimalistic and does not support linking without "physical" folders.

[porres]

As i remember my first days in PD.., i got always lost in PD files trying to make sense of whats happening, super short comments telling things that make no sense, windows popping up that don't show what i look for nor show what i can search for or even worse - hiding objects i need to know to make things work.

Can you give us objective and current issues you find on it these days?

[designerfuzzi]

Also interesting that externals get more visual space in the "help browser" than the actual help at the very top with "Pure Data". So the idea was there already but got driven away a bit..

[designerfuzzi]

The most revealing option would be to film a screen session of someone using PD for the very first time. So a welcome box would be a massive improvement. just to tell a new user where to find the main window, dsp switch, what it is for, where and what the command line is for, when does stuff show up there, where to search for objects, how to place them.. All this is basically in youtube which is where i got my first steps from after i gave up on the UI the first trial. Once i was addicted to try again i started searching in PD for tutorials and we know what we have there.. we have those PD files using subpatching to browse to other subpatches.. after some read ups you have to close them all and start again digging in..

So if we could extend the "help browser" with a right side area that presents the content of what is clicked that would be a huge step forward in my eyes. And from there examples to open to start dsp and hear what going on...

[porres]

All this is basically in youtube which is where i got my first steps from after i gave up on the UI the first trial.

It's also in the Pd Manual... and the included tutorials/documentation, no?

[designerfuzzi]

I can't even tell you.. At the peak of my journey getting more info about PD i found PDF's from some studies about libPD that dragged me much more in than the PD workbench itself. For that it's maybe good to mention that i developed Ableton Link connection and graphic engines for Quarz Composer for live graphics years before i discovered PD to do audio stuff. Where in Quartz Composer you had an object browser that had links to more infos and links to examples being part of each plugin/object. There was a manual also, but basically just telling how the signal flow is going and macros (subpatches) are done, how inlets and outlets are renamed and exposed. There the flow is from left -> right, top -> down and positions of inlets & outlets have no meaning at all, it works in frame rates rather than buffer cycles. So i came with some pre knowledge.. I was even thinking to port PD into Quartz Composer plugins.

[porres]

Sorry everyone, this thread is just too crazy and not objective, so I'm closing it. Some of the things discussed here are already happening and moved to other threads, so if you feel you want to give attention to something that was brought up here, please create a new dedicated issue