Mira bpatcher support
When I build an app of any complexity, I try to follow best practice for separating interface and algorithm (a pragmatic approach to MVC). This means that my interface elements are in one or more [bpatcher]. If I apply [mira.frame] to the presentation view, none of these show up. If the frame is in the abstraction itself, these show up, but take up an entire tab on the browser.
Just wondering as to the likelihood of seeing support for the parent view of [bpatcher] in the future?
-- Robin Parmar
bpatcher support was "next on the list" in 2013, I wouldn't get your hopes up...
Using the Presentation Mode to organize your interface/processing works fine *and* plays well with Mira, of course....
@Max, what do you mean by this? It seems to not respond to Robins request?
@Robin I support this wish as well. Right now I have had to add additional inlets to all my bpatchers that let me essentially make a redundant gui outside the bpatcher. It's somewhat frustrating, as bpatchers really are best practice in max...
However, and partly in response to @jeff, I'm hopeful that they'll get around to it, since there's actual, multi-person, active development of mira now, as well as quite a lot of user support of the project. (I'm playing my 3rd show with a large touch screen on monday! :) )
I could certainly have been clearer, I think: I tend to create very large patches and either use the Presentation Mode to handle the UI, or I send UI outputs into inlet of a bpatcher. I started doing both those things back when the Presentation mode appeared, and haven't ever really had a problem. Of course I've never felt the need or desire in any way to port my performance patch to an iPad, so perhaps this is not helpful "advice." I was responding to the question with the workaround I've traditionally used. That's all, really.
Ah, gotcha. Your advice can certainly be brought into my own workflow, now that we have snippets. That will let me retain the modularity in the UI section as well. Thank you so much for the clarification, Max. It's been a bit of an eye opener, actually.
Yes, a workaround to interfaces not working in a [bpatcher] is to not put interfaces in a [bpatcher]. Which amounts to not using them at all, since that's what they are for!
However, this immediately means that you cannot create modular interfaces. I think it's bad practice.
At first, I also thought that it would be nice that Mira shows bpatcher contents. Then I tried several things and now I think differently. In my opinion, it would not be that flexible.
When using a Mira interface, you need to build a specific GUI. It is interesting to show parameters from different patches in Mira.
Here is how I'm doing it.
Nicolas
Hey together,
is there a workaround to show a lcd object in MIRA to display painted graphics?
Wow, thank you Nicolas!
I spent a good while trying to unpack and understand how you'd done this - I'm not that deep into pattr, but this actually taught me some really useful stuff - especially about how to use the :: argument.
I knocked up this simpler version of the patch above for those - like me - who are much greener:
Clean explanation of my example, thank you Exeterdown !
Thank you Nicholas and Exeterdown! I came across this recently and it has been very interesting.
In addition to your solution, I also realized that instead of attempting to include the [mira.frame] object on the level of the parent patch that has your final presentation layout, you can simply add the [mira.frame] object into the original patch of what will become your bpatcher. When you load the bpatcher into a parent patch, the mira.frame will still appear on your mobile device.
Of course, the scope of the Mira.frame will not expand beyond that bpatcher, but you can have multiple Mira tabs to include different parts of your presentation UI.