Hello to everybody,
I would discuss with you about some good philosophy for organize PD patches in order to have the most number of projects ready to work in a given time.

I have an intensive work on PD for digital music creation and development. For me is usual spend a lot of time when I re-open an old working project and find it doesn't work now, because in the meanwhile I have optimized some self made abstraction or external.
If you use the same abstractions/externals in more than a patch (I hope;-), often is necessary and useful make them better to improve your current projects, but the old project architectures now are probably out of order... THIS IS A BIG PROBLEM FOR ME.

yesterday I found out a trick, perhaps many of you know it or have a better method.

Is possible to refer to your patches from any part of your hard disk by writing a path on the actual object you create inside PD e.g.:

C:/pd/synth/myabstraction [example of absolute path]
../synth/myabstraction [example of relative path]

So if you want to use the object delay you have in your computer, then make a new object and write on it [C:/pd/dsp/delay] if this is the path.

MY METHOD is this:

I have a folder named "pd" and subfolders named synth, dsp, external etc... I refer from every new project I do.

---> this is my environment for development

Every time I start a new project I save it inside this folder and I refer to the abstraction/externals I use by writing RELATIVE paths on the new objects.

When the project is finishes (ok, works is enough I simply save a pd folder CLONE in another part of my hard disk and I name it with the project name.

In this way I continue to develop the "pd" folder, make new projects, BUT the old ones are well separated and... EVERY TIME WORKING for me.

what do you think about?

Have good pd projects !

Enrico

Good question and ideas Enrico.

I started by realising quickly that abstractions were a potential problem after getting burned early. For the first year I used Pd I never used an abstraction, always sub-patches.

I think this is good advice for beginners, to spend at least 3 or 4 months only using sub-patches. It keeps everything in one file and makes projects easy to manage.

Later I developed discipline to manage projects with abstractions. By prefixing abstractions with a simple 2 or 3 character to show where it belongs. So most of the abstractions in the drum synth folder were called [drm-snare32~] etc.

Later I learned that certain ones were finished, familiar and ready to move into a globally visible folder. At that time I remove the prefix so [drm-snare32~] would become the definitive [snare32~]
and then I did search and replace in most the files.

I know I can never change the abstractions in my library folder so all the permissions might as well be set to read-only.

Aside from that, I follow normal project folder discipline and have a separate folder for every project with all the resources in there. Rarely ever do I refer to objects in another project, always copy them to make a fresh start (and add prefixes to show where they belong).

Still get broken projects from time to time, but they're easier to fix now.

i just make copies of all my abstractions for new projects. they're only a few kilobytes each.

Thanks you guys for reply.
For sure the advice from Obiwannabe is important because at least for the early period of its life, an abstraction or a self made external can be deeply modified.
But, actually I like to make better and better my abstractions, for example in a dsp or synth by adding some new switch, slider, parameter....
Abstractions may contain obscure errors.
Therefore, sometimes I have to change the library folder, and this increases the performance of new projects. On the contrary the old ones are broken.

If you use relative paths referring to your abstractions/externals, then by make copies of used files in a separated project folder, you fix all the compatibility problems because you don't change more those files unless you want.

Of course you have not to copy the audio files that can be stored in a well defined folder out of the project folder.

When you want upgrade an old project with new abstractions/externals you can copy them from the pd-development-folder and easier fix the compatibility problems.

This method helps you also when you want share a project like this with someone else because it gathers all the dependences.

Think for example of a recording project, a live performance, a course lesson where you have to show something that perfect works...then after some months you have to do the same thing but now your develop-environment is changed.

I've also played with abstractions when starting and encountered the problems that go with them so i've stopped using them.

Since then i like my patches to be self-containing so there's never a problem with missing or altered abstractions. So what i do have is a folder with building-blocks which consist out of the gui elements (everything $0- prefixed for uniqueness) and 1 subpatch with the necessary in- and outlets and the core of the subpatch. Whenever i need something i just open the correct file, copy paste the gui stuff and the subpatch, ready to be connected within the actual patch. When i do some global modifications to a building-block i save it as a new version, ready to be used next time.

When i start something new, within a couple of minutes i have everything in place to be hooked up in my architecture. It's a very simple system, but it works nicely.

but abstractions are invaluable if you want to do stuff like granular synthesis, no?

If i need multiples of something in the same patch (usually only when gui elements or tables are involved, otherwise subpatches are fine), what i usually do is give a unique prefix to the stuff contained in the sub-patch and save that as a standalone patch. Then i open that patch in some text-editor and do a replace of the prefix, save it, open it again in pd and copy it into the original patch (then i might copy the two uniquely prefixed patches and repeat the process to have 2 already in place, then 4,...). It's a bit cumbersome, i know, but i still prefer it over abstractions.

Eventually one has to embrace abstractions to move Pd to the next level. Granular synthesis is a good example, and generally - sophisticated control for polyphony.

I find abstractions to be the only way to go in some patches. most of mine have names like: simple.delay, pitch.node, s.ch.send, s.panner, etc etc. you can probably guess what they do

when working with very large projects, I'm not sure I would be too happy if couldn't use abstractions with creation arguments. my 12 channel mixer with 8 stereo sends on each channel is a good example.

for organizing, I like to use this scheme:

~/pd/
---/abstractions/
---/patches/
------/hello/
---------/abstractions/
---------/hello.pd

where the "main" abstractions folder holds things like ch.send and simple.delay; things that are simple and will probably not change. also libraries of abstractions like the montreal users group go in here (which are very awesome btw thanks!)

abstractions that are likely to change, or really obscure ones that won't be used in other patches, go in their own folders in their respective patches directory.

@obiwannabe said:

Eventually one has to embrace abstractions to move Pd to the next level. Granular synthesis is a good example, and generally - sophisticated control for polyphony.

That's a bit of a strange reasoning you have there obi. Because i believe it's actually possible to solve whatever you want in different ways in pd. Everyone searches his own way to get things done. Apparently many of you seem to be in favour of abstractions but,as far as i know, anything is doable without them. But i guess it all depends on what you understand by "the next level" (of complexity, of results, of...?).

Maybe one day i'll discover the invaluable advantages of abstractions and start using them, but until then i'll do my -simple- polyphony and my own interpretation of granular synthesis without them.

I'm sorry, i was probably a bit harsh in my previous post. I hope i haven't offended anyone

i think what you're saying makes sense. especially about everyone doing things their own way in pd.

i think we all agree that abstractions should be used less if possible.

> Maybe one day i'll discover the invaluable advantages of abstractions and start using them, but until then i'll do my -simple- polyphony and my own interpretation of granular synthesis without them.

The "sophisticated" way I spoke of is [nqpoly4]. What you do is define an abstraction that takes parameters from a global send and writes to a global audio bus. Then [nqpoly] dynamically creates as many as you need!!!! (but this only works if you make the voice an abstraction)

Having said that [nqpoly] is a very fragile and difficult tool. I actually broke mine by accident (for the second time) and need to grab it again. Its problem is that it's written as a set of abstractions itself and you can accidently edit the whole "class" when you think you are editing an instance - and then you break everything. [nqpoly] would be very nice as a more robust external, or built into Pd core.

But as we all agree TMTOWTDI

@obiwannabe said:

> Having said that [nqpoly] is a very fragile and difficult tool. I actually broke mine by accident (for the second time) and need to grab it again. Its problem is that it's written as a set of abstractions itself and you can accidently edit the whole "class" when you think you are editing an instance - and then you break everything. [nqpoly] would be very nice as a more robust external, or built into Pd core.

totally. I have broken it many times. Usually keep the 2 files in the same folder for each patch that uses it. I seem to remember that creating a path to it was really inconsistent and never worked, probably down to my malcoordination if anything .

I've been having a few issues with it recently where it just cuts off abstractions randomly even though its well within the poly number. Even so, it should just wait until the next one is free, not start stealing by truncating them. Any ideas?

But if it was an external or part of the core then that would be a really cool...pd's answer to poly~ in max. I'm all for that

"'ve been having a few issues with it recently where it just cuts off abstractions randomly even though its well within the poly number. Even so, it should just wait until the next one is free, not start stealing by truncating them. Any ideas?"

Not sure Boonier, and I can't test it out atm

What I've done before is use print statements within voices to debug , like in the minimal.pd help example

Being new to PD, and just to general computer programming stuff, I appreciate this discussion here. Thinking about my file organization while I'm still getting started will probably make things a lot easier later.

Thanks for y'all's suggestions!