Strange behavior on MIDI Ch. 3

Something to try ...

Okay, something to try:

  • Set up an MFC preset with only FOUR IA Switches in the "on" state for a preset that will exhibit the problem
  • Verify that the problem doesn't happen
  • Set up one of the Internal CCs to send a Control Change command (it would be the FIFTH)
  • See if the problem appears - it should if its a race condition, but less often.
  • If the problem still doesn't happen, keep adding Int.CCs until you have 6 or 7 or until it happens again. My guess is that it will happen when the combination of IAs and Int CCs exceeds 5 or six.

The Int. CCs are much like switches. If they are selected "on" for a given preset, the ON value is sent when the preset is selected. I can see from your sysex dump that none of the Int.CCs are being used. Try using them instead of the IA Switches to send initial on values when selecting an MFC preset and see if that makes any difference at all.

One thing that I do notice and appears unusual to me is that you have IA Switches 1-TREMOLO1(HOLD BS), 2-TREMOLO1(HOLD TL), 3-CHORUS2(TAPbs), 4-VOL DECR(TAPtl), 5-COMP2(TAPm) and 16-TEMPO(TAP) all set to "Momentary". Now, I know that you're not connected to an Axe-Fx but a "Momentary" switch will send the the two (CC0 and CC1) CC "ON" messages when depressed and the "OFF" messages when released. I don't know that it makes any difference - it may be your intention - but I thought it did stand out as unusual.
-G
 
Thanks. Trying your suggestions with a couple mods.

bwanagary said:
Okay, something to try:

  • Set up an MFC preset with only FOUR IA Switches in the "on" state for a preset that will exhibit the problem
Click to expand...

The state of the switch (ON or OFF) isn't the critical path, because commands are sent either way. Its whether or not the switch "Sends with Preset" (Determination made in the SETUP menu). With that in mind, I disabled every IA switch from sending with preset. Problem vanished (as in my testing before).

I enable Internal CC values one at a time until I saw the problem appear again. It happened at 6th one.

I reset from my backup, but this time repeated an earlier test to find out how many IA switches send with preset to demonstrate the problem. It was 6 (it was probably 6 before, I wrote 5 from memory since I posted well after I ran the test).

This time, I followed your test more closely. I disabled "Sends with Preset" for all but 5 IA switches. Problem went away. I then enabled 1 InternalCC switch. The problem appeared, but you are right in that it seemed to be happening with less frequency. Maybe worked 2 or 3 out of 10, just using empirical observation.

bwanagary said:
The Int. CCs are much like switches. If they are selected "on" for a given preset, the ON value is sent when the preset is selected. I can see from your sysex dump that none of the Int.CCs are being used. Try using them instead of the IA Switches to send initial on values when selecting an MFC preset and see if that makes any difference at all.
Click to expand...

I basically ran that test first. 6 Internal CC switches cause the problem.

bwanagary said:
One thing that I do notice and appears unusual to me is that you have IA Switches 1-TREMOLO1(HOLD BS), 2-TREMOLO1(HOLD TL), 3-CHORUS2(TAPbs), 4-VOL DECR(TAPtl), 5-COMP2(TAPm) and 16-TEMPO(TAP) all set to "Momentary". Now, I know that you're not connected to an Axe-Fx but a "Momentary" switch will send the the two (CC0 and CC1) CC "ON" messages when depressed and the "OFF" messages when released. I don't know that it makes any difference - it may be your intention - but I thought it did stand out as unusual.
-G
Click to expand...

I'll talk about what these are doing, but keep in mind that none of those switches are set to "Send with Preset" anyway so they don't factor into the equation.

IA 1 and 2 are in fact tied to Momentary functions. Those are for the "Infinite" decay in the BigSky and the "Infinite" repeats in the Timeline. I hold them down while I want the effect, then I let them go.

IA 3, 4, 5 and 16 are Tap Tempos. Here is where guidance wasn't available for using MIDI mode and "Tap" buttons and I had to figure out the best way to handle it. I didn't like TOGGLE because the light would illuminate with every other press (and maybe stay illuminated when I was done tapping). AUTO-OFF was explicitly for sending both On and Off with one press instantly. Also, the light doesn't like quick taps .. it gets funky. MOMENTARY works well from the light perspective, and as long as I had the "CC OFF" value set to "OFF", it doesn't appear to send anything. Turns out it works well that way and I even made IA 16 into a combo tap for both the Timeline and Mobius.
 
If you recall, I said that I could create the problem just with this MIDI Chain: MFC -> Event Processor -> BigSky -> EVH

If I replace the BigSky with a Timeline or Mobius, problem does NOT occur. That still holds true, but I did another test with very perplexing results. I moved just moved the BigSky earlier in the chain. I expected that there would be other problems downstream similar to the EVH, but just opposite. Everything worked, including the EVH. Just to be clear ..

These two chains do not work:
MFC -> Event Processor -> BigSky -> EVH
MFC -> Event Processor -> DPC -> ABY -> FootSime -> Mobius -> Timeline -> BigSky -> EVH (this is my typical chain)

But these two chains do:
MFC -> Event Processor -> Timeline -> EVH
MFC -> Event Processor -> BigSky -> DPC -> ABY -> FootSime -> Mobius -> Timeline -> EVH (Just moved the BigSky)

I going to write Strymon and have them take a look at this thread and see if they have any ideas or insights.
 
Last edited:
Okay, this is where your experience with MIDI will come in handy because my first exposure to it is through my development of MFC-Edit. From what I can see MIDI is a half-duplex protocol - without a handshake/ack/nak. Unless the MIDI protocol has some feature that excludes it, I suspect that the 6 CCs being sent are all that the BigSky can buffer and respond too. I haven't counted the bytes but my guess is that each CC message is about 4 bytes in length (Chan, msgType, the CC# and the o/off value?). Four messages is quick succession would be 16 bytes - not an uncommon buffer size for a MIDI message. It could be that the processor is consuming/parsing that buffer and executing commands and by the time the 6th/7th message arrives there is something like a buffer overrun or even some bits dropped/flipped and improperly processed. I'm assuming that no other device is sending MIDI commands into the BigSky other than the MFC. If more than one device can send messages to the BigSky then its anybody's guess what's possible with the MIDI protocol. If MIDI is reasonably respectable then messages are delivered intact on the channel, though possibly not guaranteed to arrive in the exact order they were transmitted from distinct devices? If MIDI isn't well-behaved messages might get "merged"? I'd be astonished if the MIDI protocol were to permit that possibility and would much rather suspect that the receiving processor can't keep up with stream of incoming messages, not because the processor is slow, but because of the your description of its functionality. I understand it to be something like a "proxy" that performs (typically) multiple operations after receiving each MIDI message. Depending on how many operations it performs (like sending multiple messages to multiple devices) and how long those operations take it could possibly drop an incoming message on the floor or mangle it.

Okay, I know I rambling and thinking out loud. I don't have an answer for you right now but hopefully I'll say something that will awaken some instinct in your MIDI experience and knowledge-base that will lead you to the solution. Have you tried putting a MIDI "snoop" in front of the BigSky to see exactly what's hitting it's MIDI-In and when?
-G
 
RockDebris said:
If you recall, I said that I could create the problem just with this MIDI Chain: MFC -> BigSky -> EVH

If I replace the BigSky with a Timeline or Mobius, problem does occur. That still holds true, but I did another test with very perplexing results. I moved just moved the BigSky earlier in the chain. I expected that there would be other problems downstream similar to the EVH, but just opposite. Everything worked, including the EVH. Just to be clear ..

These two chains do not work:
MFC -> BigSky -> EVH
MFC -> Event Processor -> DPC -> ABY -> FootSime -> Mobius -> Timeline -> BigSky -> EVH (this is my typical chain)

But these two chains do:
MFC -> Timeline -> EVH
MFC -> Event Processor -> BigSky -> DPC -> ABY -> FootSime -> Mobius -> Timeline -> EVH (Just moved the BigSky)

I going to write Strymon and have them take a look at this thread and see if they have any ideas or insights.
Click to expand...

Ah, I just saw this after pressing the "Post" button. Sorry I haven't been much use. That's about all I have time for at the moment. I know that sometimes it takes persistence and dogged focus to isolate problems and I apologize that I can't see this one through to the end due to lack of bandwidth. At least so have a workaround of sorts.

Good luck with it.
-G
 
bwanagary said:
Ah, I just saw this after pressing the "Post" button. Sorry I haven't been much use. That's about all I have time for at the moment. I know that sometimes it takes persistence and dogged focus to isolate problems and I apologize that I can't see this one through to the end due to lack of bandwidth. At least so have a workaround of sorts.

Good luck with it.
-G
Click to expand...

I don't blame you dude, I glad you stuck with it this far! Thanks. Checking out your prog tonight, btw. I need to be able to sort songs automatically!
 
RockDebris said:
I don't blame you dude, I glad you stuck with it this far! Thanks. Checking out your prog tonight, btw. I need to be able to sort songs automatically!
Click to expand...

Right-click on the SETS page to sort within a set.
Sorting within the SONGS page requires a "secret" handshake - to prevent users from hosing up their sets. Because SETS use an index into the SONGS list, reordering songs and renumbering them can really hose them up. If you just want to sort alphabetically for viewing you have two options on the SONGS page:
a) Right-click on the SONGS page and choose "Sort Songs by Name" from the popup menu
b) Click on the column-header of the Song # or the Name.

If you want to sort and renumber the songs you'll have to choose "Renumber Songs" - you will be warned that your Sets are gonna get hosed up. There's a magic sauce that I won't publish here to allow access to the power features of the program. Only in a private message. See if the Sort works for you the way it is and if not I'll send you the secret to access the power features.
-G
 
You must log in or register to reply here.
Back
Top Bottom