@henrique99sl hmm well I'm not sure I should do your homework for you, but I can tell you I would store the sequence in an array and read it back with a [tabread] driven by a [metro] and a counter.

you can look in the help files for an example of an adsr.
Are you allowed to use externals? that would make things a lot easier.

to me it sounds like a 8-step sequencer going into a square wave with a resonant lowpass filter (you can use a [bob~] object for that)
for the square wave you might want to use a bandlimited one, which can be tricky if constrained to pd vanilla.
you'll want the metro running the sequencer to trigger an envelope for each note (for filter and maybe amplitude)

research this synth

Isn't overwriting it what you want?
Here are a couple examples:
make_into_noise.pd in this one a set number of random samples every block get set to random values, until there are none left. (every loop through the sound file sets N more). There is an array for per-block 'urn's that keeps track of which indices have already been written to.
make_into_noise_2.pd in this one it uses noise~ both to choose to insert a new random number, and to generate one. A separate array keeps track of which indices have been written to. Lots of expr~. This one also has the option of slowly adding more noise

someone in the facebook group had an issue compiling and this worked:

solution for me was to add "-lmvec \" in the makefile BEFORE the "-lm \" line on line 211

not sure why it works

load it into a table that you play with [tabplay~] and alter the values as you play it (you can use [tabwrite~] later in the signal chain)
edit: or just set values in the sound file with regalar [tabwrite] directly

@oid basically everything (including 'anything' selectors) that can't be parsed into a float or special symbol (like dollarsign numbers) is converted to a symbol and stored in the table. That includes things in message boxes
afaict that includes comments too currently. I don't think symbols get removed from the hash table either (as symbol instances aren't reference counted or anything)

@oid all symbols end up in the hash table, the way send works is by having a linked list of receiver objects in the send name symbol itself iirc.
However when you use [send] it already has a pointer to the symbol (and list) so it doesn't have to look it up in the table.

you can see the udpreceive~ source here: https://github.com/pd-externals/mrpeach/blob/main/net/udpreceive~.c
if each pixel is a sample, wouldn't the samplerate be 800k*framerate for 1000X800? that's way more than 192k...
fundamentally your biggest issue is transferring that much data across a network, even a local one. (even if you do pack each color channel as 8-bit values into 1 24-bit int though it might get you closer if you separate the data over multiple channels)
Anyways I'm kind of confused: how is the source 'audio'? it might make sense to think of it as sending video, then convert to/from audio in pd
There might be some GEM-based objects to do that part.. maybe you can stream to/from vlc or something
you could also consider using libpd to use pd from within python, but then externals might be tricky to get working idk

@esaruoho compiled objects (unfortunately) can't be created that way.
you have to use [declare -lib ceammc] and then [ui.menu]

@Blindekinder I have a fork of pd that has the capability for (ugly) bezier cables, and setting colors (with a matching tcl plugin for selecting color themes)
https://github.com/sebshader/pdnext/releases
https://github.com/sebshader/color-themes-plugin
It maintains compatibility w/ vanilla otherwise

I tried to make a 'microbenchmark' for an equivalent list and text: looks like list is a bit faster, even with a vanilla "get" message (it can be sped up more by using [iem_prepend get] from iemlib.)
at larger sizes it looks like it becomes more pronounced
text-list.pd

my intuition would be that multi-line [text] is probably also not as good as [list] because it has to go through every atom every time a lookup happens. Especially if you have to search as well. (but again it's complex, there are extra messages to route to the clones, maybe memory isn't as contiguous leading to cache misses etc)

@whale-av still not solid on how the data is coming in or accessed in this particular case. From what I can tell yes though I would think per-clone [list store] would be at least similar if not faster. but haven't done any profiling or anything to back that up..
There are a lot of factors w/ all the routing, clones etc that add complexity..
sorry for the slightly OT tangents

@oid the stored list is freed every time a new one is supposed to be stored (or the object is deleted/freed). The 100 element lists are only used on the stack (non-stored lists). When lists are stored they are always stored on the heap.

e.g.

    /* set contents to a list */
static void alist_list(t_alist *x, t_symbol *s, int argc, t_atom *argv)
{
    alist_clear(x); // <-- clears stored list on the heap

the lists stored on the stack are only used when sending a temporary list to an outlet (like triggering [list append] from its left inlet)

now that I'm looking at it again I'm not sure why getting elements from lists should be slow if using [list store], if you know their indices. bc lists are actually contiguous memory (not linked lists).

edit: when lists are cleared or elements are deleted the memory is freed at that moment

edit2: [array] will probably be more efficient in the majority of compatible cases because memory is only allocated once when it's created, and deallocated once when it's deleted. (at least when there's a reasonable maximum size and it doesn't have to be resized)

@ddw_music (slightly OT) Supercollider might not 'know' enough to pre-allocate the array of strings. Idk what supercollider does but usually in programming languages that don't have explicit memory allocation strings/symbols are stored in some string pool/table. They're hashed and whenever a new string is made it's looked up in the pool to see if it needs to be allocated or if the same one already exists and can be reused.
This is actually good for performance in a lot of cases bc it prevents memory from being wasted when the same strings are used. Plus, the pointers of the strings can be compared instead of comparing every character.
But it can also be bad for performance in others (such as comments, or where the strings will only be used in 1 place)

(that's what pd's gensym function does)
I'm guessing supercollider does something similar, so when it creates all of those strings it actually has to allocate each of them on the heap separately rather than allocating the array with the space for each already included. (plus it would have to know the max size of a string to do that too which would also waste memory in a lot of cases where the data stored was smaller than that)

actually the most efficient might be a giant array that stores everything. if you're receiving the data per-button then also order the array per-button and calculate the index with (button_number*sequence_size) + sequence_index
(this is essentially a 2-dimensional array)

but I feel like I need a clearer picture of the architecture maybe. (what exactly are the parameters of? how long is a sequence? how often is this being triggered/queried?)

imo the best way would be to use an [array] for the button in each [clone].
If you were to use [text] there are several tradeoffs: if you want to be memory-efficient then using a single [text] might be better. (but at the cost of using more cpu possibly)
(of course using more memory can also cause performance issues in the extreme bc of cache misses etc.. it's complicated..)

The order in which buttons/sequence statuses are listed in the file might change, so I can't really avoid searching at least once per button to update.

why would the order change? why couldn't you just write each button's info to the corresponding line number?

I would go the route of updating old pd-extended patches to be compatible w/ modern pd instead of using pd-extended. Pretty much all of the old libraries are on deken afaik. That will position your patches to take advantage of any/many modern improvements to pd.
it can be a headache to add all of the [declare -lib x -path x] arguments, but it will be worth it later, especially if you are the author and don't have to refactor some other code.
you could try uploading what you have so far so we can get a better idea of what you're trying to accomplish (w/ comments?).
if the issue is transposing a currently playing note, I guess you could just do a note off before a note on. Or if there's pitchbend you could try using that. Really, it depends on what kind of synth the midi is connected to and its capabilities as far as per-voice stealing/gliss goes.
Maybe your midi synth has some control for octave that you could simply send from pd..

Should I convert the output of [openpanel 2] to a message and then loadbang this message into list store upon load or what?

yes

this will put the last thing output from [openpanel] into the [list store] when the canvas loads

the only way to store things within a patch is in message boxes or with [savestate] (which only works for abstractions iirc)

or, you can use text files as above (personally I prefer saving in-patch)

if you only want to save what is actually in the [list store] you probably need to route the output depending on some save switch which is possible but more complicated and depends on manual saving (or setting the dirty flag for the patch and unsetting it again when saved w/ an iemguts object or something)

edit: maybe message box should go in the left inlet of [list store] for your case, not sure what the rest of the patch looks like

I don't have too much experience with RPi, but sometimes on other linux machines you have to set certain values in limits. https://jackaudio.org/faq/linux_rt_config.html
Again idk that much about RPi (what does it use for 'disk'?) but the bottleneck could be reading from and writing to whatever it uses to store the soundfiles.