@ddw_music https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/8375/designing_sound.zip/practical15.html has a little more description and states for [rain_on_water] .... Rain - rain on water, alternative droplet model.
But fortunately, [raindrops] is included in the tarball of all files here....... http://aspress.co.uk/sd/ so it is an omission mistake on the page you linked to....
David.

@gentleclockdivider It is replaced when a symbol...... Bug_select_or_not.pd but once created for symbols cannot become [sel float]
[select] and [route] become different objects when they are created for floats or symbols.
David.

@elden Help... Find Externals..
and search for list-abs.
As it is a library of abstractions it is not platform dependent.
David.

@elden list-abs.... here it is... list-random.zip although it is worth having the whole library.
The library consists almost totally of abstractions.
David.

@tildebrow Then you should get the else library and see.......\else\Live-Electronics-Tutorial\Part.12-Advanced.Pd\39-Data.Structures .... as that is an up-to-date tutorial.
All of the examples need [declare -path else] and that is missing from some. But I installed it long ago and that has probably been corrected.
David.

@tildebrow Unsure whether you are looking to put "words" ..... [drawsymbol].... not editable..... [drawtext].... working.
Or graphical symbols.
If the latter then have a look at ..... https://forum.pdpatchrepo.info/topic/10349/drawing-objects-simplified/2
Particulary object-draw-help.pd ...... 1478428764693-object-draw-updated.zip

Or the else library contains a tutorial for data structures.
David.

@elden You will have seen....... https://www.uni-weimar.de/kunst-und-gestaltung/wiki/images/Dynamic_Time_Warping_for_Pure_Data.pdf

The paper concludes with an application for body gesture recognition, but it is working with arrays so should be equally applicable to audio.
The code still exists as C++ to be compiled for a Pd external, but of course we have since moved to 64bit.
https://github.com/lemire/lbimproved

And there is this....... which is older, by the same same author....
https://github.com/felixr/dtw_lbimproved

David.

@oid I can correct the object numbers in the test patch for vanilla and then it loads correctly, so I don't think it is the same problem. [matrix~] also creates correctly with the [loadbang] in vanilla, but with object numbers wrong...... and I can correct that.
I will try with [initbang] instead when I get time... thank you for the idea..... but I am not convinced for now that object numbers are wrong because of [loadbang] and the ordering will be changed again when I try.... so a lot of work.
If [loadbang] in later vanilla is sorted after all other objects regardless of its creation order then that would explain the change of object numbers..... but that would be in the "breaks old patches" category... and unusual especially for a foundational object. But only for dynamic patching, and we were warned that it is unsupported.

So I will first check whether moving [loadbang] to the end of the object list solves the problem.... an easier fix.

You are correct that this patch worked correctly in older vanilla...... it was built to create a replacement for [matrix~] during the 32/64 changeover while the external was unavailable, and worked at the time.
David.

@FFW You can dynamically re-create the connections, but of course you need to know the object numbers of the objects in the main patch that you want to connect to the inlet/outlet.
I have had to do this building patchable input /output cords in a matrix..... matrix~.zip
Everything inside [matrix~] is created according to its arguments and then the test patch connects to the abstraction.
The test (matrix-test~.pd) works in extended.... but strangely the object numbers have changed when opened in vanilla. Inside [matrix~] everything creates correctly in both versions.
It should create this....... which demonstrates the principle...

It is best to recreate your main patch with the objects you will want to connect being the first objects created... and then copy back the rest of the patch and connect those objects.
Then if you modify the patch later you will not change those object numbers and break the dynamic cord creation.
David.

@vamoscreciendo Try this.....
David.

@jamcultur The command line flags set the devices to use when Pd is started. They can be used in Pd preferences to fix the devices without opening the midi dialog and saving the setup after starting Pd.
Not so useful in Pd preferences as they will always be the same, they are very useful if starting Pd from a batch file in windows, as you can have different setups for different hardware setups....... e.g. in the studio or out at a venue.
I am not sure how they could be used in Linux... maybe starting Pd from a shell script.

However, the order of devices almost definitely depends on the order in which they were plugged in before starting Pd so it needs some rigour to use -midioutdev. Using -midiaddindev and -midiaddoutdev rather than -midiindev and -midioutdev might solve that... ? I don't know the syntax..... but maybe a list of the devices by name and in the correct order after the flag...?
That could be problematic because of spaces in the device names.... see below.

I see elsewhere that you have a problem having to re-start Pd when plugging in more midi devices.
I wonder whether a request could be made to the Pd-list.
In Pd-extended devices were hot-connected when plugged in, but that is no longer the case in Vanilla. The midi-dialog.tcl file is completely different in the two versions and depends on other .tcl files and probably also on the Pd binary, so midi-dialog.tcl cannot be simply replaced.
There is also a fixed limit of 9 midi devices. I think windows has a limit of 10, and the registry needs to be edited by removing an old entry before adding a new one.

There are ways to set devices from within a patch using [midisettings]........ see set_midi-order.pd.... midisettings.zip
The idea is to reset the order of devices to what is required, by sending a list to Pd (a midi-dialog list).
It will need some work, using [midisettings] (part of the mediasettings external) as the names returned by the [listdevices( message are symbols with spaces inside. Since some version of vanilla the spaces can be escaped so the complete symbol can be used in the route object.... https://forum.pdpatchrepo.info/topic/13506/list-comparison/2
Otherwise, for older vanilla you will need [concat] which is in the thread.

So get the midi device names with their order numbers, and then re-order the numbers by device name according to what you require, and then send the re-ordered numbers back to Pd in a [midi-dialog( message.
When you implement that it will no longer matter in what order you plug the devices or in what order they appear in the midi settings menu when you start Pd.

Here is a quick re-write of set_midi-order.pd escaping spaces with a backslash for midi devices on my system....... set_midi-order.pd

The same can be achieved for audio devices using the [audio-dialog( message and [audiosettings].
David.

@jamcultur https://puredata.info/docs/faq/commandline

David.

@bklindgren It is usually called a buffer and set as "buffer size" in samples...

Pd is unusual in calling it "Delay".
The buffer size in samples divided by the sample rate equals the delay (latency) in seconds.

Of course the block size of 64 samples gives internal latency.
You only need to worry about latency for live work and live monitoring in a studio,
A latency of 2.9 milliseconds (128 samples at 44100Hz) is the same as moving an instrument just under 1 meter away from a listener...... so not really noticeable..... (speed of sound approximately 343 meters per second in air)
David.

@impression You will need multiple tables... arrays... one for each note.
Decide the maximum number of notes for the polyphony and use [poly] to keep track of note on/off.
https://forum.pdpatchrepo.info/topic/5311/polyphonic-voice-management-using-poly
You can use [clone] for the voices or build an abstraction, with each voice having its own array for the step sequencer, and either a master [metro] for timing or a "timeout" delay window set for moving on to the next chord. Because there is no such thing as a chord in midi...... just a serial string of notes arriving (nearly) at the same time.
You will need to pack the arrays with zeros for any voice that does not receive a note for its step.
David.

@bklindgren Yes, it is the buffer, so it will add latency. For an internal soundcard it might need to be quite large... 30 - 80msecs... so that the soundcard has time to process and probably resample to the internal sample rate of the computer..... for example 48K in Windows. When the computer does not have enough time to process the buffer before it is refilled then you will get audio dropouts (clicks).
With a professional sound card you might be able to reduce it to 2 - 3msecs.
David.

@RT5000 Any object (all objects) can have a $ variable as one of its arguments.... you don't need to use a [float] to define it.... it will be translated as the abstraction is opened.
So you can use $ variables as part of a symbol in the OSC address.... [oscformat /EnvATT_$3] will become [oscformat /EnvAtt_1] if the value of $3 for the abstraction is "1".
A $ variable in a message acts differently.... taking its value from an incoming message.

GUI's can be told to change their send and receive addresses by sending them a message, so they can be dynamically changed within an abstraction.
And those addresses can contain $ variables anyway.
The same for e.g. [send message_$1] because it is an object.

[route] and [select] can also be changed (for a single argument) through their right inlet.... but again... they are objets so you could put a [route $3 $1 $2] if you wish.
So you do have a few options.

Knowing that it is not easy, I had a go at explaining this a while ago...
https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
David.

@RT5000 $ variables are translated as a patch opens, so the "mother patch" arguments will be translated to $ variables for abstractions.
Which means that you need a "super mother patch" that opens the "mother patch" with all the variables that you will want to use for the abstractions.
You could otherwise use a counter and dynamic patching to create the abstractions with an incremented argument (or more) like this.... dynamic.zip
David.

@impression There could well be messages in the Pd console in red "cannot create".
If so then use Deken ( Help.. Find externals ... from the Pd top menu.)
It needs a fairly recent Pd version with the [file] object.
Please let me know which externals were needed as I would like to make it pure vanilla.

Ahh... ! .... I think it needs [count]....... which is a vanilla abstraction.
I have just added it to the zip file..... cart-5-vanilla.zip
David.

@impression To play files from a folder this might help...... cart-5-vanilla.zip .... although I am not certain that it is 100% vanilla.
As you will know the paths to your folders you will not need all of it, and probably not the random part either.
Otherwise I think the else library has an external for listing folder contents.
David.

@porres I cannot remember to tell the truth as it was a long time ago. Yes, I believe what started my "investigation" (learning session) was finding that a list could be distributed across the inlets....which surprised me for this object.
Maybe that could be described as a bug, as I cannot see that anyone would ever have used it for any purpose, and it can cause problems.
David.