Custom UI for objects

#1

(Pie in the Sky alert - manage expectations may never happen!!!)

note: this is only for very advanced users/developers... as you will need to respect quite alot of 'unwritten rules' to do with parameters etc ... almost certainly you would need to know the Axoloti code base reasonably well

I was thinking last night, about some new objects that Id like to create,
but I realised quite quickly there were quite alot of parameters, and the current way to display parameters would just make the thing unbearable to use.

Now.. we already know we want to have more customisation options, and also presentation options. Which would be cool, and for many users very useful and enough.

BUT it will still have a fundamental limitation, that it will be limited by UI types defined in the axoloti java UI.

so i was wondering how about allowing objects to use custom java classes?

i.e. not only do you ship an axo, but also as jar which contains a java class that has custom java code.
Initially I thought about just for displaying the object, but later realised it could potentially also have custom generating code... (assuming we can get the 'right interface')

It seems not too tricky to actually implement:
objects have a class reference, and a jar reference, when the object is created the relevant class its loaded.
if its doesn't have a class reference the current implementation is used.

Note: Id considered a custom class loader and embedding the class into the axo file, but this could make the axo file pretty unwieldy

it will mean ensuring the entry points for display etc, are well defined (if its not already true) , but thats no bad thing

of course, there could be issues with versioning etc... but given the small number of users using this, i think its manageable.

What do you think? is custom java code a really bad direction?

#2

Hm. This would provide a lot of flexibility, of course.

I don't think it's a bad direction. But TBH, I think a way to layout parameters on the "surface" of .axo/.axs's is better. Basically just allow specifing X/Y coordinates for the buttons, maybe grouping and labelling somehow.

Of course, maybe the way to do it would be to allow custom Java code for objects and then use that to provide a layout mechanism!

Just remember that not everyone who wants to make complicated patches also want to write Java code :smile: but I think it's fair to say that everyone who makes complicated patches want better layout options.

#3

Or javascript, that avoids depending on a JDK install.
I've been thinking about javascript axoloti objects that can parse arguments and emit the effective axoloti object.
That would allow to de-duplicate "mix n", "mux n" objects. So "n" becomes a true object creation argument.
But that is more or less independent from custom UI presentation topic.

On the topic of custom object UI's:
We need to be careful what api we bind it to. java.awt.Graphics2D is perhaps too low level, maybe SVG is more suitable?
I think explicit X/Y coordinates is the future, rather than layout constraints. Pixel-exact representation on all platforms is a design goal.
Scalability is important, but not really easy. Some widgets like "sel/sel b 16" will look ugly if the grid lines are not on pixel boundaries. So I think all X/Y locations should be on a integer-pixel grid, and then we can scale the integer-pixel grid.
For example, if the 1:1 view grid is 8x8 pixels we can have a first zoom in step at 112.5% where the grid becomes 9x9 pixels, or zoom out to 87.5% where the grid is 7x7 pixels.

#4

As I mentioned in another thread, the ability to specify basic layout properties like alignment for parameters would probably be enough for most purposes.

Allowing for pixel-based positioning would probably not be that useful, and would make scaling/zooming the patcher window more complicated to implement.

Allowing for the creation of arbitrary interface elements by 3rd-party developers runs the risk of making the Patcher look messy and incoherent, in my opinion.

a|x

#5

That would be great! I think a lot of people would find the ability to use JS to, for example, implement complex logic without having to use a huge number of individual objects really useful. I know I would.

This would be most useful if, rather than a standard Axo object being created from the Javascript, the JS code remained editable, and is simply compiled into C when the patch goes live.

It loses it's utility if you'd have to dive into C/XML to make any subsequent edits to a standard Axoloti object created from the JavaScript definition.

a|x

#6

Sorry, I probably shouldn't be posting here.

I followed a link from the 'Suggested Topics' section at the foot of another page, and didn't realise this thread was on the Developer board.

Feel free to delete my posts.

a|x

#7

While Java/Javascript per object is obviously powerful (An aside: if there must be a fourth language involved in making modules, how about Lua instead? Very lightweight, very easy to bind, very easy to learn, the perfect domain specific language IMO)

For custom object layouts I think Java/JavaScript/some-other-language is a language too far, at least if it becomes a requirement for such a basic thing as placement of controls on modules. XML, C and assembly is fine - more than that, and the learning curve becomes steeper and the development process becomes harder and more error prone,

I'd prefer see the development time spent on core functionality and bug-fixing rather than introducing something which will undoubtedly be a lot of additional work with little gain for a development team with plenty on the plate already (if we're only talking about presenting modules better).

An explicit X/Y placement of module components sounds about right to me. That could presumably just be some additional attributes to the existing XML(?)

Just my 2c.

#8

There are a number of different things here...

As I said, this is not a replacement for customized placement, and it's different from object creation.
This is about more advanced UIs , eg say a graph object the user could interact with, or multiple UI elements that work together.

Eg more how you create panels, with user interaction.

Why Java? because that's what we already use ... do can directly communicate with existing classes , i.e. No extra layers, interpreters needed
It's simple :smile:

of course , as I said too ... I have a particular requirement for a 'project' of mine, which currently to fulfill , I'd have to either take a private branch , or move outside the axoloti framework - neither are appealing... But of course possible.

#9

Just to clarify- is it OK for me to contribute to this discussion?
I added my posts above because it was suggested my related comment in another thread would be better somewhere else, and this seemed the natural place.

a|x