Preset recall crashes Max when done from Mira, but not from patcher
Before I start on ripping apart the whole pattrstorage system in a large performance patch, a very broad question…
Does anyone else have this experience? …
Using live.tab in Mira (to recall presets in a complex patch) … clicking on the live.tab in the patcher window with the mouse works just fine. As soon as I do it from my ipad, max crashes instantly.
Also, if I use some other way of _selecting the preset I want from Mira (eg using a umenu, with the selected umenu item number stored in an int) and then use a bang in Mira to actually send the preset number to pattrstorage, I also get the instant crash.
I thought I had a way around this - I put preset objects in all of my subpatchers, and used a live.tab to recall the slots. I’m pretty sure this worked before (this problem has been around for a while), but now I’m finding that this also crashes when done from Mira (but not by clicking in the patch).
I suspect it might be something to do with either recalling a whole lot of object settings at once, or the timing of the recalls, or perhaps some sort of accidental loop, but the fact that nothing goes wrong when I click on the computer screen and yet it crashes when I try and do it from Mira is confusing the hell out of me.
(Also, if I try and autoload the first preset on starting up the patch by using (eg) [loadbang]->[t b 1]->[umenu/int]->[pattrstorage], the software generated bang crashes Max. Yet if I remove that bang and then load the settings by manually clicking a [button] to generate the bang - no crash)
(It's not an inherent problem with live.tab in Mira - I already checked that out with a simpler patch.)
I realise this is a very amorphous issue, (and the patch is too large (& involves 3POs) to post, though I can specify the exact steps I follow and what's happening in the patch if it's of any help), but if you have any general thoughts about why all this might be happening, it might help me either track down the issue or find a way around it (by giving me an idea as to _where else to look!)
thanks!
All I can say is that I have had issues with Mira crashing Max that were hard to track down. I found the most stable setup was with a more recent iPad and Max 6. You could try putting a small delay in somewhere between the Mira control and what it triggers (likewise with the loadbang) but essentially it is a bit of a hack and you may need as little latency as possible, I don't know. In cases like these with a big patch and little clues, I just start deleting chunks of it at a time and seeing when the problem goes away. Then I reinstate the bit I deleted and look at it more closely to find the exact problem area until I get down to the simplest patch possible that still causes the crash. That way you have something to post or send to support if you still can't see the problem. Apparently a new version of Mira is being Beta tested right now so that may help you out.
thanks Luke
I finally remembered that the last time this problem appeared, I somehow managed to track down the issue to a umenu in one of my bpatchers that is used to tell a polybuffer~ which folder of sounds to load. Manually selecting a new global preset...
live.tab->umenu (preset names)->pattrstorage / pattstorage recalls umenu (sound sets)->polybuffer~
worked fine. But for some (so far) inexplicable reason, doing the same thing from Mira...
offscreen live.tab->main live.tab-> umenu (preset names) -> etc
instantly and reliably caused the crash.
Once I disconnected the sound set umenu from its local autopattr, the problem went away. I'm sure that must point to some issue, but i have no idea what!
So what I've done is to again disconnect the offending umenu from autopattr, and instead I've added a little bit to the live.tab that recalls the presets whereby that live.tab triggers the sound set umenu a half second after the general settings are recalled. It means that I've had to "hard programme" the sound set numbers in...
main live.tab-> [sel 1 2 3 etc] -> message boxes with the number of the umenu slot that I want to recall-> sound set umenu
which will obviously only work as long as I don't change the number of sound set folders that get loaded to that umenu! (ie add a new folder, and sound set 3 suddenly becomes sound set 4. oops) but it'll work for the upcoming performances, and I can figure out a way of modifying the numbers being called later (maybe I can call a umenu slot by contents of slot (ie sound folder name) rather than slot number? No idea - I'll have to check).
I normally do this sort of thing with my umenus so I can save my media in folders next to the patch and call them by name. If you set the umenu to auto populate and put 'fold' in the file types it will only pick up folders and not patches.
I have a "project name_media" folder that lives alongside the Project folder, and which I add to the Project search path. Inside that folder I have named subfolders containing the various categories of files I want to access, and then I load them in Max like this...