Virus TI and unstable MiDi handling - A serious matter

[TRN]

Yes of couse you can return it... These are issues that are promised to work(advertised), that doesent. The rules, atleast here in Norway is atleast 1 year warrenty for fabric-failure after sale.
Are you saying that if you buy a car that have serius issues that are discoverd after a while, isnt either fix/replaced or you'll have your money back? Access can say whatever they want, I didnt buy it from Access, I bought it from a music-store and the music-store is responsible for they'r products and they will have to deal with Access, not me.


...But like I've said, I wanne wait and see what Access will do (updates).
I wanne keep my TI, in a working order.


- TRN

[Mister Orange]

Originally Posted by index

Did you use the midi ports or midi via USB?

I used the midi ports, connected up to an Emagic MT4 midi interface on an old 500MHz PC, running WinXP and Logic 5.5.1.

Originally Posted by index

The reason i arranged the parts as i did was simply as a test, that is not how i normally work...

Phew, glad to hear it, although it was quite good actually. It just needed a 909 kick and it would have sounded loads better than some of the rubbish they play at some nights I can think of.

Originally Posted by index

And Mister Orange, wich project did you test? The third version? Please try the first one also - because if you get that project (with more automation going on) to sound rock solid also, then it would be very interesting to find out why at least Ben had the same troubles with it as i did.

The third one. As I said in my earlier reply, I would have no faith in midi carrying sysex along with a running sequence. IMO, midi was simply never designed for sysex to be used in this way. That's what control messages are for.

By the way, don't read this as though I don't have other issues with the TI's stability. I just don't think it's the TI that's at fault in this case.

I will try your 1st sequence, maybe filtering out the sysex, or thinning out the cc data if it jams up. I'll let you know how I get on. But first, a little sleep.

Mr O

[grs]

Originally Posted by ben crosland

How is the Virus supposed to decide to start ingnoring some midi data, just in case there's a note coming sometime in the future?

I think that's why the Virus Control vsti exists, with buffering it should be possible via USB midi to get 16 notes on 16 channels to hit all on the same beat and hopefully Access will come good on their 'sample accurate' promise.

With my experiments so far I have only experienced sample accurate timing when using Virus Control (open VST, load VC, save fxp, unload VC, power off TI, power on TI, load VC, load fxp) This was also slaving to the TI s/pdif output and recording the s/pdif output.

When you think about it, unless the TI sound engine is word clock accurate to your Asio card how can it deliver sample accurate precision? That last question is just an open question for people to ponder.

As a side question: Does anyone remember Steinbergs LTB technology for accepting midi data out of time (edit: ahead of time) and having the receiving midi device play the notes when they are actually scheduled to play?

[index]

Originally Posted by Mister Orange

By the way, don't read this as though I don't have other issues with the TI's stability. I just don't think it's the TI that's at fault in this case.

I will try your 1st sequence, maybe filtering out the sysex, or thinning out the cc data if it jams up. I'll let you know how I get on. But first, a little sleep.

Mr O

Thanks for testing.

If you have the USB cable connected also, try switching from the midiports to USB midi and see if its the same there.

[Zephod]

if you are using the regular midi ports, please be aware that a full event takes about a millisec to send.. a 9-note chord on 9 channels will therefore take at least 9 millisec to be transmitted.. human threshold for "instant" is about 6msec... human threshold for audible phasing is much lower than that.. combine this with sending CC's on those same channels, and the notes get spaced even further apart...

please note as well: 1msec per event implies maximum 1000 events per second per midicable... sending more than that will go out of sync by default

[index]

I dont even want to try to understand the mumbojumbo man. Any other synthesizer can easily have a melody running on many parts to fatten it up.
Its just that it does not work with my TI...

Today i started another project, and while it does not sound as bad as the example i have showed you it still does not feel tight compared to my other midi hardware.

No sysex involved, 5 parts, 2 tracks off cc automation.

The TI just is a wierd synthesizer overall. When i recorded Panorama into cubase, after have stopped the sequenser i see the Panorama -+ number in the display continue to switch back and forth as i was still moving it!!
The sequenser was stopped and did not send any midi... very very wierd.

[ben crosland]

Originally Posted by index

I dont even want to try to understand the mumbojumbo man. Any other synthesizer can easily have a melody running on many parts to fatten it up.
Its just that it does not work with my TI...

Midi will always sound smudgy as you add more and more tracks. That's why certain artists refuse to use it at all.

Actually I tried file number 3 again today, and found the following:

1) Once I'd enabled midi clock to be sent to the Virus in SX3, it tightened up those messy delays. Note timing sounded OK.

2) Even so, there was occasional bad Dopplering - indicative of a sloppy midi clock signal.

3) Tried it in Logic - no Doppler effect at all..

I also tried my own simple midi stack test in both hosts, with a phase initialled single oscillator patch on 8 simultaneous tracks:

With no CC at all, the effect was a messy, phasey smudge. Zephod's explanation covers this - i.e. midi cannot play two notes at exactly the same time.

Adding CC to each track made little difference, if any in either host. I would not expect any hardware synth to behave differently in this test.

[Mister Orange]

Originally Posted by index

Thanks for testing.

If you have the USB cable connected also, try switching from the midiports to USB midi and see if its the same there.

I tried your first sequence last night, again using only midi cables and the same PC running Logic 5.5.1 and the MT4 midi interface. As I expected, all that sysex embedded in a running sequence really jammed the pipes up, but amazingly, Logic kept right on playing - some dopplering (as Ben calls it), but note timing was astonishingly tight. The TI behaved itself (yeah!!!), and even politely informed me at one point that the midi buffer was full.

Interestingly, the TI was still receiving sysex data 5 - 10 seconds after I stopped the sequencer, which goes to show how much backlog of midi data there was. Logic (and Notator in its previous incarnation on the Atari) always has been good as prioritising midi data, and was presumably giving priority to note data rather than the sysex. Perhaps Logic is better than Cubase in this respect, but that is a debate best left to a different thread.

I then stripped out the sysex, but left in the control data. It ran fine. No timing problems at all. Again, I changed some of the sounds to ensure they all had good, strong attacks and could detect no timing issues, phasing or Doppler effect.

Sorry, I haven't tested this with USB midi, and no, I don't have Cubase SX, but thanks for the opportunity to experiment thus far. My conclusion remains the same; i.e. that the issues here are to do with the limits of midi rather than the TI.

Mr O