Solved! Sort of. It was NOT a VI problem, it was a problem with MIDIOverLan. My workaround is kind of convoluted - if anyone wants me to lay it out, let me know.

PL

I'd be interested to hear how you fixed the problem and what was causing it in the first place.

It will only make sense if you're pretty familiar with MIDIOverLAN, so... are you familiar with MOL?

No I'm afraid not, but I'm willing to learn! I am pretty au fait with MIDI in general and remain intrigued to know how you can run multiple standalone VI's on one computer without them all playing on all MIDI channels.

MIDIOverLAN is a program that allows computers to send MIDI signals to each other over Ethernet (LAN = "Local Area Network"). You install it on each participating computer, then configure virtual MIDI ports on each computer in a control panel to receive and/or send. The ports show up in your sequencer as 16-channel MIDI devices like any other. (Many people on this forum use it - that's how I heard of it.) The version I have gives you 16 virtual ports with 16 channels each. I have four of the ports dedicated to sending info to my Giga PC, and the other eight ports go to my VI-dedicated Mac Pro.

As you know, you can only set the standalone to receive MIDI from driver-created MIDI devices. Each of the MOL ports shows up as a separate device, so what I HAD been doing was setting each standalone to receive from a different MIDIOverLAN port (to get around the problem of not being able to narrow it down to a specific channel). It was in this configuration that I was having the problem I described.

Here's the convoluted part. I use DP as a host for my plug-ins on the slave Mac Pro. DP can also generate Interapplication MIDI devices. Since I was not having the problem with plugins in DP, I decided to create 16 interapp MIDI devices in DP (calling them DP Output 1, DP Output 2, et.). Any of these can be assigned to a VI standalone. I then created 16 sequencer tracks in DP, and assigned them to the 16 newly created outputs. As inputs, I assigned individual CHANNELS from one of my MOL ports. (I.e., the 16 tracks had as inputs "Port 1-1, Port 1-2, etc."). This way I was able to split the MIDI signals from one port into that port's individual channels so that the standalones could receive them separately. For whatever reason, it also fixed my problem.

I realize it's pretty confusing - hope that sort of gave you the idea!

PL

Thanks Peter, I understand. As the standalone VI's behave fine when played as DP interapp devices, that rules out any disfunctionality in the standalone player. It therefore appears that your problem was caused by MOL, the implication being that MOL affects the MIDI data stream in some mysterious way!? [*-)]

Not at all times. After all, in my workaround, MOL is feeding DP, which feeds the DP interapp devices - then everything works fine. But DP is able to assign track inputs to individual CHANNELS of MOL data, not just whole ports. So the issue seems to come up only when the standalone (which can't split out a single channel of MIDI data on its own) is assigned to an MOL port directly.

@Conquer said:

I don't use DP, but just a thought: you say you're running a bunch of standalones on your Mac Pro. A standalone Vienna Instrument responds to data on all MIDI channels simultaneously, so is it possible that the standalone VI's are responding to ALL the MIDI data coming from your sequencer (not just one track) and becoming confused as a result?

Apologies if this is barking up the wrong tree. Obviously you could avoid the problem by running all your VI's inside DP, but I assume you have a reason for not wanting to do that.

I friend of mine used DP as I do, and has the full SE library.. The trick I think he uses, with his PPC G5 is that he has to print files as he goes, otherwise the memory usage becomes and issue.. Is this what you are talking about?

Cheers!

G

Thanks for the thought G - RAM consumption is a big issue for us all and as Peter explained, he runs standalone VI's in addition to hosting plugins in DP to get past his computer's 3GB RAM limit. Printing as you go is the ultimate resort, but prior to that you can always use the VI's 'learn' and 'optimise' functions to discard unused samples. That can reduce RAM consumption drastically.

Peter, getting back to the particular problem of the VI not responding to CC and program changes: when the problem occurs, are you absolutely sure there's no multi-channel CC data accidentally getting to the standalone player? I ask this because you say filtering the MIDI data down to one channel fixed the problem. (I don't know how DP displays CC data and the like, but as you may know Logic has an an event list which shows clearly what channel every piece of MIDI data was originated on.)

@Conquer said:

when the problem occurs, are you absolutely sure there's no multi-channel CC data accidentally getting to the standalone player? I ask this because you say filtering the MIDI data down to one channel fixed the problem. (I don't know how DP displays CC data and the like, but as you may know Logic has an an event list which shows clearly what channel every piece of MIDI data was originated on.)

I'm absolutely sure. I tested this using a sequence with only one track, which had only two pieces of data on it (a cc1 and a cc7), feeding into my slave Mac Pro, where the only MIDI module open was one VI Standalone. I was able to reliably reproduce the problem.

Actually, the next thing for me to test (which I will) is whether a non-VI standalone responds in the same way. Even though my workaround completely takes care of the problem, I'd like to be able to say definitively that's it's MOL. I'll report back. (I think it is, because when I tried controlling a VI standalone using a hardward MIDI connection, where I also couldn't specify a channel, I didn't have the problem.)

PL

OK, just tested this with MusicLab's RealGuitar 2.1.4L - did NOT have the problem. Chased multiple CCs fine. (BTW RealGuitar is made by the same folks who make MOL, so it's not surprising.) I used the identical sequence I had used to test the VI Standalone.

So it's something about the interaction between MOL and VI.

PL

Quite an arcane problem! Good that you've narrowed it down. If you put a CC1 and CC7 command in an identical place in the sequence and play it to the VI in real time, does it respond OK?

Yes, it responds fine to CCs it encounters in real time. It's just the chasing that's affected. And I fear I specialize in arcane problems...

PL

Well someone's got to do it! When chasing events, the sequencer has to spit out a bunch of commands at the same time, I wondered whether that might cause a MIDI timing issue?