Memory cells are arranged in a matrix
This is a 16-bit memory, 1 bit wide, so it needs 4 address lines to address each individual bit. That's the a3..a0 lines at the left. a0 and a1 enter the green 2-to-4 demultiplexer. An N-input demultiplexer can have 2\$^N\$ output lines, and the binary input indicates which of those will be active. That's the row select.
The column select does something similar, but uses a multiplexer to select 1 of 2\$^N\$ lines as the output signal. So the combination of row select and column select can address an individual memory cell.
This is Random Access Memory because any bit is directly accessible, no matter what the address is. And it goes for DRAM as well as SRAM. SRAM needs more hardware to store a bit (4 or 6 FETs) than the DRAM shown, which needs only 1 FET per bit. The data is stored in the capacitors. Capacitors have leakage, and after some (very short!) time the data will be gone. That's why DRAM needs frequent refreshing: the data is continuously read and rewritten between accesses. This adds some extra hardware to the device, but a DRAM die is still much smaller than an SRAM die with the same capacity.
Assumption: The developed code mentioned in the question is not a very advanced and sophisticated application, and does not contain large amounts (10s of kilobytes) of data / arrays.
The Arduino code size limitations apply to the final compiled binary of the application, not the source code size, and not the size of the HEX file generated from the source code. As @DaveTweed has pointed out, Hex files will be more than twice the size of the actual binary bytes that need to be written into the MCU's Flash memory. Source code files will, further, be many times the Hex file size, depending on code specifics, commenting and coding style.
A 20-kilobyte binary output would typically represent a fairly sophisticated, complex application on an Arduino / LilyPad - or, an application incorporating a large amount of data arrays or data buffers. The source code for such an application could well be in the 100s of kilobytes!
Even the more complex of the sample applications that come with the Arduino IDE, for instance, compile to just around 2-5 kilobytes of binary output.
UNO has this capacity in its Flash, the Lilypad doesn't!
About Arduino LilyPads: These are built around lower power but not lower memory specification versions of the same microcontrollers used in the Arduino Uno: The ATmega168V or the ATmega328 (#1). Hence, the available flash memory on the LilyPad is the same as on the corresponding Uno board.
Where did those numbers come from?
The Arduino IDE's support for ~30 kilobytes of application binary stems from the support for the ATmega328 family of microcontrollers on both the boards mentioned. The ATmega328 has 32 kilobytes of Flash memory, of which the Arduino bootloader takes somewhere between half and a couple of kilobytes, depending on which variant is loaded.
The remaining 30-odd kilobytes (ATmega328) of Flash are thus available for user-created Arduino applications, their data, buffers et cetera.
Besides this, 1 - 2 kilobytes of SRAM and 0.5 - 1 kilobytes of EEPROM are also available on the ATmega168 and ATmega328 controllers respectively.
(#1) While the Arduino Lilypad official page mentions an ATmega328V microcontroller, the Atmel web site does not yield (for me, anyway) any such variant of the ATmega328, on a search. Hence, no datasheet found either.
Best Answer
It will vary depending on if the synthesizer is a full analog synth, or a hybrid synth with digital components. The way that analog synthesizers with digital components (one of the first of which was the Prophet 600) typically work is that there is a separate control A/D and D/A, which actually sits in between the potentiometers and the synthesizer engine. In older synthesizers (such as the Prophet 600 Prophet 600 schematics), there was only a single A/D and D/A pair, which are multiplexed by using several sample and hold circuits. In any case, when you store a patch, the voltages of the controls are digitalized using the A/D and stored by the microcontroller into whatever non-volatile memory. When you recall a patch, the D/A generates the control voltage and bypasses the potentiometer.
Of course you are correct a sudden "override" of the physical controls by either recalling the patch or external MIDI control can be jarring and quite 'unmusical'. Therefore, different synthesizer manufacturers have adopted different methods to overcome this problem. I know that one manufacturer uses a weighted interpolation, so that if you recall a patch and then start "twisting the knobs", cleverly designed circuitry will allow the knob to operate from the starting point that was stored in the patch, but also assuring that you cannot exceed the normal bounds of the control.
Another problem which can happen is because the controls are sampled, sudden or precise movements of the control potentiometers can cause stepping or other artifacts in the sound. The was very much a problem on the Prophet 600 and other vintage analog synthesizers with patch memory, but is less of a problem now that processors and A/D and D/A technology works at higher speeds.
Finally, now that I've had a chance to look at it, it seems that the OB-4 voice programmer works the same way: according to this schematic. Of course, this is only a voice programmer, and not a full MIDI controlled synthesizer like the Prophet 600, so only the second problem is an issue. It is not meant to be used to modify the parameters of a sound in a real-time performance.