Also, it would be great to have the standard OS X file dialog, for opening/saving files, as the one above doesn't show the left sidebar, with aliases to home folder, mounted devices, etc.
I guess this would mean adding Mac-specific API calls, but I think it would be worth it, in terms of OS X usability.
a|x
+1. Would be great if the filebrowser was "standard" Apple browser, where you can use short cuts, etc. on left side of the filebrowser.
moving to the older awt FileDialog gives a more native feel. (as close as we're going to get)
what I do want to add though is better integration with Finder, which just requires sub classing the MainFrame into platform specific variants, much of the other code is already there. (and I think works on windows)
also, can i make a suggestion, improvements should not be put on this thread, only bugs specific to 1.0.10... this thread will be closed and largely ignored) once 1.0.11 (or whatever) is released.
general improvements should go here:
On OS X:
Using java.awt.FileDialog would definitely be an improvement.
Drag-drop for .axo, .axp and .axh file would be great!
Also drag-and-drop for samples (creates a table of the required length and loads sample into it).
Also the ability to double-click a file to open it in the Patcher would be excellent (currently it does open the Patcher if not already running, but doesn't open the file, which is annoying).
a|x
That's kinda why I've mostly avoided Java-based applications where possible, as a user- they have a tendency to look odd and behave weirdly on all platforms, in my experience. That's the downside of cross-platform VMs, if sufficient effort isn't put into making platform-specific tweaks to builds for the different OSes (and it usually isn't, for the reasons you mention).
I wonder if other cross-platform C libraries (e.g. Qt/JUCE) where considered, instead of going down the Java route? @johannes?
a|x
fwiw - I agree, though there is also a dev resources aspect to this decision.\
anyway, I think off-topic... its unlikely to change, I think there are bigger fish to fry 
(of course, its open source, so never say never, someone could already be writing a C++ Juce UI as we type)
One thing i'm really missing in the patcher is something like plain comments or text (without any user interaction) inside objects maybe with some basic formatting options.
Like patch/comment objects, but inside parameter lists, in a way that you can insert descriptions in custom objects outside the edit object definition window.
This could make parameter functions clearer to the end user
Something like (parameter list):
int32 parameter
//comment1
int32hradio
//comment2
frac32
...
I'm not sure if i expressed myself quite clearly
You can already add tooltip information for inlets, outlets, parameters and attributes, when designing custom objects.
I do think a multi-line version of the existing comment/label would be cool, though, maybe with some basic formatting, too.
Maybe that's what you had in mind.
In the longer term, something like the Quartz Composer comments would be really nice. They're coloured rectangles with a title-bar to which you can add text, and you can set the colour, and drag the bottom-right to change their size.
They sit behind the objects, and are really nice for colour-coding and visually grouping sets of objects within a patch.
a|x
Having updated to the new version, and having made a keyboard setup with 2 axoloti's and a couple of dozen patches for each card, I'm starting to find it a bit laborious in having to upload all my patches again.
I was wondering if there could be a "batch upload to SD card" function, where we could select all the needed patches, and it would do all the work for us in only a couple of actions.
I know I'm lazy and that it doesn't take that much time (and it's only once every few months), but as time goes on, I'll probably have a few hundred patches on each card by next year, so I'm just wishing out loud. (I have no idea of how difficult this could be).
Voila, thanks
I added a function to patch banks to do this , so perhaps if you organize your cards using patch banks , this is works for you.
( I can't really think of another solution, as whilst we could find the patch on the sdcard, we would have no idea where it existed on your pc )
I started to read the opening exchanges with interest here - older eyes have just become an issue for me and as a function of my workspace I am distant from the screen - relaxed legibility of fonts and lines could be one of those things that hinders interaction
So I have a question/favour - it's a long thread (it may be fixed/improved), I don't own a device yet and I think I'll forego installing the package until I do, so if anyone could be kind enough to reply with a screen grab of a Fullscreen 1920x1080 (or thereabouts) window of a sample patch(or representative other editor page) in the current editor i'd be interested to see just how tricky the legibility may be for me until I get glasses sorted - I'm suspecting the issue to be compounded by the stark contrast (such as that used by Discourse as it happens, the brightens puts a strain on the eyes)
tia
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
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
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.
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.
It would be really nice to activate tooltips for displays and attributes (apparently these don't work, now)
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.
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.