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.
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).
First of all, I think subpatches are a really good idea. But it can be a pain working with them. There are some things not working 100% with them.
Example:
Working on a Blofeld editor and I have made 16 parts, each made into 16 subpatches. Had to reduce modulation sources and destinations to zero for the main patch to compile at all. But now it works. But I cannot add anymore subpatches to this patch. Everytime I make a new instrument I try to compile it into a subpatch and it wont work. SRAM overflow. Argh..... I made sure that there is NO subpatches within subpatches and ALL subpatches has reduced presets to 0, entries to 0, etc. . If I load it NOT compiled into subpatch it works. Compiled to subpatch, it wont work..... So I use subpatches for a few things, but most of the stuff I make, I drag it out of sight, all the way to the right. As long I keep everything in the main patch I dont ever get SRAM overflow.
Using this method I have encountered another issue. If you drag objects far enough to the right side you will notice than the objects at some point gets invisible. It seems like the space of the editor is defined and if you go beyond this definition the objects get invisible. They work but you cannot see them.
Anyway after having A LOT of SRAM overflows, I finally managed to get a good work flow and find out how to build things and not hit the SRAM overflow all the time. That has been a huge headache, but finally I can focus on patching and not troubleshooting
Allhough there are a few issues I think Axoloti is really awesome. Specially as external sequencer and for sampling. These are my main uses for Axo.....
@alex yes, I program reaktor so know what Reaktor macros are...
but the context was not given in the FR and given @alexk description, I don't think he means reaktor macros anyway....his seems to be about keyboard shortcuts to subpatches?
this is why I don't like making assumptions, labels are confusing,as people have different backgrounds/requirements/expectations.
im not interested in the naming/semantic discussions... thats just what johannes chose to call them, and I can live with it.
apart from that I don't see what elements of Reaktors macros you see that are fundamentally different from a subpatch. (excluding polyphony which axoloti has a generally different model to Reaktor, which would be hard to change)
of course max abstractions (vs patches) /reaktor macros have UI implications, but that will change in axoloti if/when we do a presentation mode
we actually decided not to distinguish between AXS and objects, as for an end user it doesn't matter... its an implementation detail. if we do some kind of general colour scheming then yeah, we could make this a preference.
(note: if you are doing as recommended i.e. using ./subpatch, subpatches are obvious, it gets not clear when on search path... but thats because we want them to look like objects)
@jaffasplaffa
sub-patches as such are not related to SRAM overflows... you are just reaching the limits of resources available on the board (actually there is a possibility for a bit of an improvement here, but its unrelated to subpatches!)
as Ive discussed with you, certain features of subpatches will use memory... so I think we could do something in the UI here, where perhaps the defaults didnt use memory.
(e.g. make it so a patch has zero presets/mod sources, and you have to explicitly add them)
so lets not confuse this as a subpatch issue... however this functionality was represent/implemented in a UI, would still cause you SRAM issue... i.e. implementing an alternative to subpatches would solve nothing... so we need to look at the underlying issue.
BUT remember there are limits to the Axoloti Core board... its a 60 euro board, not a 1000 euro laptop
(my solution ... buy more boards, so its modular in a physical way too... hopefully we will make the ue of multiple boards more seamless as this becomes more common)
sub-patches disappearing.... sounds like a bug.
there is a limited workspace area (its pretty big), it sounds like you can drag outside this...
perhaps raise a bug, with some explicit directions on how you do it...
I assume it can be done with any object, not just a sub patch.
Technobear: I have a few answers for your post:
"sub-patches as such are not related to SRAM overflows... you are just
reaching the limits of resources available on the board (actually there
is a possibility for a bit of an improvement here, but its unrelated to
subpatches!)"
You say that SRAM overflow is not related to subpatches? Then how come lowering amount of presets, mod sources etc in a subpatch will make a patch compile and remove the SRAM overflow? SRAM is related to amounts of presets, etc. and therefore it is also related to the use of subpatches.
But with your help I surely got a lot more out of the Axoloti by lowering presets etc. but STILL at some point I get the SRAM overflow anyway, but mostly when I compile a bunch of objects, which is working when loaded in mainpatch, into a subpatch.... And I am no were near 100% limit, only 10% DSP used, so I am not reaching the limit. If you run out of SRAM after using only 10% DSP, it tells me the relation between DSP and SRAM might need to be checked up on. Anyway, as mentioned your tips did help a lot and I get a lot more out of Axoloti 
Thanks again
About alternative to Subpatches. I didnt ask for something like this. I just point out that there might be something to investigate in the relation between subpatches and SRAM overflow. No need for alternatives.
About the object disappearing:
That has nothing to do with subpatches. Sorry I mentioned in same thread. I wrote that when I DONT use subpatches and move all the object out of sight they disappear at some point. Anyway, I can live it with, it is a small thing, just thought I would let you know. I will recreate it and find out how to post to Github. Havent done that before.
Also sometime I get the feeling that you think I am criticizing Axoloti. I am not. I think it is really awesome thing to do a project like this. I really applaud people who can think for themselves and make things like this, with out cooperative financing or funding. I think Axoloti is one of the best things ever happened to my studio Don't take any of this as critique if you do, then at least look at it like constructive critique. It is actually help to make the platform better or easier to understand for everyone. I know as a single developer it might seem daunting that users point out errors or problems, but that is just part of it, right? We all want to make Axoloti better for everyone. Atleast that is my approach. And almost every time i get the chance I compliment those who made this a reality. Not just Johannes but also you, You are very helpful and knowledgeable
Nah, I think your misunderstanding... I don't view it like that , and wouldn't even mind if you were (cant speak for @johannes ) , and also I should probably point out Im not trying to defend axoloti. its a normal part of the development process
When someone reports something they think doesn't work or thinks should be done differently, or a new feature, there are two critical things that must happen
at this point you can have a reasonable dialog and work out what needs to be done, without either the risk of confusion and misunderstanding is pretty high. (also me vocalising, also gives johannes a chance to chime in, either with his own views, or to correct me etc.)
so hopefully in this light your will see my replies (if i get the tone right, not always easy!) , really are trying to nail down the problem into the right area...
so coming back to the SRAM vs subpatch...
subpatches have functionality which can increase memory, this includes presets/modulation sources/ voices ... but we know all this, this is not a bug, its functionality, as i said....
i.e. we still need this functionality (no one is asking for mod sources to be removed), but perhaps the current defaulting implementation leads to a bit of bloat that can be removed, by altering the defaults... but in a way that means we don't cause other problems (e.g. users not knowing why it wont save presets because the patch is defaulted to zero presets)
there may be other possibilities to... e.g. perhaps some of these things don't need to be at the sub-patch level, or are defined incorrectly at 'voice level' (I'm thinking presets mainly.. but need to check we don't lose functionality)
so I repeat, Its not about criticism of axoloti or not (I think SRAM usage is always something we will hope to improve... and is likely to be a 'continual' effort, trying to eek more and more out of the board)
its about (as a developer) trying to determine where the problem really lies, and the best way to solve it, and i think its useful to discuss this in the open.
p.s. it should probably be noted, a useful/simplying feature in axoloti at present is subpatch are really just patches, making them different to top level patches could make things a bit more complex for coding.
EDIT:
unfortunately, it doesnt work like that...
CPU usage vs SRAM usage are not related and never will be ...
you can create a huge delay line, that will overflow SRAM, and would use 1% CPU... alternatively, you could crreate an oscillator bank that will use virtual no SRAM and be at 110% CPU...
resources are fixed, but they are not related, and depending on your project you are very likely to run out of one before the other. (there are other fixed resources, e.g. midi/usb traffic which would also become a 'sticking point')
so... the deal is over time, to optimise all these things, but there will be no 'one magic fix' , the changes could/will be all over the code base.
disappearing objects again, if you can reproduce, let us know. its worth getting rid of these kind of issues, and sometimes its not too tricky.
drag n drop subpatches ending on some good newss
Ive just checked into github (awaiting pull) a change that allows subpatches to be dropped onto patches.
Note: really you should only drop from a directory on your search patch or relative to the main patch.
as otherwise when you reload the main patch, it wont find it... this is due to the fact axoloti assumes ALL sub-patches/objects are relative to main patch OR are on search patch. this may be something we can refine BUT really its very bad practice to be linking to objects arbitrarily on your disk
Here is an example of the patch window limit. Scroll all the way to the right side and you will see a half "dial" knob. That is where the patch window ends. Have posted it on Github:
https://github.com/axoloti/axoloti/issues/246
Patch window limit example.axp (510 Bytes)
yes the limit is 5000 , and you are at 4970 so yes you went over the edge of the world:)
my guess is you can have drag it so only one pixel is viewable... which would be probably then obscured.
really we should stop the drag, at 5000-width of component.
don't think Ive ever been that far over on the canvas .