@hesspet : The goal is to have identical patch layouts at different scales and operating systems. This is not there, because of the text flow in the objects, but certainly a goal.
Changing the font size does not change the size of the widgets.
The complication is maintaining sharp line art, and regular grids when scaling. If the grid would be, say, 16 pixels, rendered at a scale of 110%, the grid becomes 17.6 pixels, ugly... While if scaled at 125% the grid becomes 10 pixels and will look fine.
For example a checked checkbox widget uses a 1-pixel wide white border between outline and its mark, this should be kept at 1 pixel unless the scaling is large enough to use two (or even more) pixels.
So scaling the UI has a deep impact, and will affect patch layouts when it is done. I'd like to bundle this change with a revision of how parameters (and all of its states like midi mapped, on-parent etc) are visualized and enabling custom layouts of objects.
@thetechnobear I've seen screenshots from macosx with fine retina rendering on macosx. Its rendering at 200% does not introduce coordinate round-off issues.
Improvements/Wishes for the patcher
I'd love a "QWERTY to MIDI" mode (ideally with a keyboard shotcut to toggle it on and off) in the patcher for testing without a controller. The onscreen keyboard is useful but it would be really nice to be able to play notes from the computer keyboard with one hand and use the mouse to tweak parameters with the other.
Sorry I do not plan to develop QWERTY to MIDI, it 'd interfere with keyboard shortcuts, and is difficult to get right because there are many other keyboard layouts than qwerty.
It can be done with Midi-OX in Windows, I guess there are similar utilities on other platforms. Or patched in Pure Data or Max.
USB keyboard on the host port? I'm not sure about the current status. I believe most firmware work is done, but no object is made. Not very hard, but also very low priority for me. Git pull requests are welcome...
Ive just had a look at the code, looks complete to me... as its from the STM lib as part of the HID class with the mouse.
the only thing missing is in ubs_conf.c/h we would need to expose the keyb info.
the primary issue I see, is what would the object look like... as axoloti has little string/character handling, so its would be hard to make it do anything useful, without writing a UI object...
the only thing a simple object could so is output an ascii code.. and then perhaps this shift/ctrl status.
this could allow a user to press a key to do things e.g. trigger different sequences.
that would be pretty straight forward to do.
funny today, I was looking at monome's teletype... now that could be fun... I could use push LED (or later axoloti remote) , and then attach a keyboard... unlikely to happen, but who knows perhaps someone out there fancies a challenge 
How to access HID functions?
yeah, outlets for modifiers (left and right shift can be separate I believe) and keycode. ascii maybe not terribly useful, not all keys have corresponding ascii, like F1-F12, numlock, scroll lock. The main use case is keytar elektro-punk I guess
Generic HID joystick support would be useful, for flight simulator joysticks, racing wheels, or SpaceNavigator.
- Larger " Open Recent" (more then the 8 entries)?
- Drag n' drop *.axp to a new patcher window?
- Double click to open *.axp?
favorites section in top menu bar would be nice.
Nord modular patcher was quite a mess so i dont want to ever go that way - however it would be nice to have some sort of macros or something. Although it isn't that much of a problem - the current "type to find" approach is very nice.
After playing with it a while, here's a couple improvements top on my list I'd love to see sooner than later:
Custom arrangement or grouping of knobs for the 'parent controls' on sub patches.
The ability to attenuate the min/max value of the knobs by typing in custom min/max values. (For instance -20/+10 as opposed to -64 / +64 default) micro tuning some of the parameters are key to making really interesting patches. Especially percussion style sounds.
more recent.. how many? becomes a mess if too many? (I think the ordering is not good at the moment!)
Drag n Drop, not quite sure i understand this, what would we drop on? could work with AXS and has been mentioned before.
double click to open axp, yeah, issue is we need to have a windows/osx version of app to do this ( I already looked into it) ... not too hard, so will come I'm sure
favourites, I added a favourites menu some time ago (but not released yet I think), like Library... basically you specify a favourites folder in preferences, and is like library can have sub folders.
macros? not quite sure i understand this? we do have some keyboard shortcuts for some common items... making this user definable would probably be more effort than its worth.
custom arrangement, look in github/issues, I think we would like a 'presentation view', similar to max or reaktors panels.
Is that really important? It's just a number to change in the source code. A large number defeats the purpose a bit.
Drag and drop to where? The app icon?
Favorite objects?
Yes. Some discussion already here: https://github.com/axoloti/axoloti/issues/151
Yes, I understand the need. I think the hard part is keeping the UI intuitive.
My 1st priorities are fixing the high cpu load in osx and linux, and the usb3-xhci-hcd-bug
Example AB LIVE has 30 - i sometimes do work like in chapters, similar to Word, Excel.
(adding, if you pick 4 or 5 *.AXH from Library the ones you happen to be working on have gone)
*. AXP from Finder/explorer into a (new) patcher window, of course supporting *.AXS would give even greater use.
Favorites section in top menu bar would be nice
Yes - perhaps something like buttons that could be assigned to adding an object to the editor workspace. Maybe even groups of objects.
For example you select objects in your current workspace - righclick, select save to favorite 1.
when you click favorite 1 in a menu bar, the objects are added to the workspace.
This would be helpful if you constantly doodle in the editor and need to copy paste certain networks from other patches (internal sequencers, filter banks, midi mod setups)
One thing that could cause issues is Modulation Settings for the objects - not sure if it is best to allow or not allow macro settings to be saved with the macro and overwrite any existing settings in your workspace once you recall.
HOWEVER - all of this is icing. You can simply be organized and save projects with certain networks that you can reuse
ah favourite objects... ok.
macros, again id ask for clarification on what this means... (macros are different in every application).
im kind of wondering if this is all some kind of paste bank, similar to max now has.
sorry i just mean a shortcut to load an object network into the current workspace.
Maybe you could assign .AXP's to these favorites buttons and when you click these buttons the files don't open in a new window but are simply loaded into the current workspace.
but i have a feeling this could make things buggy with certain project files.
anyway its just icing!
Something that will become an issue when patches get more complicated is how to handle sub-patches.
I use a lot of sub-patches, and sharing these is complicated, because every sub-patches is a separate file.
Therefore a relatively simple solution could be:
create a type 'multipatch' which is actually a zip containing the patch+subpatches. When the multipatch is opened, it gets extracted in some /tmp folder and Axoloti will search for its subpatches there.
It is somewhat like the open-office format, where a document is basically a few XML files packed together in a zip and given a different extension.
perhaps an easy one:
a different color for subpatches and objects.
So I can see if something is a sub-patch before clicking 'edit object definition' .
Did you ever use Reaktor?
macros in Reaktor are somewhat like sub-patches in Axoloti. They are a collection of objects .
( https://youtu.be/A4wKuS-VI0s?t=98 )
However, without going too much into a semantic discussion, I would like to point out that 'sub' (in subpatch) suggests a smaller division , where a 'macro' is usually a (re-usable) abstraction of something (usually to hide the complex details).