Mozaic customizable GUI layouts

ManWhoWouldBeStrings

I’ve been dreaming for a while now of having the ability to create one’s own customized GUI layout templates within Mozaic that could then be used like any of the ones that came with the app. The five that are available now are great yeah, but definitely not always ideal, and when on a phone sometimes just kind of too small. Especially since now with iOS14 AUM doesn’t allow the auv3 windows to be bigger than screen size...

I was gonna send @brambos a message directly asking if this could be something he’d consider but figured I’d put it here to see if there was more interest for this kind of thing... I know I’d pay for an IAP that could add this functionality in a heartbeat.

I know there are quite a few ‘design your own midi controller’ apps out there already, but nothing really like Mozaic and as with it being built for customizability I feel like customizable layouts would open it up even more and is the only thing missing now.

I have no idea how much work adding this would be for Bram, and obviously we’d all love him to keep coming out with amazing new stuff, so maybe not worth it. Mostly curious if others would also like/use this feature.

What say ye? Start a petition? Sign on the line below...

yowza

I recall that Bram Bos has already said in the past that he isn’t interested in adding more GUI layouts but maybe you can change his mind. If you search the forum you will find it back when Mozaic was first released.

espiegel123

@ManWhoWouldBeStrings said:
I’ve been dreaming for a while now of having the ability to create one’s own customized GUI layout templates within Mozaic that could then be used like any of the ones that came with the app. The five that are available now are great yeah, but definitely not always ideal, and when on a phone sometimes just kind of too small. Especially since now with iOS14 AUM doesn’t allow the auv3 windows to be bigger than screen size...

I was gonna send @brambos a message directly asking if this could be something he’d consider but figured I’d put it here to see if there was more interest for this kind of thing... I know I’d pay for an IAP that could add this functionality in a heartbeat.

I know there are quite a few ‘design your own midi controller’ apps out there already, but nothing really like Mozaic and as with it being built for customizability I feel like customizable layouts would open it up even more and is the only thing missing now.

I have no idea how much work adding this would be for Bram, and obviously we’d all love him to keep coming out with amazing new stuff, so maybe not worth it. Mostly curious if others would also like/use this feature.

What say ye? Start a petition? Sign on the line below...

Bram has been clear that his design choices are made with great deliberation..,and he has discussed this one. He is not one to go against his better instincts because of a poll. Perhaps, you should consider searching for his posts and reading them rather than try to put pressure on him with a poll.

wim

Overly polite. I see no harm in a poll, nor do I see that as putting pressure on someone. You put your products out there, you gotta expect (and preferably appreciate) feedback. He’s an adult. He doesn’t need to be babied.

I wouldn’t bother to pursue it myself because I too remember him being against it. But I don’t see any need to dissuade others from trying ... constructively, of course.

ManWhoWouldBeStrings

Yeah I didn’t mean this as some kind of thing to put pressure on anyone. Really just to see if there was interest. If I were him, and there was a bunch of interest for something I could create, I think I’d like to know. Especially if it was marketable.

And yeah I assumed he’d maybe addressed this somewhere but it can be pretty time consuming to scroll through endless pages of forum threads looking for one comment

ManWhoWouldBeStrings

Ok well now I actually added a poll 😆 Just for fun

wim

@ManWhoWouldBeStrings said:
Yeah I didn’t mean this as some kind of thing to put pressure on anyone. Really just to see if there was interest. If I were him, and there was a bunch of interest for something I could create, I think I’d like to know. Especially if it was marketable.

And yeah I assumed he’d maybe addressed this somewhere but it can be pretty time consuming to scroll through endless pages of forum threads looking for one comment

Indeed. It would probably take a great deal of time to find those posts. I remember ‘em but wouldn’t go wading through those mega threads to find them.

Besides, people do sometimes change their minds, or have more time later on. Jim Pavlov said flat out that he wouldn’t consider an AU version of GR-16, then surprised us all out of the blue with one over a year later.

Don’t let anyone put you off. You’re not doing anything that should be discouraged.

ManWhoWouldBeStrings

But actually, and probably more constructively then....do any of you have any other solutions/app suggestions for creating customizable midi controllers that could maybe be combined with Mozaic to achieve what I’m hoping for?

SpartanClownTide

I don't think he's going to be cajoled on this one.

Personally I'd wish for just one more layout with a top row of pads and a bottom row of knobs (or vice versa). Would be great for sequencers.

0tolerance4silence

Brace for the surprise poll result. Do you usually want more or are you generally happy with what you’ve got.

wim

There’s nothing ideal. Ideally you’d want something like an AU version of Midi Designer Pro 2, which you’d then use in one-way or two-way communication with Mozaic. MDP2 is great, and it can be used in slide-over mode in AUM and split view in Audiobus. But somehow it just doesn’t feel right to me not being an AU.

Carnbot

Yeah, would love that but would happily pay for a new Mozaic app which could offer Full screen customisable guis.
That might make more sense than an iap.

wim

To be honest, I see some very rudimentary variable string handling for labeling as even more important than custom layouts. It gets really difficult sometimes to work within the constraint that the only variables you can work with in labels are numbers.

I totally get why he doesn’t want to do full string variable handling, but some much more modest approaches have been suggested and haven’t been taken up.

I just accept it for what it is (and that is a lot ) at this point.

Tim6502

@wim said:
To be honest, I see some very rudimentary variable string handling for labeling as even more important than custom layouts. It gets really difficult sometimes to work within the constraint that the only variables you can work with in labels are numbers.

I totally get why he doesn’t want to do full string variable handling, but some much more modest approaches have been suggested and haven’t been taken up.

I just accept it for what it is (and that is a lot ) at this point.

+1
Just a single character (Chr byte) functionality can avoid combinatorial explosion in labeling.

wim

@Tim6502 said:

@wim said:
To be honest, I see some very rudimentary variable string handling for labeling as even more important than custom layouts. It gets really difficult sometimes to work within the constraint that the only variables you can work with in labels are numbers.

I totally get why he doesn’t want to do full string variable handling, but some much more modest approaches have been suggested and haven’t been taken up.

I just accept it for what it is (and that is a lot ) at this point.

+1
Just a single character (Chr byte) functionality can avoid combinatorial explosion in labeling.

Yep, I made that suggestion. It seems like it would be a relatively simple addition that wouldn't cascade into a bunch of other complications. However I would hope also to see something like (ArrayChr <array variable> <start> [, <end>]) to allow calling a range from an array. This would allow setting up an array in advance, and pulling phrases from it.

I can totally see why Bram doesn't want to get into string handling. And it is sure that people would still complain about having to convert ascii to get characters. But it would be a HUGE benefit for the app.

Will

Short of full on custom layouts (likely an uninteresting nightmare on Bram’s part), it would be useful to have a few additional fixed layout types. Basically just reconfigurations of the same controls.

And/Or maybe a few more “Shift” type buttons that an author could label that would switch the layouts/labels. Essentially a tabs style layout set.

wim

@syrupcore said:
Short of full on custom layouts (likely an uninteresting nightmare on Bram’s part), it would be useful to have a few additional fixed layout types. Basically just reconfigurations of the same controls.

And/Or maybe a few more “Shift” type buttons that an author could label that would switch the layouts/labels. Essentially a tabs style layout set.

oooh! Tabs would be wonderful. TabVisable = [YES, NO, YES, YES, NO] (with each array position corresponding to a layout) and LabelTab <tab>, {TabLabel}

Will

@wim said:

@syrupcore said:
Short of full on custom layouts (likely an uninteresting nightmare on Bram’s part), it would be useful to have a few additional fixed layout types. Basically just reconfigurations of the same controls.

And/Or maybe a few more “Shift” type buttons that an author could label that would switch the layouts/labels. Essentially a tabs style layout set.

oooh! Tabs would be wonderful. TabVisable = [YES, NO, YES, YES, NO] (with each array position corresponding to a layout) and LabelTab <tab>, {TabLabel}

Interesting. I was thinking TabVisible would be limited to one at a time. Like, define an ordered array of tabs arrTabs (with label and layout for each array item) and then TabVisible = arrTabs(2) (or something). What would [YES, NO, YES, YES, NO] visually represent?

wim

@syrupcore said:

@wim said:

@syrupcore said:
Short of full on custom layouts (likely an uninteresting nightmare on Bram’s part), it would be useful to have a few additional fixed layout types. Basically just reconfigurations of the same controls.

And/Or maybe a few more “Shift” type buttons that an author could label that would switch the layouts/labels. Essentially a tabs style layout set.

oooh! Tabs would be wonderful. TabVisable = [YES, NO, YES, YES, NO] (with each array position corresponding to a layout) and LabelTab <tab>, {TabLabel}

Interesting. I was thinking TabVisible would be limited to one at a time. Like, define an ordered array of tabs arrTabs (with label and layout for each array item) and then TabVisible = arrTabs(2) (or something). What would [YES, NO, YES, YES, NO] visually represent?

Each YES would show a tab for a layout. A NO would not show the tab. Tapping on the tab would bring the layout corresponding to that index to the foreground. So, [YES, NO, YES, YES, NO] would show tabs for layout 0, 2, and 3. If all layouts were marked NO then only layout zero would display, to avoid having no layout displayed, or would throw an error. I'm not sure which would be best.

Will

@wim said:

@syrupcore said:

@wim said:

@syrupcore said:
Short of full on custom layouts (likely an uninteresting nightmare on Bram’s part), it would be useful to have a few additional fixed layout types. Basically just reconfigurations of the same controls.

And/Or maybe a few more “Shift” type buttons that an author could label that would switch the layouts/labels. Essentially a tabs style layout set.

oooh! Tabs would be wonderful. TabVisable = [YES, NO, YES, YES, NO] (with each array position corresponding to a layout) and LabelTab <tab>, {TabLabel}

Interesting. I was thinking TabVisible would be limited to one at a time. Like, define an ordered array of tabs arrTabs (with label and layout for each array item) and then TabVisible = arrTabs(2) (or something). What would [YES, NO, YES, YES, NO] visually represent?

Each YES would show a tab for a layout. A NO would not show the tab. Tapping on the tab would bring the layout corresponding to that index to the foreground. So, [YES, NO, YES, YES, NO] would show tabs for layout 0, 2, and 3. If all layouts were marked NO then only layout zero would display, to avoid having no layout displayed, or would throw an error. I'm not sure which would be best.

Ah, gotcha. Thanks for clarifying. You were talking tabs while I was thinking tab panels. Array makes perfect sense.