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.
The logs most definitely show that I’m sending B0 02 32 or B0 02 00.
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.
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).
So, finally Question:
Marked as spam
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.
Thanks for the response, Steve.
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.
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.
other troubleshooting options I can think of:
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.
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.
Please log in to post a topic
(this is your bome account, not the old forum account):.