@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.