So, Renoise is basically seeing the padKONTROL as multiple devices? How is this being split up - does the pads register separately from the buttons, etc?
I’m asking because this could be something we’d want to look into.
Duplex right now is assuming that a device is registering as a single port - and a configuration (running any number of applications) is then tied to that device. You can of course run multiple configurations, but then the various applications are running as separate instances, independently from one another…
I’m not entirely sure I get you here - you want to hide certain elements because they take up too much screen real estate, or? I mean, you would only add an on-screen control when it’s supposed to be manipulated somehow…
If it’s a matter of size, I’m sure you know that the on-screen UI can always be closed, and Duplex will continue running in the background (in the new version, it’s even easier: you can now toggle the virtual UI on/off by pressing TAB, but still leave the basic options visible).
The Device class really is quite abstract as it is, the only MIDI/OSC specific code is for creating “settings” dialog - so, just some ViewBuilder stuff. They could of course be refactored into their respective classes, but I hardly found it necessary to do so. Messagestream is also quite abstract - when you see “MIDI” there, it might be because an OSC message actually has a MIDI message as “payload” - as these messages are handy for describing a note event.
The Display class on the other hand, is a mess. It definitely needs critical review 
Actually I just put up the latest bunch of changes on the Renoise SVN - I think you will benefit from the new code comments, I literally spent days tuning everything to the “ldoc” syntax.