Feature analogin

[piman13]

Added sensitivity to reduce noise on inputs making events on mass
Updated and fixed docs to add sensitivity and fix issues with AnalogInputs example

[regicidalplutophage]

I've been writing a wall of text about how this should be more of a backbone for more application-specific modules like MIDI, and now you made a change to midi.py so I hope you provide a good application.

Other criticisms is that the AnalogueEvent should belong to those application-specific modules, for example we can derive midi velocity from AnalogInput's delta property and we should support scanning inputs of a demultiplexer so that we won't have to add 12 ADCs per octave.

The functionality of the AnalogueKey should belong to a scanner. Such scanner should take an "input map" and a "threshold map" so that it can produce matrix changes which would allow it to integrate well with keyboard features of KMK.

Someone has already made a hall effect keyboard with KMK BTW.

Other applications may include gamepad with its thumb sticks and shoulder triggers and drawing tablet/digitizer whose coordinates can be derived from the same thumb stick.

This applies to #1054 as well obv, but I think that was the point of that draft: "here's an example, if you can apply it, then we can think of merging it."

[regicidalplutophage]

Aside from using hall effect sensors to play notes, another way to use this musically would be to use piezo discs as a drum pad.

[piman13]

Sorry about the change to midi.py
it was out of scope and I should have made a separate pull.. draft. this is like the first time I'm using git for anything more than downloading
the issue with midi is it was not sending the channel number as pulled from adding channel=#. this was not documented in midi.md so likely was never tested or an update to adafruit_midi broke it.

[regicidalplutophage]

Sorry about the change to midi.py

Yeah, no, my point is that something like that would be the reason to merge, so please, by all means go in that direction.

---

Like, at first your concern was with the minutia of an abstract module, when what it really needs is an application.
Basically, you wanted to use this for a reason, so make what you want to make with it and make it well enough so others can use it.

[piman13]

Ah that's kinda been my direction with getting this moving in the first place as I have a macro-pad I built that I want to make or use software like midi mixer to control application volumes using primarily or only open source software

[piman13]

ok I have now learned what an analog multiplexer is lol, kmk just could become a platform to make midi boards quickly and simply if done right. that would be cool.

[regicidalplutophage]

It could, but hardware-related features take some effort to assess properly, so contributors have to be willing to provide justification for these features so that KMK won't maintain more code than it has to.

Something you can focus on is providing first class support for analog scanners in the MIDI module and documenting these changes. That support would of course rely on that abstract analog module.

[piman13]

ok so learn then implement scanner to replace AnalogueKey ,
update and improve support for midi on kmk
make better docs for midi other than some keys that don't explain anything

and off and on side project of adding to rgb.py for perkey support (side project)

so then we are targeting a generalized analog class of key/input method that other extensions/modules can use and emit too (eg midi can receive into the keyboard and change leds or turn them off. common feature on midi boards)
cool Ill see what I can do...

[regicidalplutophage]

You know what, hold off on the scanner. I wouldn't feel good about greenlighting it when neither of us can test it with a HE keyboard. Same for demux -- that would also need real hardware first.

Just make it so that knobs and sliders are immediately useable with MIDI.

[piman13]

Got it almost done but didn’t know where to get it’s index from :/
(HE? What does that mean in this context)

[piman13]

Oh Hardware Environment isn’t it
Well if that is the case I might have a dumb idea..
I can only really test slide potentiometers with my setup so honestly I can’t account for even most of the possible hardware without making some specifically for this project… but you had some neat ideas with the midi and connecting discs as a drum-pads and other stuff like joysticks and tablet digitizers

should we make a design for a midi board that covers most of the stuff we would need in analog. And if we make it right it could be good enough to sell as “kmk certified” board lol

either way I do think there should be more input for a broader use case. Like someone who wants to make midi boards, custom input boards like the xbox accessibility thing.. i think if we did do this though we should look at other possible modules so we could make the ultimate test platform for this

just an idea might be kinda to large of an idea but still an idea..

[regicidalplutophage]

(HE? What does that mean in this context)

Hall Effect, like the one I linked near the beginning of this discussion. That's because in such board analogue scanning is used for actual typing which is the hardest thing to get right and is the ultimate goal.

either way I do think there should be more input for a broader use case.

Ideally, capacity for expansion should be a function of good design.

You can come talk in KMK Zulip if you want to discuss more experimental stuff like piezo discs.

[regicidalplutophage]

@Maka8295 do you want to upsteam your analogio scanner?

[Maka8295]

Hi! I'm very new to GitHub so I'm not sure on these things but yes! Please take what you need from my project :)