We have all been there............
You have an abstract idea, and you are hard pressed to get ahead and build your patch!
But before you start....... you have to “know”...... at least......... that this.............

Is the same as this..........

Well........nearly. There is in fact much more in the second patch.
And although the second patch is not perfect (in fact there are many mistakes), it is much easier to work with (and easier to find those mistakes).
You can build the first patch in about 2 minutes using just two components (abstractions) of the second patch. An abstraction is a patch... like a subroutine... that you can use over and over again.

Why is this important?
Because at some point your patch will become very messy, and if you are unlucky then it will stop working. You will not be able to see the mistake in the giant cobweb that you have created...... and when you finally spot that mistake you will have to fix it in 200 different places!
It is quite likely that you will then delete important items or connections by accident and cause more problems...... and not finish your project on time.
If you have a new brainwave with the first patch then you will be eating your breakfast after a sleepless night with your patch. With the second you will be hearing the result within minutes.
Please study the attached patches for as long as you can remain interested. They are difficult if you really are a complete beginner. If you have more experience then you will of course understand a lot more...........

If none of that is even remotely understandable then you have missed out on the basics.
It is much easier to use a dishwasher if you know where to put the soap and that it needs mains electricity to work at all......... http://puredata.info/docs/manuals/pd/x2.htm
DO NOT read chapter 2.9 yet.

( I have tried to explain some of the workings, especially the use of $ variables within an abstraction. (PLEASE SEE THE POST "show_me_dollars" BELOW IF YOU DO NOT UNDERSTAND THE USE OF "$"))

Try to remember while you are working that there is almost always a better (and easier) way to build your patches. Look in “soundbox.pd” as well for some $ clues!
As your project progresses you might come back here again, having found that you are able to create abstractions of your own. You will then be amazed at your understanding of what I am sure looks very difficult at this first glance!
Please do glance........it will do you good in the long run......
Pd noob.zip
David.

Very nice advice, David!

Here is another piece of advice to complement David's. This one is more about approach and less about technique, but it has helped me to drastically simplify my patching.

Build tools rather than systems.

This might not seem like a very precise distinction, so let me give an example. I am trying to create a sequencer that can bang numbers on a list in their proper order, so that the list “1 2 4” would be played as “bang bang 0 bang” (where 0 is a pause). I also want the sequencer to be able to start from any position in the list, and play the sequence in reverse order. I first tried to create a system that would achieve this, encountering new situations as I went and trying to patch them in. The number of conditions grew and the system got more and more complicated, until I can't really understand it anymore and it doesn't work anyway:

So I started again from scratch, and instead of building a system, I built three simple tools:

1. a counter which counts from x to y and then stops
2. a tool which decides where to count from and where to count to
3. a tool which matches the count with the given list, and outputs a bang if a match is found.

The result looks like this:

Believe it or not, the second patch does everything that the first one does, and does it better!

The drawback, of course, is that you need a lot of foresight. Most times I don't really know what I'm aiming for in a new patch, and I certainly don't know what problems I am going to encounter—I'm just exploring. But even if it takes two or three shots to make the right tools, it's worth it in the long run. Not only does this approach make patching more elegant and efficient, it also makes it much easier to modify when you encounter an unexpected problem in the future.

Ok...... So I have been meaning to do this for a very long time......
I don't think it is the perfect "show_me_dollars" and so I will change it from time to time.
3rd attempt.........
show_me_dollars.zip
Here is a really terrifying screenshot, but I have also tried to explain it in words.
In many ways I think words ( below the screenshot) are easier to understand.
David.

Dollar $ variables in Pure Data patches.
A dollar variable is a thing that can be given a new value.
The new value can be a float or a symbol.

1. If the Dollar variable is in an [object] box
   A Pd patch can be saved and used inside another patch. We then call it an abstraction.... and it is just like a programming sub-routine.
   If you want to use it many times then you have a problem, that they are all the same, so if you put an object [receive woof] they will all receive any message that you send with [send woof].
   That might well be what you want to do.
   But what if you want to send the message to only one of them?
   You can give it an [inlet], but your patch will get messy, and what if your patch needs to make its own mind up about which abstraction it wants to send the message to, maybe depending on which midi note it received?
   The solution is to give the abstraction arguments... some parameters that define it and make it different to the other copies.
   For example [my_abstraction]
   Let’s give it some arguments [my_abstraction 5 9 woof]
   Inside the abstraction, as it is created (you open its parent patch) the dollar variables will be replaced. Wherever you see $1 written IN AN OBJECT it has been replaced by the number 5.
   Number 5 because 5 is the first argument and has actually replaced the $1. You still see $1, but if you bang a [$1] object it will output 5.
   [f $2] will output 9
   [symbol $3] will output woof
   So if you have an object [receive $1-$3] then it has now become [receive 5-woof]
   And if you want to send it a message from outside, from another patch or abstraction, you will need to use [send 5-woof]
   Every Pd patch, which remember includes your abstractions, also has a secret number. The number is unique and greater than 1000. As Pd opens each patch it gives it the number, increased by one from the last number it gave.
   That number will replace $0 as the patch is created. You can find out what the number is by banging a [$0] object and connecting its output to a number box, or [print] object.
   $0 can be used in any object as part of the name or the address, which means that a message cannot escape from the abstraction. A sub-patch like [pd my-subpatch] will be given the same number.
   But from outside your abstraction you don’t know what it will be when the patch is created, so it is not useful. (A lie, you can find out, but as it can change every time you open your patch it is not worth the bother).
   Use it to send messages within your patch [send $0-reset] to [receive $0-reset] for example, because the message is absolutely unique to its window, so you know it cannot interfere with other abstractions.
   Use it also for objects like [delwrite~ $0-buffer 100] or for an array name [array $0-array] so that in each abstraction they have a different name and you will not have problems with their being "multiply defined"...... as each name can only exist once in your patch.

2. If the Dollar $ variable is in a [message( box
   Dollar $ variables are also replaced, but not as the patch is created (drawn by Pd as you open it).
   Dollar zero $0 has no meaning in a message box. It will produce a zero if the message is banged, but that is it.
   It is a mistake, a patching error, to put a $0 in a message box.
   $1 $2 $3 $4 etc. in a message box are replaced by incoming atoms (individual floats or symbols or whatever) when they arrive. $1 will be replaced by the first atom in the list, $2 the second etc.
   So if you have a message box [$1 $2 $3( ..... and you send into it a list [3 48 lala( .....then it will output 3 48 lala
   That is not really very useful.
   But it is actually very powerful.
   Make a list in a message box........ [33 12 wav(
   And bang it into a message box [open my-track$2-$1.$3( and you will get the output.........
   open my-track12-33.wav
   Which could be just the message that you want to send to [soundfiler]

P.S. If the first item in the incoming list is a symbol then it will be dropped causing errors.
You can fix that by making the message a list by passing it through the object [list].
Unfortunately only messages starting with a float are automatically recognised as lists.

@whale-av

I did one some time ago, here is what I came up with

abstraction-help.pd
abstraction.pd

@whale-av what is this?

@4ZZ4 It was an abstraction from Pd extended.
A much used abstraction years ago..... it "loadbangs" and allows you to "bang again" with the mouse if you need to....... lbang.zip
There are probably a thousand or more useful abstractions (as opposed to compiled externals) lurking still in the old extended libraries.
It is hard to remember to include them in an uploaded patch....... and at the time of my posts above extended was still very popular.
David.

else/loadbanger allows you to click on it to bang again by the way