Thanks, Dan for the prompt answer. I understand your concerns. I had hoped there might be some easy answer to add these presets to multiple Yaesu radios at one happy swoop.
I’ll probably return to the special memories model. The preset index in the radio’s memory is indeed separate from the other memory locations as are the presets themselves because they’re not contained in the _mmap. E.g., memory 0 is index 0, skip 0 is 900, scan 0 is 1000, all in _mmap, while weather 0 is 0x1000, marine 0 is 0x2000 and actually stored who-knows-where. The only marginal hassle is that it becomes a very long list if it’s filled or if one shows empties.
I do suggest that you keep the “steps” I outlined around as a starter tutorial for those who need to use sub_devices. And warn others that VARIANT may have side effects, or perhaps duplicate functionality to two variables: VARIANT and SUB_DEVICE to avoid the over-overloading.
To that end, I’m attaching my template.py that just barely works, but starts to implement the sub-device tutorial idea. Use or not, q.v.
On Nov 2, 2024, at 14:49, Dan Smith via Developers developers@lists.chirpmyradio.com wrote:
I’ve now found the sub_devices settings, and see several drivers that use them. Since the sub_devices seem to display a Memory and Banks tab for each variant, they’d essentially be perfect: there could be a “normal” variant that works the way it does presently, and a “presets” variant that only displays the data for the Yaesu-defined preset addresses. Since the driver is implementing the banks model, it should be able to handle both cases easily, and the preset memories could be marked as immutable.
I think representing these as a separate subdevice is a bad idea. The subdevice function is for radios that keep two completely independent sets of memories. Think radios that only support VHF on the left, UHF on the right or the dumb radios that inexplicably keep memories separate for the two VFOs so you have to program in every channel twice. Sidebar, I hate these kinds of radios.
I can see your thinking that this might be appropriate, but the problem is that they're not completely separate in this case and the bank editor will not do the right thing since it will assume the regular and preset memories do not overlap in banks. The subdevices are treated by the GUI as basically entirely separate radios, and it assumes there is no interaction between the two.
As I'm sure I mentioned before, to me these are purely immutable special memories. Expose them as specials, set all the fields to immutable so the user can't change them. They'll show up at the bottom of the memory editor and in the banks tab like normal. You can map them to whatever number sequence is convenient for you and give them whatever special-name you want (i.e. "Preset32", etc).
- NOT change the VARIANT definition. I thought VARIANT was being used to denote versions of the radio type (e.g. FT-1DR vs FT-1DE) rather than sub-devices. Thus most of the Yaesu drivers I’ve worked on have been overriding the value to one specific to Yaesu. Bzzzzt! wrong!
VARIANT is loosely defined and used for slightly different things in different places. It provides us a place to differentiate almost-identical-but-not-quite radios in places that we need that distinction, but where we probably want to not display that difference to the user. They're use by subdevices so that they are distinct, and they're used by some drivers that have real variants (i.e. US and EU), as well as for some cases where a firmware version bump was very significant.
--Dan _______________________________________________ Developers mailing list -- developers@lists.chirpmyradio.com To unsubscribe send an email to developers-leave@lists.chirpmyradio.com