When does IF LOAD actuate in SB?

Question

MIDI Target Manufacturer(s): Other/Unlisted Maker

I think I occasionally have problems with SB code that has not been initialized when I activate MDP. MDP is usually open (in standby) on an iPad even though another app is active. When is IF LOAD ... END in the StreamByter plug-in triggered (usually to initialize variables)?

a. Anytime MDP is activated from a standby state (doesn't seem likely)

b. When MDP is activated after being closed (cleared), which I occasionally do to clear up memory

c. Only when a layout containing SB code is loaded via Configuration, Actions, Load Layout (seems likely, but not desirable)

d. Never

If c or d, I may have to manually initialize SB variables before using the layout (creating a button to initialize)

Comments

I use if load for initialization, and have not had a problem with things being initialized.  But maybe I am missing something and haven't noticed that they were not initializing.

Easy enough to test when they get initialized - add a SND statement with a dummy sysex message and use a midi monitor and MDP2 log.

---

I would expect (c) above.  But I am not seeing the test message get generated.  One quick workaround for the output rules would be changing the IF LOAD to look for a specific dummy sysex message, then send that message for initialize.  A workaround for the input rules is more difficult - either have to bounce a specific message off the target device, or send from a third app.

---

There's a lot going on here, but I think the answer is "never" and "we've fixed this in the latest beta." It'll load whenever connections change from 0 to > 0, and also on install etc. Thanks!!!

---

Thanks! It's really not "Never", even in beta. My earlier comments to jkhiser's Answer were using 2.190. I reran using 2.200 (beta) and got the same results. Initially I missed that loading the layout did trigger the SB LOAD. As I stated in an earlier comment to this post, using an INITIALIZATION button seems to be the only viable operational solution.

BTW, the $127 worked in beta. I particularly want to try the delay over the next few days and will report back to TestFlight.

Answer 1

Was Broken, Now Fixed in Upcoming Release

Looking at the code and considering what you and JK have discussed, the answers are:

1. Never. It was never called.
2. Now fixed in 2.200+ (coming soon).This will get called:
   • on rule install
   • on layout load
   • on first-start layout load
   • on connection change from 0 to 1 or more connections

Thanks!

Comments

GREAT!!! Can't wait to test it out. See my earlier comment to your earlier comment.

---

Just tested and saw all the above loads happening, both on input and output rules.  As you stated, when more that one of these happens at the same time, you get multiple calls of the load.  Since these happen simultaneously, should not have any problem effects  - just need to know that the load might be called more than once.

---

2.200 build 210609 looks good.  Now seeing all eight cases are working: input and output: cold load, install, layout load, active connection.  The holdout was layout load input, where the rules were running before the controls were ready to be affected - but now good!

---

That's the version I have. I find rule install, load layout, and starting MDA after closing so it doesn't run in the background will execute LOAD. Using a Wi-Fi connection, I don't find Load runs by disconnecting and reconnecting the Network Connection either from MDA or my computer. I use the log to verify both Input and Output Loads occur simultaneously.

I still think in my situation I need an Initialization command as a backup to initialize MDA controls as well. My iPad is not dedicated to MDA. For memory purposes I periodically do have to Quit all open Apps (including MDA). Perhaps I could add a SND in Input Rules to initialize MDA controls when LOAD occurrs.

Thanks Again!!!

---

While I don't understand all of this, just to be clear you have to go from NO connections to some connections to get Load to trigger. We've added a 750ms delay in the latest version on TestFlight which occurs on layout load but doesn't occur on connect.

---

Ok, Ok - I was able to see the Rules being installed in the log and verified the LOAD variable was initialized when I disconnected and reconnected in Config. This is the most likely to be used by me.

---

re: "I don't find Load runs by disconnecting and reconnecting the Network Connection either from MDA or my computer."

I do get if load to activate when I initiate a wifi connection from either iPad or Mac, same for bluetooth.

re: "Perhaps I could add a SND in Input Rules to initialize MDA controls when LOAD occurrs."

Concur - this appears to be a nice hidden feature - you can send in to the layout to initialize controls on load.

Answer 2

Was Broken, Now Fixed in Upcoming Release

Looking at the code and considering what you and JK have discussed, the answers are:

1. Never. It was never called.
2. Now fixed in 2.200+ (coming soon).This will get called:
   • on rule install
   • on layout load
   • on first-start layout load
   • on connection change from 0 to 1 or more connections

Thanks!

Answer 3

Spent some time playing with SB load in the beta.  Looks like the “load” is not triggering.  I think I managed to get a load event one single time.  Think (but don't know) that was when I did a clean load with a layout without any SB rules, created a new layout, then installed SB rules.

Next two are suppositions:

1. Suspect in Nics stand-alone implementation he has some flag when rules are recalled to trigger the load event.  The current beta log does show input & output rules installed, which is prolly when the load event "should" get triggered in MDP2. 

2. Suspect that MDP2 ends up with a single, continuous instance of SB, which is very persistent, and may even preserve variable values between layouts.  This comes from trying to figure a workaround as follows: instead of if load, tried something like if i0 = 00, ass i0 = 7F, (other desired load code here), end.  This will only get triggered a single time, implying the SB environment is preserved - leading back to 1.  (Although now have another idea to check.)

Workaround for now is:

• Outbound code manually initialize with a unique sysex message.  
• Inbound code, will require requesting a unique status report from the board that will only be received during init condition.

Comments

Great, thanks for testing. Amusing note about IF NOT LOAD: great way to put it.

Random note about other things we don't have hooked up: StreamByter can also modify labels on the fly. So at some point, we'll probably allow you to source labels to StreamByter.

---

What version do you use? I use 2.200. I see LOAD acivated for layout load but not connection from none to connected.

---

Organists tend to use Novation Launchpads and often complain about properly labeling Stops, such as Diapason, Bourdon, etc. This is true especially when changing organ sets. They often print a template and have to overlay it and make it stick. Not easy..

Creating an X-Y layout and being able to change labels could possibly sway them to try MDP. Great idea. How about being able to add colors to labels. Some Stops are occasionally colored (red is common). This is used in my layouts now but the workaround needs the labels in the foreground overlaying buttons, but often end up in the background.

---

"What version do you use?" - 202106050738

---

Aka 210605 on the welcome screen, which is year month day. So is the longer number from config > about, but also adds hour minute and year is full four digits

Answer 4

Spent some time playing with SB load in the beta.  Looks like the “load” is not triggering.  I think I managed to get a load event one single time.  Think (but don't know) that was when I did a clean load with a layout without any SB rules, created a new layout, then installed SB rules.

Next two are suppositions:

1. Suspect in Nics stand-alone implementation he has some flag when rules are recalled to trigger the load event.  The current beta log does show input & output rules installed, which is prolly when the load event "should" get triggered in MDP2. 

2. Suspect that MDP2 ends up with a single, continuous instance of SB, which is very persistent, and may even preserve variable values between layouts.  This comes from trying to figure a workaround as follows: instead of if load, tried something like if i0 = 00, ass i0 = 7F, (other desired load code here), end.  This will only get triggered a single time, implying the SB environment is preserved - leading back to 1.  (Although now have another idea to check.)

Workaround for now is:

• Outbound code manually initialize with a unique sysex message.  
• Inbound code, will require requesting a unique status report from the board that will only be received during init condition.