I’ve posted separately about the glitchiness of the live.dial and the live.slider which appears as a single multislider style slider.
I’d like to point out that the kslider will not render the top or left edges on the ipad 1 – this is irrespective of the actual or relative sizes of the mira.frame object or kslider object. Indeed the Frame of the kslider is so thin it needs to be ‘on’ to discretize between adjacent ‘white’ keys. This is in part a Max6 issue because with 4/5 (from memory) you could easily use kslider without a frame. Either way, those two edges are not rendered on my ipad 1
The slider also renders differently than in max (again like a bar multislider style) – not sure why this has to be so – some interfaces work better with the line
On the ipad 1 usability front, for those interested, apart from a few incompatibility issues (regarding lack of compass etc) the updating speed (even with the help file examples) can be very slow (there may be network issues, but they don’t blight other apps!) – it can take quite a few seconds to populate the screen
Most objects appear live (as if by magic) but i’ve found the fpic object to be hit and (mostly)miss
Hopefully we can have a ‘mira compatible’ object filter in the Max object explorer soon (the little (m) is handy, but you still need to hunt a bit too hard)
FWIW, I hope the dev(s) work mostly on fixing what we already have (efficiencies) before getting distracted by additional bling ….. it crashes too often !!!!!!!!!!!!!!!!!
Here’s another (on the ipad 1)
When mira is set to mirror the presentation mode, the orientation of live.tab will switch based on whether presentation mode is enabled on the host computer.
It’s probably easier to experience. Try pasting this code in to a blank patcher and switching between edit and presentation mode (remember to set MIRA to only display PRESENTATION)
----------begin_max5_patcher---------- 402.3ociRsraCBCD7L7Uf7YJxjpj.8WopBYHaHN0XirWnIJJ+60XCIjpPUNf er6vNd2YtDFPJUm.CI5inOiBBtDFD3BMDHX7d.ogcpRvLNXDAuGRPVII1mrm okrF3o4Tcn.P7bK3YfPh8e6EJFRh9ZDmrqgKsHcLjdOXgfKASQqFLfDYHWIG P79Hh4wKzPE5YIktNgFGs0sl5VyoIz4r4eXlGJFCqNvk0KVHJcXa07J82G1z SmuyMNTkGeaE4V801wDB5BPxJEvBs53qXdVCqG1UvPTyK6P39IynLMpSCZgn CT6mBOEeN4BkrdI85AflCJM9RHmz2UOIGXasQsWIgAoG+Q41NnA3lC3g+oSx QCd1Ohn97WCCuu4VuFF+hN1Ftlkren5jm42n+uaxo5doeSVx1777rLqaHOMg ZOmmtfshtrs5kqXIq56ZspStatc3ELcoSMJuVprDK3Ue6fNa54XgvZa6AsYr Ttwmc3cToGttI1ckK8WcDQzPOeB+ZWDl11gns85zdyxorMjvAdtF9KPzkiQq -----------end_max5_patcher-----------
@avantronica Thanks for pointing out these discrepancies and even more so your patience as we try to fix all this stuff. Hopefully it’s reassuring to know that "bling" is right at the bottom of my list of priorities. Many of the issues you’re seeing, especially the slow network speed, creaky drawing and occasional crashing are all caused by certain inefficiencies in the way Mira handles drawing. Unfortunately these are going to be at their worst on the iPad 1. But this is my current focus, and I’m hoping that tweaking here will improve the Mira experience across the board.
In the mean time, you can get the most out of Mira by trying to work within memory constraints. Simple UI’s, while less interesting, will load faster and use less memory.
I’ll be sure to keep you in the loop as things hopefully improve. Nah, forget that ‘hopefully’. I’ll keep you in the loop as things _inexorably_ improve.
I appreciate that the end user can sometimes appear to loose sight of the fact that developers can be hard at work by whining about progress. It’s clear now that (amongst many other things potentially) that you’ve been waylaid by porting to windows. If you’re intending to keep us in the loop, I think you could do a whole lotta good by publicly laying out a wishlist/roadmap of the objects you are working to incorporate/enhance ! By this I mean, say (but not promise timescales) that you can/can’t do e.g bpatchers and roughly when/why !! A little transparency. MIRA can be really significant, but as the subset of supported objects is limited I find myself putting it on the back-burner as it compromises my established workflow (i know, baby and bath water) and in turn i guess this slows development because you have less feedback. I’d be inclined to probe more if I knew what was the likely/intended endgame. I restructured a whole project recently to specifically cater for MIRA support only to have my hopes dashed when I realised that bpatchers were not supported ! Maybe you could have a forum page with a focus on object support and discrepancies. I’m happy to do BETA testing if you PM me, especially as I intend to run iPad 1 for a while yet !
Thanks for being so frank with me, it’s really great to be able to talk openly about the whole development process. I get the sense that you’re expressing what a lot of Mira users are feeling, so I’m doubly glad that you’ve taken the time to lay it all out.
People have been calling for a central discussion place for Mira for a long time, so I’ll put some thought towards what that should look like. Part of the delay in getting something like that together is that I don’t think a forum thread is exactly the right place. One big thread is just going to get unwieldy, and a forum topic for Mira, while great, is better for managing a bunch of small topics than one central Mira wishlist/roadmap.
As for bpatcher, I can at least say that it’s quite high on my list. As I alluded to in the last post, memory issues are the biggest focus for me right now. These issues flare up especially in the case of really large patches. I’m worried about releasing bpatcher without addressing these core problems, in that I don’t want to enable this feature without really being able to support it. Hopefully that makes sense.
Thanks again for your patience! I’m hoping that not having bpatcher for now isn’t spoiling your Mira experience too much.