What features would you add to Soarer’s / Hasu’s Converter?

[orihalcon]

Soarer’s Converter and Hasu’s Converters are awesome, but what features would you add to one or both if you could?


I have couple to start off:


SpaceFn to Soarer’s Converter

Mac Specific Keys like the Apple Fn Key - Hasu has a page describing how this would work, but not sure it is easily done

Bluetooth

Solenoid Support


Others?

[alh84001]

Maybe off-topic but I deal more with controller's these days, and what I'm missing the most from hasu's is actually not concerned with keyboard functionality but with workflow:
- soarer's controller has custom tool to upload keymaps, which with Pro Micros means I don't have to play with RST pin to reset to bootloader and then hunt for a tty device
-defining a matrix is a bit easier in soarer's, especially if columns and rows are spread across non-contigous pins

[Phenix]

I second Soarers programming workflow - would be nice if TMK/QMK would add this as well.

A "addon" bluetooth module had be interesting, exspecially if they were preflashed..

[JBert]

- The ability to set and recognize device IDs.

While Soarer's tools are brilliant, I've had it happen a few times that I was reprogramming the wrong device because every one of my keyboards contains a Soarer controller / converter, and you don't always think about which ones are connected.

[Phenix]

Soarers would be even better with tap-dance and oneshot-mods

[Daniel Beardsmore]

Is there a prize for the best idea? Do you know something about Soarer that we don't?

[Arakula]

- soarer's controller has custom tool to upload keymaps, which with Pro Micros means I don't have to play with RST pin to reset to bootloader and then hunt for a tty device

I always replace the boot loader on the Pro Micros with Grendel's. It's smaller and it doesn't have that pesky 8 second timeout. Of course, replacing the boot loader means that you need an ISP programmer, but these are cheap (if you want to go extra-cheap, you can use one Pro Micro to program the others. People have done that already; see here, for example. The AvrISP II clone in the LUFA archive might work as well).

[Norman_]

Bluetooth would be really awesome. Hasu USB-USB converter with bluetooth would have a ton of uses.

[paecific.jr]

A gui

[Phenix]

A gui

A GUI option Is better, many like code more than a GUI..

[pixelheresy]

Tap vs longpress.

I re-converted my IBM Model Terminal to use TMK instead because I did the whole Caps as Ctrl thing, but if I tap that, it's ESC. Which is awesome. Basically Ctrl and Esc is easy reach for VIMmy goodness.

[Sigmoid]

Correct me if I'm wrong, but Soarer's is practically dead in the water, it's closed source and abandoned (Soarer has been MIA for years). So no new features to expect there...

TMK seems to do all the things Soarer's does, though...

[paecific.jr]

A gui

A GUI option Is better, many like code more than a GUI..

If it could be where you could do general mapping with a gui then push a button to flash it, that would be a huge improvement in the usability. You could even add in a way for people to modify the code or import their own!

[seebart]

Yeah a GUI would be great.

[Chyros]

More protocols!

[depletedvespene]

More documentation, before anything else (including "recipees" for certain things and "typical" reconfigurations for some known models). As I've been writing down some of the stuff I've been doing, I can help with this.

[seaworthy]

Some of you may know, others not, there is a GUI for Hasu's controllers...

http://www.tmk-kbd.com/tmk_keyboard/editor/unimap/?hhkb

[orihalcon]

More protocols!

Hasu's pretty much has everything already

Which protocols would top your list to add to Soarer's Converter?

[Chyros]

More protocols!

Hasu's pretty much has everything already

Which protocols would top your list to add to Soarer's Converter?

Hmmm, maybe I'm messing up converter names, but there's lots of ones I can't convert yet, like Fujitsu (I'm sure they used multiple ones actually), Sun, that AWX thing, Amstrad, basically all Hall effect boards, etc.


On a side note on your own converters, having a reset pin integrated would be a useful feature, that way you could do the Z-150 and DC-2014 etc. with it as well .

[hansichen]

Correct me if I'm wrong but I think that you have to compile the software for Hasus converter if you use a self built one made with a pro micro. So the UI interface is only partly existing

[alh84001]

More protocols!

Hasu's pretty much has everything already

Which protocols would top your list to add to Soarer's Converter?

Nitpicking, but It would be nice if hasu's had support for PC-8801 and Xerox Docutech.

[depletedvespene]

Could we add/define "generic" pseudokeys to act as a sort of arguments to macros?

Allow me to explain with an example; as we know, we need to work on the layouts on two distinct levels, physical (with Soarer's Converter, to be programmed with a .sc file), where we think in terms of the actual keys being pressed and national/customized on the OS (with a .KLC file to be used on MSKLC), where the keys that have been pressed are sent to the OS, which then decides to produce a certain (Unicode) character(s) based on that.

I want to have a secondary side keyboard that will allow me to type Greek characters, while the main one keeps its usual layout. To this effect, on the upper (OS) level, with MSKLC, I've defined AltGr-G as a dead key that will produce those characters (AltGr-G+A → α, AltGr-G+Shift-S → Σ , etc). On the lower level, I could add a macro like this:

Code: Select all

  macro A
    PUSH_META CLEAR_META all
    MAKE RALT
    PRESS G
    BREAK RALT
    POP_ALL_META
    PUSH_META CLEAR_META alt
    PRESS A
    POP_ALL_META
  endmacro

Or, actually, 26 macros like these, from A to Z (and perhaps a few more, come to think of it). Cumbersome, right?

And it could become worse, if I decided I need to have, say, four layers for four languages on this side keyboard, each supported with a distinct dead key at the OS-level layout.

This could become much less cumbersome with pseudokey constants that stood for any of a certain group (in a similar fashion than what already happens with SHIFT, that responds to either LSHIFT or RSHIFT). We could define, for starters, ATOZ (any of the A..Z keys), ONETOZERO (any of the 1..0 keys), ALPHANUM (A..Z, 1..0, MINUS, EQUAL, LEFT_BRACE, RIGHT_BRACE, BACKSLASH, SEMICOLON, QUOTE, BACKQUOTE, COMMA, PERIOD and SLASH), ALPHANUMISO (as before, plus EUROPE_1), and several others. This way, I would need just one macro, like this:

Code: Select all

  macro ALPHANUM
    PUSH_META CLEAR_META all
    MAKE RALT
    PRESS G
    BREAK RALT
    POP_ALL_META
    PUSH_META CLEAR_META alt
    PRESS :ALPHANUM: # Be my guest to suggest a better way of making the backreference.
    POP_ALL_META
  endmacro

to cover all my bases.

We could even allow user-defined pseudo keys. For example, my .sc file could define IBERIANKEYS to respond only to A,E,I,O,U,L,M,N,R,S and IBERIANDEADKEYS to respond only to B,C,D,G,T, allowing this to require only two macros instead of 35.