Erm, somebody probably mentioned it earlier but I'd say that the biggest limitation I can see as a newby is the inability of the platform to run more Axolot's in parallel from one programming surface.
That might actually not be a patcher subject as such but a solution for this problem would take care of the biggest limitation in the whole system = how to run really complex patches polyphonically.
Hmm not sure that's really much of an issue. You always have compromises when using a dedicated chip rather than running stufff on your computer. If you really wanted to run something with high polyphony you could split the keyboard and send half out the midi out to another instance on a different board?
What I mean is that if a instrument becomes very sophisticated / complex it tends not to be able to provide real polyphony. Being able to run multiple Axoloti's in parallel from one software instance would cure that. Also see The Holy Grail? discussion.
I understand what you mean, but compromises have to be made if you want an embedded system running on a chip. There are only so many ARM chips and price / performance always has to be considered. If you want a more powerful system you have to go for a laptop with all the advantages and disadvantages that offers.
That might all be true as such but why resist an idea that takes the concept so far beyond it's original bounderies with no discernable disadvantages attached? Once programmed every separate Axoloti can simply be "triggered" through an individual MIDI channel. So the only real problem is to give the sofware the ability to reprogram more then 1 unit when going LIVE, even if that would have to be done in short succesion, within a few seconds or so via a USB splitter / hub. I do not see any important technological problem at all and thus: Why not?
As mentioned in my previous post, you can already do something like this with keyboard splits or manipulating midi in some ways - maybe there would be a way to do polyphony overflow or something if that's what you mean. I do think that's a good idea. But running out of voices is a different issue to not enough processing power for the patch or algorithm in the first place as in the former you're running the same patch in multiple units - I think it would be very difficult to allocate computational tasks to a separate unit to run one patch. I think you might be asking two separate things, or maybe we're misunderstanding each other 
If you want to pursue voice allocation over multiple units using the current software you could start a thread in the patching area - I only have one axo so can't really help you I'm afraid!
Doh! Yeah, we must be talking different languages. One more try: A very complex architecture may on one Axoloti only work well as a monophonic synth. So what lies nearer then to in such cases make more then on Oxiloti run the same setup in parallel while receiving different note numbers. You would of course need an additional output mixer but once the setup is in the Axoloti's the practical results would be as if you run one polyphonic synth. Only loading your setup into the Axoloti's would remain a problem. And that is the only thing I am actually asking for. To not have to do that by connecting every Axiloti to the USB output of your computer first. Geddit!
I have a suggestion for the object browser of Axoloti, cause it feels like it started out with the best of intentions, but having so much freedom also means things are getting out of control where the organization (and finding of) objects is concerned.
It's a nightmare at the moment, cause searching for an object has no use if the object wasn't named in a way the user who is wanting to find it, was expecting. The other day it was suggested to me that I should try looking through the library of objects more. Fact is, that's all I ever seem to be doing! I think a good 80% of my time with Axoloti must comprise of using the library, trying to find things!
If I wanted, for example, to see a list of all envelopes in Axoloti, no matter what type, no matter who made it, I think there should be a way to see them all in one list instead of constantly having to hop in and out of folder, after folder, after folder.
And that's just now, the problem will only increase over time if it's not addressed, because more contributors, more objects, more folder hopping, means the problem will increase over time.
When I am looking for new objects to play with, I always have the community library page open from this forum.. And then select the user you want to check out.... There are explanations for most of the objects. I found a lot of interesting stuff this way.
If you type env in the text field, you'll obtain a list of objects that contain env somewhere in their name or in their description. Not to say that there isn't room for improvement, and expect to address this.
In hindsight, envelopes were probably the worst example I could give, so take functions instead. Say I wanted a list of all math functions. I can't search for a specific math function because I'm wanting to see a list of the variety of functions available, not a specific one, and they are represented by their various names, names I'm not aware of, so can't search for.
I suppose what I'm getting at is some sort of tagging system for the objects, but I know, the problem there is how to ensure the objects actually get tagged. Anyway, thanks for hearing the suggestion, Johannes, it'll be interesting to see how it might be improved with whatever you come up with 
I'd also love to see Tags implemented.. I guess it's "good enough" to hope that creators use helpful words in their object descriptions, but sometimes I use a word and the creator has used another word and then I scratch my head..
I think it would be neat to see Tags that are democratic - you could suggest a tag for an object if it's not already there or perhaps suggest that tags be removed. Of course that adds one (or many?) layers of complication to the concept.
So I'm putting in hour three with the patcher tonight.
I kept double clicking to add objects - which is awesome and so easy. Sometimes I decide that I no longer need to add an object so my instinct is to simply "click away" from the new object dialog box. Unfortunately this continues to add whatever object happens to be selected in the dialog box instead of cancelling the activity.
So then I've got an object I don't need in the patcher and I've got to remove it. Cool. My first instinct is to right click on the object and look for a delete option... but it's not there! So then my only option is to reach for the delete key. I appreciate mouse controls, and I appreciate keyboard controls, but having an akward mix of the two I find frustrating.
Disclaimer: If I could control the entire patch editor with the keyboard I would.. but I can't! 
Thanks for listening.
I'll keep plodding along.
I'd really love to see a favorites object list.
Even a favorite object section appearing in the object list as you add a new object.
That way you could add via the menu or create a new object as per normal.
Being able to add a new object and filter out by searching "favorites/" or "fav/" would be very handy. Of course this would just be a Virtual object library and not a real one. The library would be managed by adding or removing objects from the favorites group. I can see this to be very time saving.
sel Fader objects...
Writing to presets as a blob, would help a lot, its totally unpractical like it is, for 8 presets i have to click 8*16 times ... , Also i would like to assign a controller to each fader...
Just re-downloaded axoloti after some time away, unfortunately the UI is still too small for my eyes to use for a decent amount of time.
Setting my monitor to a different resolution kinda works but messes with other applications. What are you all doing to work around this?
Do others feel this is an urgent (like the most urgent) issue or not really?
Other than java, what other knowledge is needed to help make this happen?
Is there a specific framework that the GUI is built with? (sorry not too familiar with java applications)
I notice in the repo there is a purge for 'zoomui'. It must be quite a difficult task to add this zoom feature if it has not been implemented yet but would love to see this happen.
My programming skills are 'modest' (mostly small web apps with the js stack) - but if there is any way I can help please let me know.
zoom - unfortunately it was 'pulled' from this release, as it causes performance issues.
as you correctly point out, its not just something you can easily add, without causing other issues.
however, its something that is slated for the next release and the work is already 'in progress' , but the release has quite a few things going into it, so its probably a while away yet.
(as stated before 1.0.12 is stable, so the next release was a bit more ambitious, tackling some issues under the covers)
so yes, its a priority, but Axoloti is not made by a software house, that can just bring in extra resources, so its not really a question of if its 'urgent' or not
if you want to help, then you can contact @johannes, you will need to be an experience Java programmer with Swing/UI frameworks and experience with the model view controller paradigm.
if you cant do that, but have development experience, another option would be to either look at the 1.0.11 version which contained zoom (note: its not the latest release of 1.0.11, you'll have to dig to work out which it is) , or one of the development branches (probably experimental is best... master if you want to help development) BUT this is not supported i.e. be able to figure this out yourself ... also you will not be able to contribute to the community library, and of course development versions contains bugs, and potentially features missing/partially complete.
... this is not too 'hard' if your experienced with Git, a bit of java, and general build tools, but its not some I can really walk you through, as too many pitfalls if your not sure what your doing.
Thanks @thetechnobear, great to hear it's being worked on - I'm learning Java atm for other reasons and will look into Swing. I'm very comfortable with mvc model.
I'm not sure of your tone here? Perhaps my use of the word 'urgent' came off as demanding. I was only looking to get a gauge/perspective from the community, clearly plenty of people are getting on fine without zoom. Often customer feedback comes into play at least a little when prioritising new features.
Your response is helpful, I'll do some reading - build some toy projects in Swing with the hope that I can contribute to axoloti at some point! thanks again.
sorry, no tone intended, the quote was attached to the previous statement, which is its already in development and it already has priority (due to previous feedback 
) ... as you are new here, I merely wanted to point out that there is not a team of developers, or a revenue that could expedite this change.
@username_global Glad to see that there is another person who shares my conviction that having a zoomable UI is absolutely critical going forward. I've put in a ton of work to try to make this happen, and I plan to do everything I can to make sure it sees public release eventually. I'm the author of both implementations so far. The original attempt was a total hack that attempted to mostly stay within the bounds of what Swing provides without introducing any new dependencies. This can be made to work sort of but turns out to be a minefield of special cases because Swing isn't really designed to be zoomable.
The second attempt uses the scene graph framework Piccolo. Piccolo comes out of years of academic research in the area of Zoomable UIs, so it works incredibly well; most of the hard problems are already solved for you in the framework. Getting the Swing and Piccolo UIs to live side by side cleanly took a bunch of refactoring work to separate fundamental patcher logic from view logic. In the currently released version of the patcher, this logic is still all mixed together. Getting all this logic separated is the model view controller work that @thetechnobear alludes to. This process was started in my work with Piccolo and is being continued now in @johannes latest work. The MVC paradigm can improve many aspects of the patcher beyond just view rendering, so there's still a bunch of work happening in that area (patch code generation, etc). This latest work is in @johannes 's GUI-refactoring branch, but this is the bleeding edge in the MVC process and will likely be unstable. There are firmware changes there as well that may make it frustrating to work with in its current state; I haven't had a chance to work with the latest firmware yet. Currently, Piccolo is disabled but still present in that branch and needs some work to be made consistent with the latest MVC changes. I've been off working on another project for a while, but will be returning to work on that branch when I have time.
If you want to simply experiment with an older build of mine that runs Piccolo and can zoom, private message me and I can help set that up for you. This will require you to be able to check out and build code, so you'll need a working dev environment.
Best and welcome back to the community. Hope to see you submitting patches in the future.
Apologies if this is too technical for this thread. Feel free to relocate this post if need be.