Questions about commit

[rayluo]

First of all, some context here. This Serial API doc mentions caution against commit.

Parameter and keymaps changes, when committed, will degrade the flash chip over time ... If you plan to programmatically change layouts, for example, you shouldn’t commit the changes unless you need them to persist after power loss.

Chords are stored on external flash ... and is less of a concern.

I can see that this charachorder.py library provides an explicit commit:boolean parameter for most of the setter methods, but not for chord-relevant methods. Some of those chord-relevant methods (such as delete_chordmaps(), append_starter_chordmaps(), append_functional_chordmaps()) has docstring explicitly mentioning that they will always commit, but the set_chordmap() and delete_chordmap() does not mention commit behavior.

Q1: Do set_chordmap() and delete_chordmap() always auto-commit, too?

Q2: If I programmatically add for example 1000+ chords (such as those defined in CharChorder Builder), does that incur 1000+ commits? That can easily be 3 magnitudes more than one would change the keymaps and layouts. Shall I also make an effort to minimize the set_chordmap() and delete_chordmap() calls?

Q3: Is there a "no commit" mode for me to frequently test out different chords which are meant to be lost after powering down?

Q4: By the way, where do the chords of append_starter_chordmaps() and append_functional_chordmaps() come from? Are they hardcoded in the firmware? Are there any docs or source code somewhere listing what those chords are?

[GetPsyched]

cc @Raymo111 @jdestgermain

From what I can recall,

1. Yes and no, they do auto-commit in the sense that they make persistent changes, but committing is a concept only meant for parameter and keymap changes (for the VAR sub-commands on a lower level).
2. As mentioned above, those commands don't commit; and in the docs that you quoted, it mentions that chords are stored on an external flash which doesn't degrade the chip nearly as much.
3. There isn't one; but if there's a decent use case for it, I'm not opposed to add it.
4. AFAIK they come hard-coded in the firmware (likely updated across different versions) and there are no docs/listing for it yet.

[Raymo111]

I'm pretty sure what Getpsyched said above is right, but John and @Theaninova can confirm for sure.

[rayluo]

Thanks @GetPsyched for the quick reply (and creating relevant new issue(s) for tracking purpose).

With regard to

Q3: Is there a "no commit" mode for me to frequently test out different chords which are meant to be lost after powering down?

3. There isn't one; but if there's a decent use case for it, I'm not opposed to add it.

It might not be a perceivable or tangible use case but, based on my own first-hand experience of using "thumb drive" (which also uses flash chips), they do wear out within merely several years. While thumb drives are cheap to replace, the data loss would typically go unnoticed for a long time and the troubleshooting were unpleasant. In Charachorder's case, the device is not cheap, unless its flash storage becomes replaceable by swapping a TF card.

All that being said, you seem to hint that there is indeed an "in-RAM" mode on the hardware? If that is the case, exposing that mode in this SDK becomes a no-brainer. :)

[GetPsyched]

Ah, so what you're requesting is essentially something that would go along the lines of:

1. Connect CC device with stock settings
2. Run a command/method that loads custom settings but don't commit them
3. Use CC device
4. Repeat above steps whenever connecting it again

cc @Raymo111 @jdestgermain @Theaninova again to weigh in their opinion on how viable this is independent of the inconvenience.

Code-wise this shouldn't be much of an issue I suppose.

[Theaninova]

I'm not sure if I follow the conversation correctly, chords need to be stored on flash by design. Just storing them in RAM is not possible because opposed to settings and layouts they are never held in RAM unless immediately needed. Especially the older M0 devices are very heavily constrained in memory, and moving chords to a RAM-only mode might constrain them to only a few hundred chords.

That being said, there is something we are trying out internally that could benefit from an in-ram mode which as a tradeoff constrains the amount of chords you can have, so there might be the possibility we add this at some point, but please level your expectations of what is possible.

[rayluo]

"A few hundred chords" are already plenty to enable some different use case. Not every user is going all-in to chord every words in a dictionary (well, at least not initially); some may already be a fluent touch typist who wants to add only hundreds of long words and phrases in his/her field.

[GetPsyched]

But chords are fairly cheap to store anyway; wasn't it the commits we were worried about?

[rayluo]

But chords are fairly cheap to store anyway; wasn't it the commits we were worried about?

Well, because the docs in this library mentions "commit" on chords too, I thought the commit concept was also applicable to chords. But now I can clarify.

1. The initial ask of this conversation was about saving chords into RAM. If a use case is potentially swapping hundreds or even thousands of chords "fairly frequently", will it still be "fairly cheap"? (Is saving-chords-into-RAM even feasible? Because if the answer is no, there is no point to continue this conversation. :-) )
2. The "changing settings without commit" is a good-to-have, though not my original ask. Personally I do not feel a need to frequently change the layouts and settings.