My PF and TF are both sending unwanted MIDI messages when the algorithm changes… details

[feralchild]

Hello, I think I have discovered a possible bug…

When using the rotary encoder to cycle through the 10 algorithms, occasionally (maybe 10-15% of the time?) a MIDI message is sent. This also happens when cycling through my saved patches, whenever the algorithm changes.

Using MIDI OX, I logged some of these messages:

 TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT  
 000F596B  12  —     D8    F1    —    9  —  Channel Aft 
 000F9701  12  —     FB    —    —   —  —  Continue 
 000F9E15  12  —     B0    E8    A0    1  —  Control Change   
 000FB3C0  12  —     FA    —    —   —  —  Start                
 000FB3CE  12  —     FE    —    —   —  —  Active Sensing
 000FBC0B  12  —     FC    —    —   —  —  Stop
 000FCF74  12  —     B0    48    00    1  —  CC: Release Time
 000FD588  12  —     F7  Buffer:     0 Bytes   SysEx End
 000FDE99  12  —     EA    F0    F4   11  —  Pitch Bend

* It only happens when the algorithm is changed, i.e. switching from Diatonic > Quadrovox on the Pitchfactor.

* I Tried Disabling CTL XMT, setting OUTPUT to THRU, these settings have no effect.

Turning MIDI CLOCK OUT to OFF seems to stop these messages from being sent. However, I need MIDI clock to be ON because I am using my Timefactor to control tempo on my 2880 looper. The problem obviously is that the errant MIDI messages are starting/stopping the looper at unwanted times, and possibly disrupting other devices in the chain as well (my SL has been freezing from time to time).

My MIDI path is as follows:
Timefactor (clock out only) > Pitchfactor (clock in, midi thru) > Novation SL > 2880

Firmware version:
3.0.0[19]
(both)

I'm about to try putting the beta 3.5 firmware on both and see if anything changes. I'll report back on this thread when finished. Thanks for reading…

[feralchild]

Update: the beta firmware doesn't seem to be helping…

To simplify, I tested the PitchFactor by itself (v3.5.0b)… using the following settings:

CTL XMT: OFF

OUTPUT: XMT
CLK OUT: ON
CLK IN: OFF

… and connecting it directly to my SL MKII which is connected via USB to MIDI-OX. The issue persists.

I thought that perhaps the generation of the MIDI clock message (0xF8) is being occasionally interrupted by the algorithm change, and the wrong message is being sent (i.e. 0xFA – "start").

Could this be possible? And if this cannot be resolved, what are some possible workarounds? For example, a device could be programmed to filter out all but MIDI clock messages… practical?

thanks

[brock]

Well, I'll be.  I'm seeing the same phenomenon in 3.5.0beta[3] in the PitchFactor.  I don't have the TimeFactor, but I have many Novation keyboard controllers.  I've seen spurious MIDI messages when the Novations get older and accumulate dust & debris.  That isn't the cause here.

But I ran the (no MIDI input  – THRU – Clock In) PitchFactor straight out from my MIDI router to Bome's SendSX MIDI monitor.  One quick test, and I'm seeing the same kinds of MIDI messages that you are, when turning the encoder.  I even got a few isolated Note Off messages, and some undefined F9&h messages.

For some reason, the non-System Real time messages seem to favor MIDI channel 1, or channel 9.  Very strange.  I'm going to experiment with this a little more.  Nice catch.

[brock]

Quote:

a device could be programmed to filter out all but MIDI clock messages… practical?

I wouldn't be in favor of the 'Factor pedals incorporating that kind of 'slash-and-burn' solution.  As for an external device, I'd suggest my favorite go-to MIDI toolkit – one of the MIDI Solutions Event Processors.

I run a fairly complex MIDI routing, and I'm thinking aloud on how this could adversely affect it (assuming that I was changing algorithms in a mission-critical situation).  Start / Stop?  That's usually generated 'upstream".  Active Sensing?  Totally screws up an FCB-1010 pedalboard.  Aftertouch, Pitch Bend, and CC messages?  Most certainly.  Note Offs?  Could be problematic.

The other semi-innocuous messages?  Maybe not so much.  I guess what really bothers me is that – for as often as I have a MIDI monitor up – I've never noticed this before.  Then again, my patch programming sessions are usually isolated from my recording or live situations.

[nickrose]

We have seen problems on Windows when sending MIDclock – this particularly affects FactorLib. My guess is that the MIDclock breaks up other sequences and the Windows MIDI system can't handle it.

[brock]

Quote:

the Windows MIDI system can't handle it.

Good point, Nick.  That may be the common denominator here.  By that, I take it that you mean our MIDI monitors are displaying 'ghost' MIDI messages, and the spurious messages themselves are generated 'in-the-(Win)box'.  Interesting dilemma here.   Now to get some of our Apple-based members to chime in.

I have an old Roland MC-50 sequencer that I may be able to kick-start.  It has a rudimentary MIDI monitor (I believe it displays by Command Set, not individual message type).  Or use it to record encoder moves straight out of the PitchFactor, and see what pops up (if anything).

That might satisfy my curiosity.  No matter where this is generated, I'd like to find out a little more about it.  I'm still on the fence on how deeply this kind of thing would impact me.

[feralchild]

Thx for the responses.

Nickrose, even removing Windows from the equation entirely, I can confirm that the Pitchfactor is at least sending unwanted play/stop messages, because, when I plug it directly into my 2880 looper, it occasionally starts or stops in response to an algorithm change on the Pitchfactor.

[nickrose]

We'll have to look into it once we get more information. I don't believe that play/stop messages are being normally generated by the PF. The fact that they are very similar to MIDIclock messages may be relevant – if MIDIclock is getting corrupted by either the sender or the receiver it might explain things.

Can you try just connecting your PF to MIDI-OX ? I tried this and cannot duplicate your problem. It may be associated with your other equipment and thus be hard for us to see.

[brock]

No need for me to repeat the "PF straight out to MIDI monitor" test (see reply above). 

I hooked a MIDI cable directly from the PF's OUT/THRU to the MIDI IN of an ancient drum machine [Yamaha RX-7].  A few spins of the encoder, and a START message kicks in the drum pattern.  I went in to the PF system settings, left the OUTPUT on THRU, and set both the CLK IN and CLK OUT to OFF.  I still got a START message to kick in the the drum machine.  I went through a few dozen variations on that theme.

You have to have a MIDI cable inserted in the PitchFactor's MIDI In jack to reproduce this, and I believe that a MIDI clock signal also has to be present on it (whatever the PF system clock settings are set to).  The corrupted clock theory is gaining credibility, but it's not just a Windows problem.

I think that's enough wear-and-tear on the encoder knob for one evening.

[feralchild]

Good evening gentlemen.

I tested again, this time using my Tascam US1641 (usb interface) instead of my Novation SL. (So, Pitchfactor > US1641 > MIDI-OX). I got the same results. Also, I can get it to happen with just hardware–no computer involved.

When testing, you may have to turn the encoder for a while before you start seeing the errant messages.

Brock, yeah, this is consistent with what I am seeing. In order to replicate the issue, the 'Factor pedal must be transmitting some kind of MIDI clock. If CLK IN/OUT are set to OFF, and/or OUTPUT is set to THRU, then there must be another clock source going into the 'Factor's MIDI IN jack or it won't happen.

If there is no clock being sent, the issue does not seem to occur.

[nickrose]

Sorry guys – I tried this with Borne SendSX V1.22 on my Win7/64 PC and don't see it. My guess is that it depends on the receiver. I'll see if we can put a bit more white space around the MIDIclock – that might be helpful for the more laggardly MIDI systems.

Another possibility is that some MIDI systems can't handle a
MIDIclock being inserted in the middle of another MIDI message – this is
allowed by the standard (MIDI V1.0 (4.1), p.35, or (4.2) p.30), but I
can believe that it might cause some hiccups to some.

I see no evidence yet that the problem is in our product. The fact that Mr Feral gets this problem with TF set to MIDI THRU and an external MIDICLOCK source would appear to back this up (please let me know if I misunderstood this last point).

[feralchild]

Thanks again for your time Nick (my first name is Josh, by the way, pleased to meet you). I'm surprised that you haven't been able to replicate it yet. May I suggest that you try setting the tempo higher? This might increase the likelihood of a corrupted interrupted clock signal (I was using around 110-120).

nickrose:

Another possibility is that some MIDI systems can't handle a
MIDIclock being inserted in the middle of another MIDI message

Is it significant, however In my testing, there were no other messages present in the signal? Only MIDICLOCK was in use.

nickrose:

Mr Feral gets this problem with TF set to MIDI THRU and an external MIDICLOCK source would appear to back this up (please let me know if I misunderstood this last point).

Actually, to clarify, when I was using an external clock source, it was the other 'Factor pedal.

There doesn't seem to be anything wrong with the stability of the clock messages generated by the 'Factors. The problem seems to occur when the algorithm changes at the exact moment when a clock message is sent.

Basically, what I was saying was, if MIDICLOCK is being generated by OR passed through the 'Factor when ITS algorithm changes, the issue can occur. Or so it would seem, to me.

Hope this helps…

[nickrose]

Hi Josh

We'll keep on trying. Obviously, if we can't make it happen, we can't fix it. Let me know if you discover any other info. I still believe it's not us, but am prepared to be wrong (not for the first time).

[feralchild]

Thanks, I'll try to get more independent confirmation, and anything I learn will be posted here.

One more note, if you're testing with a TimeFactor, it seems to happen a lot more often when engaging the Looper algorithm as opposed to the others.

[Author]

Posts