Midi Leaking on Preset Hot-Swap
I'm trying to prevent my max for live device from sending out any midi when it loads. The logic above works great when I drop the device onto a midi track and when I hot swap to my first preset. However, at times when I swap to presets after that the midi data will sneak through. Also I noticed if I hot-swapped to the original .amxd and then to the desired preset (.adv) no midi leaks.
I've tried a couple iterations of the logic above using loadmess, loadbang. live.thisdevice and number boxes with their parameter order set accordingly and this seems to be the most consistent so far outside of the quirks mentioned above.
As always if anyone has any insight or advice into why it might be acting this way I would very grateful. It's not device breaking, but it's clunky enough on the user end I want to try and get to the bottom of it.
Have you tried to omit the number box. A gate will be closed by default (btw who needs a graphical gate?) you don't have to set it to zero.
Just tried it, now the midi gets through as the device is loaded. Out of habit I grab the graphical gate when it's just 2 outputs or inputs. Not sure why ha
ok now I understand. loading a preset is not like loading the amxd. It's only updating the parameters.
So the gate will remain open. But the [live.thisdevice] bangs also on preset load.
Now with loading time you mean the time before the [live.thisdevice] bangs or the 400ms after?
This works after bang. But I don't know if midi can get through before the bang as this test device is loading presets really fast.
Found a solution!
"loading a preset is not like loading the amxd. It's only updating the parameters"
was the key phrase that helped me solve this, thanks 11olsen!
I needed to use the number box as before, but I needed to make sure it was unique to each preset. There are probably multiple ways to do this, but this is what I came up with...
As side note, in my particular situation this cleaned up the preset leaking only to a point, but it was enough to spot the last issue. I had a particular bPatcher loading two patches based on button click instead of using a more common "offset" command to move around a subpatch. I believe loading the subpatch after the fact messed with parameter order and bypassed some of the above logic. Once I went back to an "offset" command style setup my issues were gone. bPatchers have officially been the death of me on this project, but definitely teaching me a lot.
The above screenshot should do the job for most people trying to solve this specific issue unless you're doing funky things with bPatchers like me.
Ok, so in every preset it has a unique number (with a [random] set to a high number you can do the same without adding date values, but ok). I still don't understand what "midi leaking" means in this case. Midi going through your device with the preset/state from before or really bypassing your device?
I would load a preset and bunch of midi values would be sent out of the max for live device. The values would be for that preset that was loaded. This was not desired because the receiving device could not make sense of that many parameter values all at once so only some of them would be received.
I called it "leaking" because I had already built in the gate to block this from happening, but midi would still get through only on preset hot-swapping.