Trying to figure out HOW to troubleshoot - Timers/Cntrl Squarp Pyramid

Okay, still trying to figure out HOW to troubleshoot this.

Because: reasons, i have a pretty complex script (well, complex for an idiot like me) that uses masks in the form of bit mapping for statuses for, in this application, 16 Tracks and their On/Off (Mute/Unmuted) status.

The output is facilitated by a Timer that cycles through an index 1-16, comparing the Masks (is this CC affected or not) to the statuses (a "Layers" mask and a "Group" mask). If the result is "1", then that track should be "On" and I send out the corresponding CC value (0=off, 1+=on).

Everything works okay on the script side of things. Really: I went thru this for months, tested, re-tested, rewrote from scratch multiple times, etc.  I've verified on the logs that what I'm sending out is correct.

I'm hyperfocusing on one specific event, because the problem I'm having is intermittent: <em>sometimes the correct tracks do not update on the Pyramid.</em>

In my tests, I'm bopping around different layers. What I'm calling a 'layer' is more than just a single MIDI Track, but a group of related Tracks. (say, snares & claps would be a Layer together because my relationship might be the same with them, that is, I won't be playing snares w/out claps and vice versa (just for an example))

'nuff said, but basically I'm flipping between 2 of these layers. One of the layers should be only Track 2 which is toggled by sending B0 02 xx where xx=0 for off and 01 or greater for on.

The logs most definitely show that I'm sending B0 02 32 or B0 02 00. All good from the MT Pro side.

But the Pyramid doesn't always respond as expected.

Normally I'd just dump this on the shoulders of the Pyramid, but I've tried overloading the Pyramid with incoming MIDI data, sending CC's to turn on/off multiple tracks at once with keystrokes. In all those tests, the Pyramid behaved completely as expected.

So honestly I'm at a loss for what directions I should take to troubleshoot this. From the MTPro side, it would seem from the MTPro logs it is doing exactly what is expected. In tests, the  Pyramid should respond, but it's not. Of course, unless I start "recording" that data to see what is happening on the other end, I can't really verify the Log is an accurate representation, but I'm not sure that's a proper place to start.

Note: What my Translators actually do is take the note info from a button controller, update some masks, then call two output Timers, one of which updates the LED stats on the button controller and the other cycles through the 16 Tracks in question, compares the 'state' masks for Layers and Groups with the status of "hey, was this turned on or off" and updates the salient CCs.  Really: all that works as expected as evidenced by the logs.

working backwards from the logs I notice when I use the script Tracks don't always update. Moving backwards, one item in particular B0 02 32 should be turning the Track ON and B0 02 00 should turn it off, but it doesn't always.

I have Delays in my Timers (didn't originally). The Test script calls a "DO" 0ms Timer that has an initial delay of 5ms. The CC Output Timer has an inital delay of 5ms and a Repeat Delay of 5ms.

So, finally Question: Where do you think I should go to troubleshoot next?

How about posting the script so we can look. My guess is that there are some asynchronous events happening that update the variables and read the variables and that sometimes the read occurs before the update happens.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

Thanks for the response, Steve.
Appreciate the input, but after 4 months of development time and hiring a consultant (you!) to help with part of the design phase, I’m not really comfortable posting my whole script.

I’d post the salient parts, except for the fact I’ve documented at least in the MTPro Log that it is sending the correct MIDI data. I’m just not ready to dismiss the problem as purely a Pyramid issue since I cannot create an environment to simulate that same kind of glitch.

There is only a single Translator that updates the variables, tho.
There is a Timer to take those variables and output MIDI commands based on the status of those which is where I was going first with troubleshooting.

I thought at first that it was conflicting Output Timers, so I set up a Kill Timer for everytime a Note Event is going to activate the script and then set a Delay for the Output Timers so that Note Events that occur within a few milliseconds of each other will not spit out the Output routine until the final event.

But as mentioned, MTPro is reportedbly (via logs) sending a B0 02 32 or B0 02 00 which turns the Track On/Off respectively. On the MTPro Log Window, the left hand column is Ticks? If so, in one of the test runs I did a printout of the log in a window of 168 Ticks there is only one Event that affects that Track and that failed to affect the Pyramid as expected.

I’m just looking for suggestions on what direction to Troubleshoot.
As noted: MTPro is pretty much working as expected if the Log Window is 100% believable.

other troubleshooting options I can think of:
– Communication error due to hardware? Except that should occur in other test scenarios, which it does not.

Stupid question: On the Log Window of MTPro, the left column are…ticks? Whut?

Left is milliseconds if I remember correctly (if you turn timestamp on).

If the log is correct, then the issue must be either with the Windows MIDI driver or the Squarp itself. I’ve seen scenarios with other controllers that sending a lot of MIDI can overrun the controller and make it crash. The only other suggestion I would have it to slow everything down by adding delays.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz

Thanks, Steve. Yup, have Timestamp on so ms it is. Good to know. I’ve been experimenting with delays and it seems so far that delays help, but don’t fully resolve. So given your comment on the Windows MIDI driver, I’m thinking I will dump the script on the Box and try it from there. Note: I’ve been using an extra laptop in place of the Box for development because I have to update my ‘masks’, and that’s easier to do on a laptop rather than just editing on the laptop, logging in to the Box, uploading, restarting, etc. 🙂 THANK YOU! You have given me the next step in this nightmare. EDIT to Add: Just increased all my delays to 15ms and I haven’t been able to duplicate the issue. This is strange because as an earlier test that I think I documented in my OP was that I tried a test of sending 16 CCs in one Translator all at once trying to overload the Pyramid, and everything worked as expected. That is, set up a Translator that took incoming keystroke ”A” and sent B0 01 50 thru B0 10 50 all at once and keystroke ”Z” sent B0 01 00 thru B0 10 00. Flipped them back and forth repeatedly and quickly and nothing even stuttered or jittered or barf’d or anything. Which is why I feel like I’m taking crazy pills. LOL Thanks again for the next step. Will update if this resolves anything or illustrates anything even more WTF.

Ok, Jim.
Good luck!

Okay, have some data.
Posting it here in cas anyone searches for it.
I know there’s at least a few BomeBox & Pyramid users out there, so in case anyone is searching on here, they can find this info.

In the scenario above, I was using PyraMIDI to Mute/Unmute Tracks via CC’s coming from MTPro that are triggered from a button controller. (Because: reasons – 64 Tracks, but 4 banks of 16, plus standardisation because I’m an idiot. etc)

However, my original incarnation of my script didn’t do this because Track Free Mode didn’t work for my application (I like to change meter, and Free Mode is not compatible with this) and Relatch Mode would start anyone newly introduced melodies/rhythms from “1”.  By setting everythign in Relatch Mode, but still having control over what is Mute/Unmuted allows me to approach a passage of music, set all salient Tracks at “1” together, then sculpt which Tracks play improvisationally.

However an OS update or two ago they introduced being able to restart all Free Mode Tracks by repressing the [Play] button. So my not-yet-fully-implemented MTPro script was quickly switched to using PyraMIDI to Mute/Unmute Tracks.

This is where it all goes wrong and I get the issues as described by my rantings above. Incidentally, increasing Delay times on my Timers increased accuracy, but at the cost of timing.

However, I switched back to my original plan (pre OS update) and things work exactly as expected.

That is, instead of directly Muting/Unmuting Tracks, I add a MIDI Effect of “Chance” on the Track, set the Chance to 0%, and then Enable/Disable the MIDI Effect via CC.  These changes are immediate and I have yet to crash the same script. (a couple of minor script changes necessary, but nothing that affects timing – actually, I got rid of any delays)

So, PyraMIDI:bad. External CC’s controlling MIDI FX: good.

And like the rest of my life, this will probably affect no one else.
Thank you for joining us this weekend and be safe!  🙂