How the keypad should work, and how to configure it.

Olfried2 commented 3 years ago

continued from issue 2 I did some research and made some notes. Here's the result.

The device should be able to:

send single chars via USB to the computer (receiver)
send keystrokes like CR\LF ALT-ENTER CTRL-PRTSCR via USB
send text via USB (size to be defined)
send actions which enables you to execute different commands on one keypress
to use layers (where different chars, texts, keystrokes be stored) _Could be obsolete, see later._The "layerswitch" has to be configurable (which key on the keypad should act as toggle)
be used in/with foreign (not english) languages
light up configurable LED's in conjunction with the pressed key
Should be able to act as midi-device (the midi-commands exclude "sound-generating" ones, no notes - just commands to control a midi device like start, stop change octave ...)

Configuration

I'm sorry that I couldn't describe my earlier idea about the config process precisly. So here's my second attempt. As this gadged is only used local, I would prevent a big API. Everything is on board of the raspi The config file will be written by the "frontend-webserver" and saved (copied) at the arranged place. So if there's any new paragraph in the config file, the "frontend-webpage(s)" could be easily enhanced. It could be possible to store older configs somewhere to use them again. The frontend stops(kills) the actual python program and starts it again, the new config will be read and used. This could also be used as a layer-switch. The frontend could be used to show informations about the config.* and let the user choose. This would be close to switch layer. The python program reads the text-config.** in an array and prepares and sends the content when the associated key is pressed.

If we are in midi-mode the configuration files looks similar except that the commands are different and the config is called midi-config.**. (meaningful Midi commands are to be investigated)

Configuration files

I found a webpage where the author shows several types of config files https://martin-thoma.com/configuration-files-in-python/ My favourite is the xml-like config (I have a web background) which looks like

<layer 1>
    <key>
        <number>1</number>
        <content>my email@foo.com</content>
        <led_no>5</led_no>
        <color>FF0000</color>
        <brightness>512</brightness>
        <blinky>20</blinky>
    </key>
    <key>
        <number>2</number>
        <content>something I have to type often</content>
        <led_no>2</led_no>
        <color>FF00CC</color>
        <brightness>512</brightness>
        <blinky>3</blinky>        
    </key>
    <key>
        <number>3</number>
        <content>ALT-ENTER</content>
        <led_no>2</led_no>
        <color>FF00CC</color>
        <brightness>512</brightness>
        <blinky>20</blinky>
    </key>
</layer1>

Also possible JSON

{
    "layer1":{
        "key1":{
            "content":"my.emailo@foo.com",
            "led_no":"5",
            "color":"FF0000",
            "brightness":"512",
            "blinky":"20"
            },
        "key2":{
            "content":"my company footer
            with several necessary
            topics and of course spaces",
            "led_no":"6",
            "color":"FF0000",
            "brightness":"512"
            "blinky":"20"
              }
         }
}

just my 5 cents on config files Another problem of the keypad would be different languages and different keyboards see issue#4

eltariel commented 3 years ago

Questions:

Why a separate config for 'midi mode' and 'type mode'? The USB interface supports both 'modes' in parallel, and since everything else is common between the two modes just mixing the action types in the same file would be more logical.
Do you expect that each key will be able to light up its own LED, or just one LED somewhere on the board? If keys should light themselves then the key->led mapping should be static and not messed with by this configuration. Also you'd need to map the GPIO used for each key somewhere as well, and that should never change with this config.
Why are you so keen to tear down the entire world just to change what a key does? It makes more sense to let the main program swap out the handler for a key and keep all of the rest of the state intact, and it would mean you'd never have weird pauses waiting for everything to reload. And you'd lose any lighting effects that were running at that time.
Any particular reason for limiting a key to doing just one thing at a time? The code literally allows you to turn a light on, do a web request, type the result of the request as a string, then do a small light show... all from a single key press. Maybe we'd be better off having an 'actions' parameter that can do whatever.

Olfried2 commented 3 years ago

Why a separate config for 'midi mode' and 'type mode'?

Didn't know that this is possible.

Do you expect that each key will be able to light up its own LED, or just one LED somewhere on the board?

The LED's should be lightened independently. For example if you send the midi-code for play the LED's could show a "triangle" when you record the LED's could blink red and so on. (just ideas what to do with the LED's) For me, the LED's are only a goodie, not a must.

Why are you so keen to tear down the entire world just to change what a key does?

My motivations are a usable Keybow. So the easiest way in my opinion is: restart the program, read the config, work. Restarting the python program shouldn't take a noticeable time ? (will check it with the actual njak.py DONE) -> It's less than 2 seconds.

I must admit, changing only one key has it's charme, especially now that I learned that the program can do "actions". Which leads to a more complex program (if not already implied) and of course a different config.

How will the program know that there is a new config?

_(I'll edit the specs to add the 'actions' topic)_DONE

eltariel / njak