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

Thanks for your response. I had this on my mind for quite some time. I tested several Output variations using simple code and a button to send a Chan 1 CC midi and monitored on MDP log.

IF LOAD
 ASS I0 = 00
END
SND B2 I0 0A
ASS I0 = 01

With MDP running, I0 = 00 did not occur (expected)
Activating another app and then reopening MDP also did not trigger the LOAD
However, editing the SB code (I changed SND from 00 to 0A) did trigger the LOAD statement
AND closing the MDP so it was not running in the background and then reopening also did trigger the LOAD

Neither is desirable to implement, thus the only viable solution is, as you said, set up a button to initiate any variables at the beginning of a session that uses SB.

For the Input SB it may be that the only viable approach is for the user to close MDP so it is not running, then reopen it to start his session or find a way not to require any initialization.

Except for the initial run, I program to initialize and set variables and don't have issues. I may have to start a procedure more than once to get SB in sync. This occasionally leads to erratic behavior the first time or 2. I will use an Initialize button since I also have some buttons that get out of sync with other buttons and can set them to default at the same time.

I suspect MidiFire SB in iPad has the same behavior. But in a computer environment, I believe when MidiFire is closed and then reopened later, LOAD will work.

---

Restarting my iPad did not trigger the LOAD

---

I think a more robust indication is a snd statement inside the load statement.  This precludes any variable initialization artifacts from giving a false indication of a load.  Might explain why I saw the load get triggered less than you did.

---

I think that would be true if I used complex code to test with. I generally use MidiMonitor, which needs a network connection to receive midi. I used the log as well and received matching results since my SND occurs after the code is loaded, which is normal operation.  In my situation, midi will pass thru as long as I0 is 0 (initial condition). Activation of SB code is triggered by a SysEx which changes I0 to 1. When the procedure is complete, I0 is reset back to 0. On rare occasions, if I0 is 1 and not 0 when MDP is started, the code will run when it is not supposed to.

---

Thanks all. I've been testing with just one simple send in the on-load and I think it was 100% broken.

---

I was just observing that setting the variable inside the load, and reporting the variable outside the load statement, you were getting two false indications - when the variable space was initialized, not when the load statement was called.

---

Not sure what you mean by false indications in my test setup. I0 is only set to 00 when the IF LOAD is called. It is set to 01 only outside the load. My tests indicate exactly that. If the load is actuated, the first test message I send shows I0 = 00. After that, I0 shows 01 for each test message. I see the load runs when a rule is installed, when a layout is loaded, and when the iPad is shut down and then restarted, which I think is the same as loading the layout. When the log indicates the Output Rules were installed it also indicates Input Rules were installed. This causes the IF LOAD to run for both Input and Output at the same time. My initial question has been answered for 2.200 beta. Thanks to you and Dan.

---

Okay so to sum up and focus on the App... we're pretty happy with the latest Beta?

Thanks Don & JK for the expert help with this advanced stuff.

---

I think so.  I see output rules loading in all four cases above.  I see input loading in three of the four - don't see them trigger in the "layout load" condition, but maybe a problem with my test setup.  If 7 of 8 conditions working, don't know why that one case wouldn't.

And now the load only triggers the rules inside the IF LOAD.  IF NOT LOAD is properly assumed for all remaining rules.

One more note - if load does not happen on install in design mode - but that seems appropriate.

---

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.