there has been some work on a full zoom on the UI, it was pulled from the 1.0.11 release due to some performance issues. but no doubt it will be back 
Improvements/Wishes for the patcher
thetechnobear
#242
mtyas
#243
Thanks a lot, I don't know how I missed the patch bank feature for so long, never even saw it (and it is quite obvious).
It seems to be exactly what I am looking for.
Thanks again for showing me the obvious...
...and that is I'm blind
thetechnobear
#244
johannes added it in one of the test releases....possible 1.0.8 or 9 - the upload all, I only added in 1.0.11 though.
cpwitz
#245
The new 1.0.11 feature for toggeling the visibility of specific cable types (red, blue, green, yellow, pink) is great. Maybe it would become even better when, if mouse-hovering an inlet/outlet with hidden connections, these specifc cabels would appear and become draggable again.
Sputnki
#246
It would be really nice to activate tooltips for displays and attributes (apparently these don't work, now)
DrJustice
#248
Object editor improvement
If an object from an axo file that contains multiple closely related objects is opened in the built in object editor, saving the edit will delete the other objects and only keep the edited one. This can cause a loss of objects, something which has actually happened as another user unknowingly did such an edit on one of my multi-object files in axoloti-contrib (easily fixed, so no biggie).
The practice of keeping closely related object in a single file is something I picked up from the factory library, and it helps in preventing an explosion of files. Therefore it would be good if the built in editor retained any objects in a multi object files that are not being edited and saves them back with the edited object, or alternatively it could issue a warning. If this is a no go, the object editor documentation and tutorials should perhaps mention the behaviour when editing with multi object files.
thetechnobear
#249
yeah, if we keep the multi objects per file, we need to add support for this in the editor....
I guess as a 'bug fix' we could make objects within a multi file 'read only', this would mean the owner would not do this accidentally.
that seems like a bug... another user should not be able to save/edit one of your files... the save option should not be available, they should have to 'copy to library' , which would then 'not be a problem'.
this is an important bug, since Axoloti 'reserves the right' to reset a change that is made to a library object that you 'dont own' i.e. factory object or outside your area in the community library.
(of course, id recommend users use a GitHub library for even their own personal objects, so changes are not lost, as can be reverted via GitHub)
feel free to update the user guide with a warning, though frankly i suspect it'll be a detail that even if a user reads will be quickly 'forgotten', so we need the application to enforce/remind.
philoop
#250
A set Default in the param menu would be cool..and double click to reset to default value would be even more usefull then.
DrJustice
#251
Nevertheless this happened on two occasions, on Sep 17 2016 and Sep 26 2016. It's in the git history, here.
Perhaps a minimal fix could be to detect on loading that there is more than one object in the file, and then give a warning that the file can not be saved and subsequently refuse to save if that's attempted - even if one is not supposed to be able to commit.
lis0r
#252
Hi all,
Sorry that I'm replying to an old post, but I've implemented a graph based sort method for computing execution order. The code's on my fork https://github.com/lis0r/axoloti
It starts by finding all the nodes with no outlets, sorts them by the position as done now, and add them to a list. It then processes the parents - first adding them to the start of the list if they're not already in it (again in position order), and then recursing into them if they're not in the list. This way it should start with the furthest away nodes, the inputs, and proceed to the outputs, without getting caught in loops.
If this is a desirable change, I can make a pull request?
Cheers!
Lisa
lis0r
#253
I've thought of a request, which I might try and prototype if I get the time, but I thought I'd get it here for posterity otherwise.
In short, detach the process of building xpatch from the process of uploading the resulting binary from the board. Longer, whenever the graph changes, mark it as dirty. A background thread is monitors for dirtiness, and when it detects it, it generates code, marks the graph as clean, and starts building. When it comes to uploading, wait until the graph is clean and the builder thread is idle before doing so.
The idea of this is to reduce the latency of going live by hiding the build phase behind user interactions.
Cheers!
Lisa
rbrt
#254
...would be GOLD if there was a way to adapt the locked/unlocked color of the patcher background.where can I change this?I figure it shouldn't be too hard to do so...
...also zoom would be very cool indeed.
I was just patching with a friend of mine,he's a max/msp dinosaur but since he's not 20+ and has bad eyes anyway,he can barely read the patcher , that's why.
jaffasplaffa
#256
I think someone already worked on that too, but since they could not get a stable version working, they ditched it again for the last release. So I am guessing it might be implemented in the near future.
philoop
#261
yes!! iam quite sure @jahhonest is working really heart on 12 ..cant wait...but zoom? I dont think so .....lets expect more oscillators and filters, and a stable release.....