51 wires? No – use a cable.
In Part III, we talked about how to take 3672 copies of a 300-channel list and cut the memory requirements down to size.
The price we pay for that savings is a bit more work on our part. But it’s a price well worth paying – we save 22 MBytes of RAM.
What we’re doing is restricting each channel selector to a single string/value pair, rather than storing all channels in every selector’s list. To do this we need to intercept the MOUSE DOWN? event on the selector(which happens AFTER a mouse click, and BEFORE the menu pops up). That is exactly the right time to perform our switcheroo. After the user chooses a new channel, we remove all the names that weren’t chosen, and are left with only one. That is how we save RAM.
If you’re used to an event case being directly connected to a given control, or maybe two or three, you might be daunted by trying to have an event case with 51 controls as sources. Well that’s unnecessary, because we can do it another way. You do have to have 51 REFERENCES to those 51 selectors. But that makes changes easier later on. Rather than manipulating the list in the EVENT CASE structure, you just add or delete a reference.
So, in an INIT part of the window’s code, place a reference to each selector, and build the references into an array: 
I put them into separate cases here for easier finding. After the while loop has finished, you have a list of every channel selector in the block (51 in my case). Use whatever method of assembling the array that works for you. Note that you are handling the blocks independently (72 of them). Each block has its own list of Channel Selectors, and each block is basically independent of other blocks.
So what do we do with this list of references? Well, we want to listen for events on ANY of them, so we use a REGISTER EVENTS function to prepare for that:
We want to use TWO events on each selector, so we wire the array to TWO separate terminals and select those terminals to be the events we want. The REGISTER EVENTS function is capable of accepting an ARRAY of references, and it produces a Registration Refnum, suitable for use with an EVENT structure:
Simply SHOW DYNAMIC EVENT terminals on the EVENT structure and wire the REGISTRATION REFNUM to the Dynamic Event terminal. Then create a case for the MOUSE DOWN? event, and another case for the VALUE CHANGE event.
Put your code to POP UP into one event case, and your code to handle VALUE CHANGES into the other. You have a CTLREF which refers to the specific control you’re dealing with, so you can use property nodes to set the STRINGS and VALUES array, and to read the current value. You also are given the PLATMODS structure, which will tell you whether the SHIFT or CTRL keys are down. If you are dynamically modifying the menu based on those, then here’s your chance.
For a LV2013 project which demonstrates these ideas, click here. (same as link in Part III).
