Yes just tried it. Nice. But it is not possible to edit the patch afterwards, besides form the code editor. Would be awesome if it was just another regular patcher object that you can edit as others.
Anyway, happy to finally be onboard the "new school" Axoloti 
Object layout, adding the ability to customize the position of different controls within the frame is certainly something I want to improve, and yes object type name or instance name should not affect size.
Hmmm but it is sometimes used to differentiate: osc/sine versus lfo/sine versus math/sine
I did not like the max/pd style ~ suffix, the tilde character is hard to reach on many keyboard layouts.
But that is already the case, no?
Fair points. I don't see the problem with having a truncated name in the titlebar, and a more specific path in a tooltip that appears when you roll over the titlebar.
a|x
there is an 'ideal' that you can reproduce a patch from a screenshot...so that might be slightly hindered by using tooltips. though, id say most of the time, the end part of the name is likely to be enough.
I think this ideal does have merits... here on the forum, when explaining things, you can simply post a screenshot, or even part of a screen, to give the idea of whats happening in the patch.
... but as i said, perhaps the end part is enough for this purpose.
That's interesting. It IS one of the merits of an object-based editor that it's by nature 'self-documenting', so I do see your point here.
You can upload a .axp file to the forum though (and it will take up less space on the server, too, probably).
Maybe you could have a keyboard shortcut to toggle all tooltips on/off.
a|x
Is there a way too start the patcher without automatically connecting?
I have a few axoloti's, and I wouldn't mind choosing which one to interact with before connecting (as some may be running in autonomous mode)
not as far as Im aware... but I do want to do something similar....(same reason, many axoloti's to control)
Im thinking perhaps something like a command line interface, that can just upload a patch and get it to execute, disconnected.
what you can do temporarily at the moment (apart from sdcard and using program change events or similar) is use the fact that if you disconnect a board it continues to run the patch.
so what I do is...
select board 1 - connect, go live
disconnect (on console window)
select board 2 - connect, (possibly change patch) , go live
disconnect (on console window)
select board 3 - connect, (possibly change patch) , go live
disconnect (on console window)
etc
one thing you can't do currently... is reconnect to a running patch... as soon as you connect to a board, it will automatically stop the current patch.
(would be nice, if it would allow reconnect, you get the logging ... and something like if you had the same patch loaded, you could reconnect it ... obviously needs to be the same patch, for controls to match)
its not ideal buts works for now.. well that and using the SD Card, and load the patches via program change events.
You might consider adding a couple more XML tags (or additional properties for existing tags) to be used in the Parameter section of the object definition.
Taken some cues from HTML/CSS, how about
float left
float right
clearUsing these tags/properties, you could arrange controls in horizontal rows and specify where to start the next row. It would be a start, in terms of allowing more controls over object layout.
Note: you'd have to move the parameter label above or underneath the control, for this to work (but to be honest, I think it would look neater here, anyway).
I used to be involved in the development of a video performance software, that had a plugin format based on Quartz Composer. At one time, they experimented with a method to allow plugin developers to customise the layout of their plugins, and even add their own background image. Adding the ability for Axoloti custom object developers to add their own logo or branded background image might encourage more established programmers (i.e. those who already have an established brand) to get involved.
a|x
How about reserving a small area at one corner of an object for logo or something similar, as a compromise?
a|x
can i suggest, this topic is about what to change.... rather than how to implement it.
Id leave implementation decisions to the the implementor, we all know about HTML/CSS/XML ... and we are pretty familiar with graphical environments (including Quartz Composer)
now... if you want to get into implementation, and start developing the code, fantastic... then we will definitely be happy to discuss with you options for implementations.. not in this topic, but in the developer category or github issues.
(honestly, the reason for not doing this stuff as yet, is not, not knowing how to do it, its about time and resourcess)
I second this request! I also find it hard to read and tried in vain to zoom in, pleas make it so we can
4 posts were split to a new topic: Poor performance with patcher on older machine
moved to separate thread...
A post was merged into an existing topic: Poor performance with patcher on older machine
Just thinking, would an alternative execution order be possible?
My first instinct in terms of visualising signal flow would actually be top to bottom, left to right instead of left to right, top to bottom. In other words: columns instead of rows. I've been becoming increasingly aware of the importance of the execution order and have been trying to lay out my patches accordingly, but it makes it harder for me to actually keep track of what I'm doing.
Now obviously this can't and shouldn't be a global setting as it would break all existing patches, I would instead propose it be a per-patch setting so you can decide at the beginning which way round it'll be. The original execution order would obviously be the default and what gets chosen if an older patch without this flag gets imported.
Does this seem possible?
I fear a patch setting for an alternative execution order will increase confusion. I do plan to address execution order, and add graph-based sorting, but this is a deep change, and importing patches requires extra care in development.
First priority in development is getting the next stable release out.
