Improvements/Wishes for the patcher

#216

sorry not possible, the planned path is "bulk uploading" all patches in a bank from the patch bank editor.

#217

The ability to compile a patch without having an Axo core connected would be handy for "offline" development & testing.

#218

+1 for that. Having said that, it's a bit of a can of worms, potentially. Would it necessitate creating a VM of the Axo Core hardware? If so, probably a major job.

a|x

#219

How about adding the ability to make an object temporarily inactive, without removing it from the patch?
Very handy for debugging.

a|x

#220

this is already possible. you need to enable expert mode, in the axoloti.prefs file.

we hide it, as we don't want inexperienced users thinking its a 'necessary' stage to take a patch live - would be an easy 'confusion' to make.
its main use, is when developing custom object - to test your own code compiles, again probably 'not the norm'

besides don't you keep an axoloti with you at all times, you never know when it might come in handy :slight_smile:

#221

I took the testing to mean (perhaps incorrectly), testing your objects compile etc, which is something Ive personally wanted to do away from an axoloti.

but yeah, full patch testing, as you say thats more likely to be fulfilled by making the UI be able to create VSTs or something BUT... to do that we also would need to take out/substitute the arm code from the objects, as well as adapt firmware calls etc.
brief discussion here on this topic

(I guess you could use an arm emulator, but frankly as much effort as doing a VST generator and not as useful :slight_smile: )

so yeah, Id guess that would be outside of 'axoloti' , but a great open source development project.

#222

Thanks - that's just what I need :slight_smile:

Indeed, but sometimes it's a handy feature anyway - using it now :+1:

#223

A more useful VST-related thing might be to create a VST instrument/FX allowing audio to be piped to/from the Axoloti Core hardware via USB, much like those provided by Access for their Virus synths, and Novation for their Ultranova keyboard.

That would be cool.

a|x

#224

yeah, that or make it a USB class compliant audio device , with N channels in/out.
but think its quite tricky, Access have had a hell of a time, getting theirs to work reliably, with no end of support nightmares. works for me really well, but there are still lots of complaints on the forums.

but would be a nice feature, though digital audio between axolotis is my #1 request :slight_smile:

#225

I dont know if this has been "wished" already.
The patcher: If i double click the background/press space, i get the object list. I then type in for instances "sss/filters/". Then i have to click below to be able to navigate up/down through the patches. Its really annoying to me that i just cant write sss/filters/ and then press the arrow down key right away, but that i have to mouseclick in the object-list area first, and then press the arrow up/down key. (ok, "really annoying" might be an overstatement;), but you get what i mean).

#226

You can press tab to jump to the list below.

a|x

#227

Thats true! but it still seems like an unneccesary thing to do in my mind. In reaktor, you just write something and then press up/down. But thanks for the tip:)

#228

more native feel on platforms....
(drag drop, finder integration, file dialogs, menus, shortcuts)

for Apple OSX consider the following:
https://developer.apple.com/library/mac/documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html

It would probably be a good idea to sub class various components up-front, so that windows/linux/os x variations are easier to implement.

Note: we have to be careful here, part of the advantage of using Java is cross platform development, so not having to continually think about different platforms, and testing separately, so this has to be 'balanced' with native look and feel.

#229

Just noticed, when opening files, it's possible to navigate to the root of the filesystem on OS X, and see all the UNIX system folders that are normally hidden by the OS.

Screen Shot 2016-07-19 at 09.20.54.png1580x1614 215 KB

These should really be hidden I think.

Also, more importantly, it's not obvious to a non-os x-geek how to get to mounted external devices (external HD, USB memory devices etc.). It's possible by navigating to /Volumes, but most people aren't going to know that.

I've seen this behaviour with X11 apps and other Java-based applications on OS X, but again, the majority of OS X users probably won't, and will be confused.

a|x

#230

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

#231

+1. Would be great if the filebrowser was "standard" Apple browser, where you can use short cuts, etc. on left side of the filebrowser.

#232

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:

#233

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

#234

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

#235

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 :slight_smile:

(of course, its open source, so never say never, someone could already be writing a C++ Juce UI as we type)