Macro recorder (button sequence record/playback)

[NotherNgineer]

Description of the feature you're suggesting.

I'm proposing a macro recorder/playback utility app that can record physical Portapack key presses and then later play these back with similar timing.

Considerations:

1. Macro playback could possibly leverage existing serial port control of Portapack for injecting button presses.
2. Support for Touchscreen presses is optional (I don't think it's actually required since everything can be done using the physical switches).
3. Options in the app might include "Record", "Stop", and "Playback". User would enter a new macro file name when starting new macro recording. For playback, user would select from a list of macro files stored in the app-specific folder. An SD card would be required for this app.
4. The macro buffer would likely need to be held in RAM to prevent file I/O (except when saving & loading the macro file). This is to prevent interference with file I/O from apps that are running while the macro is being recorded & played.
5. To limit the macro buffer size in RAM, the time between button presses probably doesn't need to be too precise, perhaps 1-2 bytes is sufficient (for example, perhaps 1/4 second accuracy up to 16383 seconds).
6. I think it's OK if macro recording & playback can only be started & stopped from inside this new utility app. Probably the first recorded button presses will always be to exit the macro app and navigate to another app.
7. Navigating from one app to another does not always require the same number of button presses since apps are not in consistent locations between firmware versions. Thus, the macro recording will need to keep track of which app(s) are started while the user is navigating the menus (and bail out during playback if the app no longer exists).
8. When recording button presses inside an app, we might just need to assume that the app hasn't changed substantially. If it has, a recorded macro may not function correctly. Also, if the steps in the macro tell an app to open file manager and hit the down key 3 times to select a file, we'd probably just do that despite that the file list may have changed since the macro was recorded. That's OK IMO.
9. Playback steps in a macro could include loading another macro, at which point the executing macro should stop and the new macro would take over (no recursive macro playback).
10. Macro recording/playback could also be done entirely on a connected computer via the serial port, but in this ER I'm proposing a utility app that runs solely on the Portapack without needing a additional computer hardware attached.

Anything else?

Example use case: There are certain transmit apps that one may not wish to be transmitting continuously when doing radio range testing, etc.

[eried]

It sounds nice but this idea is the start of a pandora box 😬. The moment there is some button/touch recording, you would want tweaking that recording, then some debugger of the macro playback, etc. The easier workaround would be a simple arduino/esp32 usb-host board, which would already work on an unmodified firmware.

Could you elaborate on the use case? like what type of testing and what will the macro do?

[htotoo]

we could add it to hackrf.app site. there is a macro player already, so a macro recorder would be easy.

[NotherNgineer]

It sounds nice but this idea is the start of a pandora box 😬. The moment there is some button/touch recording, you would want tweaking that recording, then some debugger of the macro playback, etc. The easier workaround would be a simple arduino/esp32 usb-host board, which would already work on an unmodified firmware.

Could you elaborate on the use case? like what type of testing and what will the macro do?

Mainly I was trying to think of a way to add a delay before transmitting and to limit the transmission time, utilizing a generic method that would work with ANY of the existing transmit apps. For example, for a Foxhunt transmitter a HAM can use the existing Morse app and it supports a delay between transmissions but it only transmits morse code (also the delay time isn't very flexible but that could easily be fixed). To support intermittent VOICE transmissions instead, one could modify the Replay app to add a delay and/or maybe modify the Soundboard app to add a delay, but then someone might theoretically want a delay in other TX apps as well. Maybe that would be easier to modify each app as needed to add this functionality, IDK. I don't think most users would be able to add a "simple" usb-host board to do this (and personally I'd prefer a self-contained solution).

[htotoo]

JS framework :D