Memory types and sampling to serial flash

The Teensy 4 has two main types of memory flash, aka program space, and RAM.
There are 1984kB of flash and 1024kB of RAM.
Program space cannot be changed by the code, it is written once when uploading then stays. It is non-volatile meaning that it stays there when the Teensy is unpowered.
RAM is where all the variables are held. It is volatile.
There's also 1080 bytes of EEPROM, a special type of memory in the Teensy that persists after the Power is turned off.

Lets say we want to sample some audio. Audio is sampled at 44.1Khz by default. Each sample needs an integer, 2 bytes. Stero would then need 4 bytes, 44100 times a second. If we were to use RAM we could store 1024/(44.1*2) = 11.6 seconds of mono audio.
Cool! But it would go away once the power was turned off.
So we can use external serial flash. This is the chip installed on the bottom of the Teensy.

This code is an example of how to sample with the Bleep base.
This is the chip installed on the base. It can hold 128 Megabits which is 16 Megabytes.
Flash can be read from very quickly but takes time to write to as you need to erase what's there before writing. Flash cards and SSDs do this but it's automatic. Of course we have to do everything ourselves.

The samples are stored in banks on the flash chip to make it simple, all of the same calculated size. This is sfblocks in the code.
A bank must be erased before data can be put in it. This takes about 500 millis per block. Once a sample is recorded it's length and starting location are stored in EEPROM.
On startup, the Teensy checks this memory and remembers the starts and lengths of all the samples.
There is a slight buzzing sound while you're recording but it shouldn't be in the samples. The sampler takes abut 8% pf the processor to play back a sample at regulars speed. The faster the more taxing as its needing to grab samples more quickly. At 4x it's about 14%.

What about flash cards?
Cards can hold gobs of data but are much slower than serial flash chips. They also can be fragmented, meaning the data could be spread across the card making it even slower. It is possible to dump files back and forth from the SD card though. It's complex but you can see how it works in this code. I'll have a more clear example for the Bleep base soon.

It seems like there's plenty of space in RAM though?
Yeah its good for some things and I plan on making an object for that too.

What about the "play mem" and play SD examples in the audio library?
These work but you can't change the speed, just play them back.