a bit different… but the way I handle this in EigenHost see this post 
, was to allow users to ‘paint’ the layout.
I’ll admit the reason I went this way is Im lazy 
, I got bored very early on in EigenD defining the keygroup layouts by hand - so quickly defined script that would generate them for me!
I had realised that most note layouts can be defined as vertical / horizontal offsets between ‘cells’. very few user ‘arbitrary’ notes (except for Antonio ), so this is a quick way to define a layout If you know the starting point/note.
I used that approach for MEC, and with EigenHost I take that further, so basically, you have the offsets define and if you ‘paint’ a region it uses the starting note to infer all other notes.
its not fixed at all, you can chose to paint the whole thing, or just a row or column…
ofc, I also allow you to specify a particular note too…
the ‘paint’ is just a generator… I store individual notes (actually, I store offset/intervals, but thats for scale abstraction), so a user can still have any layout they want… just quicker to setup new ones.
as for types e.g. notes vs app control
my current (internal,wip) approach is to use zones
this is a bit like EigenD where usually you put not musical keys into a different keygroup. so in EigenHost you’ll define a new zone, then target the app control output.
that said you have a lot more functionality in this area, and Im not sure how Id extend my model to cover all of this…
I’d guess basic idea is that the zone editor / painter will need to paint different types ?! e.g. control vs notes?!
anyways, not suggesting this is a good route at all, rather it might provide some ideas…
I certainly have been inspired by ECMapper for ideas for EigenHost 