Hey Philoop,
Do you mean the ability to set a custom background color for a particular knob? Like from the knob's right-click menu? That should be a really quick change.
Nicolas
Hey Philoop,
Do you mean the ability to set a custom background color for a particular knob? Like from the knob's right-click menu? That should be a really quick change.
Nicolas
No problem. Really the only tricky part I can think of is making sure that those colors are saved and loaded properly as part of your patch file. I'll add it to my list of things to work on. It probably relates to having a more generic mechanism for themes down the road, so we might have to spend some time thinking it through to make sure it's not going to conflict. I suppose if we had a theme mechanism, the per-element colors could just override the global setting.
I just want to note that merging any of my enhancements will likely need to wait until after 1.0.10 is out. We're in the release candidate/bugfix stage of the development cycle, so we don't want to introduce anything that could impact stability at this point. I'll keep you updated on my progress.
Patch load mechanism / controller object
it would be better if the patch.bin files pointed to a controller object on the SDcard,
so it could be edited, instead of of having a painful reupload session.
I am just starting this planning to have 100 preset on the card.
Modifying the controller object would be ......
....
i know its impossible but
sorry not possible, the planned path is "bulk uploading" all patches in a bank from the patch bank editor.
The ability to compile a patch without having an Axo core connected would be handy for "offline" development & testing.
+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
How about adding the ability to make an object temporarily inactive, without removing it from the patch?
Very handy for debugging.
a|x
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
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 )
so yeah, Id guess that would be outside of 'axoloti' , but a great open source development project.
Thanks - that's just what I need
Indeed, but sometimes it's a handy feature anyway - using it now
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
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
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).
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:)
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.
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.
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