[chirp_devel] #112: Memory bank support for VX-8

Jon K Hellan
Wed May 18 00:10:22 PDT 2011


On 05/18/2011 01:57 AM, Dan Smith wrote:
>> +    # Return channels for a bank. Bank given as number
>> +    def get_bank_channels(self, bank):
>> +        nchannels = 0
>> +        size = self._memobj.bank_sizes[bank]
>> +        if size<= 198:
>> +            nchannels = 1 + size/2
>> +        _channels = self._memobj.bank_channels[bank]
>> +        channels = []
>> +        for i in range(0, nchannels):
>> +            channels.append(_channels.channel[i])
>> +
>> +        return channels
>
> This is so that we can present the user with a list of channels
> belonging to a bank, right? I.e, they want to create a bank by tagging
> channels into it instead of marking the channel with a specific bank...

We need it no matter how the UI ends up. It's the most natural way to 
decode the bank membership information in the image. In turn, it can be 
directly mapped to a spreadsheet like channels by banks layout, or 
something different.

>
> So, maybe we need to change the UI to not allow per-memory bank editing
> for any of the radios, but rather make the bank editor more robust, and
> capable of handling the one-to-one and one-to-many bank models.  I'm
> definitely in favor of a unified workflow in the UI. We'll just need to
> change the current bank-supporting drivers to return banks of memories
> (like you have above) and declare whether they support one-to-one or
> one-to-many.
>
> Sound reasonable?

It does.

I've seen two different approaches:

- A separate tab for mapping channels to banks
- Two different views in the channel editor, one with a column for
   each possible bank, and one with columns for the other channel
   attributes.

 > I can try to hack some of the UI changes up in a
 > prototype patch if this seems like a good path forward.
 >

Looking forward to it.

Jon LA4RT



More information about the chirp_devel mailing list