Serious MIDI Timing/Overload Issues with a lot of MIDI data

[powerpulsarian]

I am having issues with the Sequencer Midi Dest and Sequencer Midi Source modules when using a lot of MIDI data.

I can play any of the Scope synths using my Nord Modular G2 without issue when playing from direct MIDI input, but when playing through the Sequencer Midi Dest and Sequencer Midi Source modules, issues start to come up.

The issues do not appear until I send a lot of MIDI data, such as when I hit the Nord's pitch stick and it waivers back in forth (sending a lot of note bend data). At this point, everything I play starts to get delayed because it appears the Scope MIDI modules can't keep up.

It continues to be a problem on playback of the recorded MIDI data. The MIDI data recorded in the sequencer is fine, but Scope synths can't keep up.

By the way I am using Live 6 - and have also reproduced this problem in Sonar 5. Also, no VSTi's loaded into these programs have this issue (they keep up with everything I play). So, that's how I determined that it was an issue with the Sequencer Midi Dest and Sequencer Midi Source modules. These modules seem to be the weak link.

With not being able to count on Scope keeping up with Midi data, this problem is making Scope unusable for me.

Any thoughts or ideas?

Thank you!

[irrelevance]

There was a utility reviewed in SOS recently www.earthvegaconnection.com
that measured midi port latency/jitter performance. I think it would be quite interesting to compare the performance of the physical port against that of the virtual.

I wonder, are you using the same midi channel in all instances to send continuous controller and midi note data? If so, try seperating this information onto different channels which is a recomended approach with any midi product/device. I believe channel 10 is given the highest priority. You could also try setting up more midi source/dest modules. I cant remember what windows defaults to but when you've reached or exceed the limit you will get a message prompt informing that the extra midi ports will be available after a restart.

[valis]

What is the cpu usage of the host system for your Scope cards when you experience this problem?

[spacef]

Valis' question is appropriate, because midi overflow in scope generally causes a noticeanble slow down of the graphics (like it takes ages to select something with the mouse), not immediately the sound flow (at least that's what i experienced - and by overflow i mean millions of midi data at the same time). A pitch bend is not a lot of information for scope in general, even if you do a lot of pitch bending like you described (unless the pitch bend you use sends different info than usual pitch bends, which is possible eventhough it would be very uncommon -- and i understand that it is annoying that it happens when you do that, but i m sure there is something else causing this problem).

[huffcw]

I have this issue in XTC mode. The CPU usage is not very high when it happens.

The strange thing is that it seems to be related the the Scope synth rather than the midi modules because it only appears when controlling a Scope synth, such as Minimax. I do not run into the issue when controlling software synths through the midi modules.

[huffcw]

Also, by the way, normal pitch bending is not an issue for me - but I have noticed it related to the G2 pitch stick. Since it is on a pivot that allows it to waiver back in forth very quickly if you grab it and let it spring, it is sending way more MIDI data than what would normally be associated with pitch bending. So maybe an overload is happening - but again it appears to be overloading the synth instead of the midi module (and only when the synth is in XTC mode).

[Nebukadneser]

Also make sure that the Midi connections are properly set up. The problems you have may be caused by a looped MIDI chain which results in the same data being sent again and again.

Just a thought ...

Neb