theres quite a few assumptions here....
as such 'display objects' do not really eat up ram... parameters DO...
and parameters are not just about display, as you will see when you get Axoloti Control
Parameters are 'variables' that can be changed at runtime, as opposed to Attributes which are compile time constant.
as i think i mentioned earlier, Johannes and I have discussed this before in the past, what we would like is for the distinction between inlets/parameters/attributes to become more 'fluid'
Ive proposed we actually do away completely with attributes, instead what we will have is Parameters, that you can right click and say this is a fixed value.
users will then learn the tough reality... nothing in life is free, you have all your parameters as variable, then your patch wont be as fast/will consume more memory... fine for small patches. more complex patches, you'll want to lock down everything you dont need to change at runtime.... but the key is its the users choice, and they get to live with the consequences
(actually for performance reasons, it'll probably be fixed by default, and user choose which to make variable)
this will also help with axoloti control, since you can expose less parameters, so its easier to navigate.
inlets for parameters, as I said, its kind of an idea/proposal thats knocking around, the issue is some objects already have these manually coded, so then there would duplicates, and if we remove, we have the danger of breaking patches!
(and yes, we have had lots of discussion about backwards compatibility, and object migration... which is another huge can of worms)
displays... again will be viewable in axoloti control
if your connecting to a computer, then yes, when display values changes, there is some usb traffic, apart from that yeah a small bit of memory to store... so I guess theres an argument for disabling, though how long before we get complaints there not working coz they've been disabled
of course, the other side is ... you could structure your patches differently...
put your sound engine in a subpatch, and then the UI / GPIO in different parents... then for debugging use the UI variant, for performance use the GPIO variant.
... I have to say, I tend to use a strategy where I try to not have too many UI objects, so I agree on many of these points, just I'm hoping we can get to fixed parameters to solve this.
I think this is rather exaggerated, different users have different expectations, even with just factory objects, there are huge number of things you can build with Axoloti.
saying its 'unusable' because it doesn't have a feature you want is a bit excessive... especially if there are other ways to achieve the same/similar... no piece of software or hardware, can do everything, everybody wants...
so sure, if you are a programmer you can extend it more... do more, of course, its the same with PD, those that can write externals can make it do more... but heres the thing, its this ability that allows community programmers to given non-programmers new objects!
also this is why Axoloti is open source... unlike (e.g.) Reaktor, it is possible for others to update/contribute to its development..