A set Default in the param menu would be cool..and double click to reset to default value would be even more usefull then.
Improvements/Wishes for the patcher
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.
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
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
...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.
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.
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.....
I dont have any Windows machines here, so I cant test it for you. But looks weird. @johannes, do you have some inside knowledge on why it might look like this in windows 10?
@philoop zoom had already been implemented but it was not stable enough for a release. So it was ditched again. So I am pretty sure it wont be many releases before it is stable and working.
Oscillators and filters... I am not too sure about that. I dont think Johannes is putting much effort into developing new objects as he is in working on the editor in general.. But I might be wrong.... I hope I am.....
The theme editor I did is still present in the latest stable release but remains disabled. Ultimately, I'm not sure if we'll end up enabling it because it will complicate support and troubleshooting. Last Johannes and I talked about it, we discussed possibly supporting a small number of factory themes, but not full editor functionality.
A revised version of a fully zoomable UI is implemented as part of a very large refactor I did but will not be available in the stable release for a while. The feature has not been ditched. If you feel up to it, you can clone my branch directly and build from source. Here is the pull request: https://github.com/axoloti/axoloti/pull/371
With an option to generate 3D printer models so that we can go from software to hardware knobs
Though slightly more seriously, it looks like the latest knobman3d is open source? I'd not come across https://github.com/g200kg/knobman3d until today. Wrong language, but it would make STL export doable
From my point of view, customized graphics would be a way of prototyping hardware controls rather than a replacement of the usual controls.
One thing I'd like to see is a way of putting the 'map on parent' controls in two or more rows when you make a sub-patch. I really like the sub-patch system, but with so many controls on some, it goes way down the page and it makes it pretty hard to use.
Cheers and keep up the good work programming guys!