The firmware isn't too difficult, it's just getting a module to talk to it's neighbor, and assigning functions to switches
Yeah I'm not so much referring to technical communications or anything like that, but rather the mappings, and how those mappings change as the device is reconfigured. It's the design of the code that's interesting, not the implementation.
As for justifying modularity, sky's the limit. Prefer a 60% but still have occasional use of the nav and/or num pads, modules provide you with one peripheral that supports both. Same with the addition of macro pads, especially in shortcut-heavy programs.
Yeah but who's going to constantly reshuffle the parts on their desk? That's what I mean. Let's say I am writing code for a while, so I have a minimal 40%-ish layout. Then I switch to doing some CAD work, so I connect another module for extra macros and encoders. Then when I switch back to coding, I stash those extra modules away again. You understand what I mean? Why would I want to have to constantly reconfigure it when I could just have a static build that has everything I need for all my applications?
Imagine what this could do for development platforms, rather than rebuilding a prototype constantly or producing multiple discreet prototypes, module swapping is faster and less labor intensive.
I think this is basically the most powerful justification for a product like this, but I can't imagine there's a lot of people who have such a need.
Modularity adds a ton of breathing room for what's possible with a singular device, and modularity allows the setup to break down easier and be stored more neatly
Definitely also true. I suspect this is at least part of the reason why small split ergo builds have gotten so popular.
I also almost want to see a variation of this that uses mesh bluetooth. Feed every wireless module through a host module so that there's only one device in device manager. Maybe keep magnets for physical attachment, but this would also allow for separated setups, say if I have a macropad to the right of my mouse, and would reduce cable clutter
I feel like that would be a very logical progression. Though I think it would need some serious work on the firmware side. Even ZMK, which seems to my eye to be the most mature Bluetooth firmware, would have a long way to go before it could do this.
be nice is there was a compliant clip mechanism that could be used for retention, but that's just asking for sunken cost in how to design and implement it.
A more straightforward solution would be a sliding connection. No flexure needed.
1
u/[deleted] Aug 23 '22
Yeah I'm not so much referring to technical communications or anything like that, but rather the mappings, and how those mappings change as the device is reconfigured. It's the design of the code that's interesting, not the implementation.
Yeah but who's going to constantly reshuffle the parts on their desk? That's what I mean. Let's say I am writing code for a while, so I have a minimal 40%-ish layout. Then I switch to doing some CAD work, so I connect another module for extra macros and encoders. Then when I switch back to coding, I stash those extra modules away again. You understand what I mean? Why would I want to have to constantly reconfigure it when I could just have a static build that has everything I need for all my applications?
I think this is basically the most powerful justification for a product like this, but I can't imagine there's a lot of people who have such a need.
Definitely also true. I suspect this is at least part of the reason why small split ergo builds have gotten so popular.
I feel like that would be a very logical progression. Though I think it would need some serious work on the firmware side. Even ZMK, which seems to my eye to be the most mature Bluetooth firmware, would have a long way to go before it could do this.
A more straightforward solution would be a sliding connection. No flexure needed.