So, I think the way to handle this is to expose these memories as "special channels" with everything marked as immutable. If they're not actually in the memory image, we'll just need to store all that data in the ft1d.py file, and return them as memories when requested. Then we can expose those in the memory editor, but they will be un-editable if everything is immutable. That way they can show up in the bank editor (more work may be required here) and then we can reflect those mappings and allow them to be changed.
Does that sound like a plan?
Yes, that sounds quite plausible; I had even experimented with something similar in an earlier toy version. But i had the wrong idea, thinking they were memories and not bank entries. Thanks for the thought you put into this to help me avoid playing with my own mental blocks!
How does CHIRP-next GUI handle specials? The old GUI had a way to hide and show specials; Yaesu has some 150 pre-defined addresses! With the thousand memory locations already in the radio, that’s a lot of scrolling (especially since we also cannot hide undefined memory locations now.)