@Matt-Stalcup I don't see all of the problems that you describe in this version (from Pd Vanilla 0.49 but still the same in 0.53)...... text.zip ...... so maybe it will help.
Of course I might not have looked hard enough...... but it might be different to the file you have?
I hope it helps.

Anonymous... maybe that at some point in the future it could be possible to find the data contained in a [text] object without knowing its name....... a "sort of" [text search all] or [text get all].
An [all( message has been implemented for some objects...... for example [clone].

[write( failed could be because the file attributes of text-object-help.txt have been set as read only...... maybe.

"sort" does seem to have proper help.

In [text define] "text-help-1" is at the top of the window because that is the defined name of the "defined" [text] window. The data has been read from the file text-object-text.txt, which is a simple "text" file...... not the same thing at all as a [text] object.... when you clicked the [read ...( message.

Summary.
A [text] object maintains a list of lists, each list separated by a comma or a semi-colon (carriage return) and each [text] object has a defined name.... which is defined by [text define].
So [text define] creates the [text] window and holds the data...... which will be saved within when you save the patch only if you use the -k switch. If you don't use the -k switch then you will have to write new data (generated from incoming midi for example) or read in data from an external file every time you open the patch.
The data can be read from an external .txt file and written to it, and that file can have a different name.... e.g. playlist.txt.

The other objects [text get] etc. provide the tools for finding and manipulating the lists within the defined window.
You could think of it being a three dimensional [array] that can contain "anything" rather than just a list of floats.
The story started with [qlist] which was then supplemented with [textfile] and eventually superseded by [text]........ see [text sequence] for the similarities to appear.
The separation of functions into free-standing objects such as [text get] allows you to interact with [text define] from different parts of a patch (or another patch) without sending messages or connecting cords.
David.

@markuc You can send data from Pd Vanilla to a network port....... TCP or UDP...... using [netsend].
The data can be in ASCII or binary format and there are objects for formatting messages to be sent for OSC as well..... and the port can be bi-directional.
You can also send directly to another program from [netsend] using the pdreceive binary that you will find in the Pd bundle..... called in Python for example.
You can also communicate through a serial port using [comport].
Have a look at the help file for [netsend]..... right-click the object for help.
Welcome to the forum...!
David.

@esaruoho Off topic (a little, but it might help).
On the audio side you could reduce the patching and remove the audio from your abstraction by using cyclone [matrix~]
Messages from control in the abstraction could control just one [matrix~] for the entire audio chain.
The same [send] address for every fader, and the corresponding [receive] address for [matrix~]
The [dump( message also lets you construct a state saving mechanism for control parameters.

I use it for a 64in 64out mixer, with eq on all ins and outs..... so a lot of fader abstractions although my colour changes are only occasional (new mix templates update colours on the GUI and touch screen tablets).
David.

@murkrellr What is your operating system?
Do you mean in the operating system file list window?
David.

@ddw_music I added a [bang] + [$0] + [number] to my patch just to check the order of abstraction creation, and saved it. Now it is consistent across Pd versions...... but with the new [random] sequence 2nd 3rd 4th (see my post above).
Conclusion..... something something nothing.
If I posted the original.... I probably did...... then I will check in a text editor this evening.
Certainly the patch window opens with different window coordinates in later versions..... a lot of whitespace at the top...... so "something" changed.
David.
P.S. Its a mess in a text editor.... window coordinates for every object have changed and the object ordering is all over the place..... to the point that I don't think I will be able to analyse the changes.....
So this evening I will start the patches and resave them in previous versions of wish..... maybe that is where the conundrum will be solved.

@Maks As @jameslo says....... setting the patch to use a previous Pd version might work if a change has been made. The help file used to state "WARNING: nothing is known about the quality of the pseudorandom number generator." .... so very strange if it has changed.

You can try a compatibility message saved in the patch...... e.g.
[loadbang]
|
[;
pd compatibility 0.50(

BUT.... I luckily have a very! old [random] test patch with multiple [random] objects..... and I commented the values expected into the patch...
It is very strange.
There seems to be a shift......... the 2nd 3rd 4th etc. created are the same as the 1st 2nd 3rd etc. used to be.

You could make a copy of your patch, delete the [random] object, create a new one somewhere.... a dummy that you will not use, and then put a new [random] .... a second one....where you had it originally.
Keep the dummy [random] in the patch, save it and try starting the new patch.
I.e. insert a [random] in the creation order before the one you want to use.

The compatibility message doesn't seem to work and I had to go back to Pd 0.47 to have the same series as before.
That suggests a change as Pd went from 32-bit to 64-bit........ which could make sense....
David.

@ddw_music It's probably this from Pd Extended......
A "sort of" graphic equaliser.
64-bit update on Deken by lucarda.
David.

@Maks Worth checking...... but very unlikely as changes that break objects for previous patches are frowned upon by the developers.... even when they could improve things.

It is most likely that you have opened another patch first, and that it also contains [random].
Unsure...... but every [random] created after the starting of Pd will be different...... but the same difference will occur for all of them after a fresh start of Pd.
David.

@bobpell If you open the patch with a simple text editor....... one that does no formatting..... you will see a couple of lines that contain the name of the sub-patch.
You can ignore the #X restore line.

#N canvas 907 466 450 300 mysubpatch 0;
((all the objects and connections in the sub-patch here))
#X restore 80 565 pd mysubpatch;

The numbers will all be different, and mypatch will be the name that you gave your sub-patch.
The 907 466 in my example above is where the sub-patch will open on the screen, and the 450 300 is its size.
The 80 565 is where it appears in the mother patch window when it is closed.

It could be....... most likely as it is still working..... that it has gone outside your screen area.
Edit the #N canvas line to #N canvas 0 0 xsize ysize (leave xsize and ysize as they are) and save the file.
It should then open on the screen in Pd.
You can then move it to where you want and save the patch.
David.

@inum https://lists.puredata.info/pipermail/pd-list/2009-05/070317.html
It looks as though you are controlling [fffb~] with messages so [biquad~] should work.
You will need [equalizer] from the ggee library to write the coefficients to [biquad~] and I suppose you will need 8 copies as it is a single filter.

Pretty sure [delwrite~] and [delread~] can replace [tapin~] and [tapout~]

A lot of useful [list] abstractions can be found in the list-abs library.... mainly abstractions and so Vanilla Pd...
And so you will find a clone of [zl group] in that library......... [list-group]

A lot of Max clones can be found in the cyclone library.... [uzi] is there, [maximum~] also, and maybe some others you are looking for..... but audio-rate clones are likely to be externals.
David.