PlanetZ forums - scopeusers.com

When powering up XITE, but not the attached PC, I get a Midi-storm on my MIDI-hub. XITE seems to send permanent messages.
After half an hour, the Midi-hub seems to stop distributing this Xite's input to the outputs, but all other inputs are not routed, too.
So i typically have to powercycle my Midi-hub after the XITE-before-PC-powerup sequence, which is not nice.

Why does XITE send messages in this situation `?

This probably does not help you, but here we go anyway:

My Xite Midi Out seems to behave like a Midi Through when the Xite is on but the PC is not on [correction: PC on, but Scope not yet loaded]. So if that’s also how your Xite behaves, you’re not alone.

Causing a midi loop perhaps?

Use a MIDI Filter on the XITE-1 Hardware output.

I have Maus excellent MIDI Filter/Router on all inputs and outputs.
You can actually use the PRJ Preset List/SR-Pro and each preset will change the routings as well as Filter settings using a simple PrgmChng message.

dawman wrote: ↑Mon Mar 08, 2021 7:42 pm Use a MIDI Filter on the XITE-1 Hardware output.

I have Maus excellent MIDI Filter/Router on all inputs and outputs.
You can actually use the PRJ Preset List/SR-Pro and each preset will change the routings as well as Filter settings using a simple PrgmChng message.

He has the issue w/ just only XITE powered up and before his computer is powered up (computer OFF),- so any software MIDI filter solution won´t help much.
Seems XITE MIDI-Out is connected to something already powered up before powering up XITE, then followed by powering up the computer.

And yes, I´d also wonder why XITE transmitts whatever MIDI data from MIDI-Out WHEN computer is still powered off and SCOPE environment isn´t loaded.
I never recognized because my XITE MIDI I/Os were connected to a Sycologic M16 MIDI patchbay/router always where I selected a desired preset AFTER everything was running.
But, the Sycologic M16 itself NEVER responded to such a "MIDI storm" described in original post above.
It never crashed !
So,- I guess, not every XITE might introduce this issue and maybe his XITE is faulty (?) ...



Bud

I see, said the blind man.
Unplug the MIDI then.

it could also be quite normal, to protect the outside world "Reset Mode"
e.g. quite a few keyboards send constantly
it's just a little scary when a lot of leds keep flickering ... like modular corner

System Real-Time Messages

11111000 Timing Clock. Sent 24 times per quarter note when synchronization is required (see text).
11111001 Undefined. (Reserved)
11111010 Start. Start the current sequence playing. (This message will be followed with Timing Clocks).
11111011 Continue. Continue at the point the sequence was Stopped.
11111100 Stop. Stop the current sequence.
11111101 Undefined. (Reserved)
11111110 Active Sensing. This message is intended to be sent repeatedly to tell the receiver that a connection is alive. Use of this message is optional. When initially received, the receiver will expect to receive another Active Sensing message each 300ms (max), and if it does not then it will assume that the connection has been terminated. At termination, the receiver will turn off all voices and return to normal (non- active sensing) operation.
11111111 Reset. Reset all receivers in the system to power-up status. This should be used sparingly, preferably under manual control. In particular, it should not be sent on power-up.

Good point. Active Sensing will do this, and Active sensing used to actually crash Scope on me in the 3.x era oddly enough. Filtering software side didn't help that, which is why I originally got my MOTU units.

Also, on the Xite acting as a thru, that would just mean the default state it loads in passes inputs to outputs, no? I still don't own one so can't comment further on that.

I did some futher tests.
The XITE was powered up with the hdmi-link unplugged and the Midi-out unplugged.
It seems that the Midi.out is flooding with some rubbish, which is not always understood by my timepiece getting the Midi.out.
Sometimes the data runs through the timepiece and I got this at maximum rate:
0xC0 0x00 .. which is a program change.

To me this looks like an uninitialised DSP-machine or some sort of testpattern. For that later I wonder why it's not always understood by timepiece.
This is no major problem, but my timepiece seems to block such a port after some unknown time/event, so I have to powercycle it sometimes after booting.

Yes that's program change to 0, and Active Sensing is FE (no second byte).