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