Would be REALLY great to be able to have the object browser open all the time. So you can move it around on the screen and have it in front of you all the time.
Improvements/Wishes for the patcher
Dunno if possible but a script object that allows you to paste mathematical equations ot formulas into. This would have a really wide range of use.
For example creating new types of windows, without having to write a bunch of new objects.
Basicly it could be a very capable multipurpose object.
And also make many things a lot easier for non coders
you can already do this with one-liner scripts.
yes, they are limited to one parameter and one inlet, but if you allow more then you have to be able to add parameters/inlets and give them types.... which starts to look identical to an object. (embedded object)
so in practice, an embedded object is what you are after... albeit with perhaps more parameters and visualisations possibilities (which would be useful for objects anyway)
What about the option to display attributes on the parent patch, like delay line sizes etc.?
Oh, cool. Didnt know that I was thinking about the window idea i mentioned. I have got the formulas for most window types, so I was hoping maybe we would be able to just paste those formulas into the script and have a one function script. That would be perfect. And then maybe create an embedded object from the script and everything else that need to be in the object to create a new window type.
Anyway, just trying to find ways to include more functions, without asking for new objects. I requested a few ekstra window types, but if it can be done with scripts, thats fine with me Just didnt think of this approach before today.
Guess it is time to look into them
Thanks for the info
Expecting to copy/paste mathematical equations or formulas from a wikipedia page or a DAFx conference paper and get a working implementation, is unrealistic.
Window functions are often implemented with look-up tables, not by direct function evaluation. In DSP often formulas
are approximated when implementing them. Or some formula's don't even describe an implementation.
Yeah I also thought it might be expecting a bit too much. BUt if possible it would be great I do know that it probably had to be adjusted a bit and not DIRECTLY copy pasting. BUt you get the idea I am sure.
Thank you fo the answer
Apologies if I keep mentioning it, but it's the node-based editor I have most experience oh..
Quartz Composer has a mathematical function object. It's pretty useful. On the other hand, it doesn't implement variable typing, so maybe it wouldn't translate well to the Axoloti environment.
a|x
What about a short-cut to toggle the Live mode on and off?
(Maybe there is such short-cut and I missed it?).
heres a little one, but it would make patching much faster; on osx, when i pull up the object window i need to select an object from the list and THEN im able to arrow up and down. it would be great if i could type an object name and then arrow down to the one i want.
in other words its mouse, type, mouse, type. instead of mouse, type, type, type. .
like i said, just a small annoyance, but it would make patching alot smoother and faster for me
Press tab to move focus from the object name field to the list,
shift-tab to move focus back.
The ability to convert a subpatch into a patcher object version of the subpatch.
This would be very handy if you load a subpatch from the browser in Axoloti and then still want to edit the subpatch from patch to patch. The you could just push the "convert to patcher object" button and Axoloti converts the subpatch to a patcher object, which can then be edited, without worrying about messing up other songs or patches.
The Object Browser is the single item most in need of some attention in the current Patcher, I'd say.
It at the Least needs to be resizable, but having it constantly visible, or even docked to one side of the Patch window, would in my view be a great improvement.
a|x
Also, I don't think the width of an object should be determined purely by the length of the title string.
I don't think we need any part of the file path of the object in the title- just the object name should be sufficient.
The path could be displayed in a tooltip when rolling over the title.
Personally, I think it would look much neater if the widths of all objects conformed to the same grid used to snap their positions.
a|x