It's all about "order of operations". 

The first transformer creates a CC99 event, the value of which is set to the port to which the original event (A) is to be directed. At this point you have the original MIDI message (A) and the new CC99 event (B).

Apparently, and this is only borne out by actual results as opposed to documentation, when an event (A) is transformed, the newly generated message (B) gets priority when the two are summed. This results in the CC99 message "leading the way" into VEPro, followed immediately by the original message (A). And of course, this is the way it has to be. 

The whole transform-and-then-sum thing is really unnecessary, however, because a single transformer working in Copy Matching Events and Apply Operation (Reverse Order) performs exactly this function with a single environment object.

Peter, thank you very much for your reply (and for your many other informative posts).  I believe I understand what you're saying, but I still don't understand WHY we need the CC 99 message at all.

You're very welcome!

The CC99 event tells the VEPro Instance which port a MIDI event is destined for. When this message "leads the way", the Instance is made at-the-ready to direct the next event it sees to the plugin assigned to that port.

Example: You've got an Instance loaded with two plugins: VSL (assigned to receive MIDI from port 1) and Kontakt (assigned to receive MIDI from port 2).

Let's say you have a Note On Event that you want to trigger a sound in the Kontakt plugin. If there wasn't a CC99 event preceding this message to direct it there, it would be directed to the VSL plugin instead (port 1). This is apparently the default behavior. However, when it's preceded by the CC99 event (with a 2nd data byte value of "1"), the Instance knows to send the very next message it sees -- in this case our Note On Event -- to the Kontakt plugin.

So break this down even further...

Just a Note On Message (not preceded by the CC99 message) going to ---> VEP Instance. Result: sound is heard from the Vienna Instrument (port 1). 

Compare to this scenario:

CC99 message (value 1) ---> VEP Instance. Result: The Instance is now "at the ready" to direct the very next MIDI byte it sees to the plugin assigned to get MIDI from port 2 (Kontakt). So then...

Note On Message ---> VEP Instance. Result: it's sent to Kontakt.

Ah!  I see!  So, am I to understand that MIDI CC 99 (which is listed in the MIDI spec as "Non-registered Parameter (MSB)") is used by VEPro as "Send to MIDI Port XX"?  Is this documented anywhere in the VEPro manual?  And thanks again for your help!

Exactly! 😎

Yes, this is one of the NRPN messages, which can be used for any purpose a developer sees fit. As it's implemented in VEPro, it apparently performs "direct the next message to port X". I don't know if this is documented in the manual.

I would like to impose on the forum community for a bit more help...

What I'm trying to do is a bit unusual, I think, and I'm having some trouble sorting it out.

In the reductive case, I have an external MIDI SEQUENCER which sends notes on MIDI Port 01, Channel 01.

This sequencer is connected to a laptop running Logic Pro X.

A second laptop is running VEP Server.

What I need to do is be able to have the sequencer send MIDI into Logic, then through a VEP instance, triggering a plugin on the second laptop, hearing that audio in Logic on the first laptop, but be able to record both the MIDI from the sequencer and the audio from VEP.

I have set up the following tracks:

TRACK 1 [MIDI]:  Software Instrument track with no plugin and no output.

TRACK 2 [OUTPUT]:  Software Instrument track with VEP plugin.  The output of this track goes to Bus 01.

TRACK 3 [AUDIO]:  Audio track.  The input of this track is Bus 01, and the output is the Stereo Out.

In the Environment, I have patched MIDI Port 01 to a Monitor object.  The Monitor object is patched to a Channel Splitter object.  The Channel Splitter object output 01 is patched to the input of Track 1.  The output of Track 1 is patched to the input of Track 2.  I can now hear the VEP plugin play throughTrack 3 when I run the sequencer, and I can record the audio on Track 3.

The problem comes when I try to record MIDI onto Track 1.  As I understand it, unless I patch (in the Environment) a second ouput from the Monitor object to the Sequencer Input, nothing will be "seen" by Logic.

Fine.  So I patch the Monitor object second output to the Sequencer Input.  Now I can record the MIDI being output by my external sequencer onto Track 1.

The problem is that I'm now getting TWO identical MIDI notes playing - only one gets recorded, but two play.  Not a deal-breaker, but disconcerting, and potentially an issue with heavy MIDI and audio bandwidth over VEP.

I'm stumped.  I know that my relative inexperience is preventing me from seeing some elegant and simple way of solving this problem, and I would very much appreciate any advice.  Thanks.

@HFTobeason said:

The problem is that I'm now getting TWO identical MIDI notes playing - only one gets recorded, but two play.  Not a deal-breaker, but disconcerting, and potentially an issue with heavy MIDI and audio bandwidth over VEP.

I'm stumped.  I know that my relative inexperience is preventing me from seeing some elegant and simple way of solving this problem, and I would very much appreciate any advice.  Thanks.

Send me the song and I will look at it at cb dot pub at numericable dot com

Cyril

Now I have the 2x48 port setup running otherwise smoothly, but the undo/redo times are ridiculously long. That's a big problem for workflow. This is not happening in my older projects, which are not using the 2x48 port template. I checked that I have the exactly same undo setup in Logics general preferences in the new template that I have in the old ones and I even imported all the project settings from a recent project in which undo/redo is working flawlessly in an instant. Anyone else having this problem or does someone who knows their way around Logic X have any idea why this might be so?

@Sami Boman said:

Now I have the 2x48 port setup running otherwise smoothly, but the undo/redo times are ridiculously long. That's a big problem for workflow. This is not happening in my older projects, which are not using the 2x48 port template. I checked that I have the exactly same undo setup in Logics general preferences in the new template that I have in the old ones and I even imported all the project settings from a recent project in which undo/redo is working flawlessly in an instant. Anyone else having this problem or does someone who knows their way around Logic X have any idea why this might be so?

Sami, I have a rather large template, not using the multiport method, and have come across the really long undo issue too - very bothersome and possibly just a Logic bug with larger templates?

@Sami Boman said:

Now I have the 2x48 port setup running otherwise smoothly, but the undo/redo times are ridiculously long. That's a big problem for workflow. This is not happening in my older projects, which are not using the 2x48 port template. I checked that I have the exactly same undo setup in Logics general preferences in the new template that I have in the old ones and I even imported all the project settings from a recent project in which undo/redo is working flawlessly in an instant. Anyone else having this problem or does someone who knows their way around Logic X have any idea why this might be so?

Hello

The VSL template should not effect the undo/redo time as it is only adding a "port  number" for each midi message, you can send me your template, I will have a look at it

The other solution is to use IAC

Best

Cyril

Thank you so much Cyril for your offer to help. To where can I send my Template?

@Sami Boman said:

Thank you so much Cyril for your offer to help. To where can I send my Template?

you can send at :

cb dot pub at numericable dot com

Cyril, I just sent you an email. Hope you get it.

Yes I did

I have send you my comments 

@Sami Boman said:

Cyril, I just sent you an email. Hope you get it.

Hello Paul,

Would a new Muliport Templates be useful for my setup? I mean it is not so powerful.

Master -Mac Mini 2.3 Ghz Intel Core i5, Mac OS X 10.9.5. Logic PRO X,  RME FIREFACE UFX,

———

Slave -MacBook Pro 2.2 GHz Intel Core i7, 16 GB, Mac OS X 10.9.5. VI Pro 2, VE Pro 5,  VSL Sounds, VS, MIR PRO,

If you can wait 10.11 until AU3 is availlable, it will natively support Multi-port

@Gukas Pogosyan said:

Hello Paul,

Would a new Muliport Templates be useful for my setup? I mean it is not so powerful.

Master -Mac Mini 2.3 Ghz Intel Core i5, Mac OS X 10.9.5. Logic PRO X,  RME FIREFACE UFX,

———

Slave -MacBook Pro 2.2 GHz Intel Core i7, 16 GB, Mac OS X 10.9.5. VI Pro 2, VE Pro 5,  VSL Sounds, VS, MIR PRO,

Many thanks for your support!

VE Pro Main 1 works. But from VE Pro Main 2, multiple ports doesn't work. 

I''d like to route VE Pro Main 2 to the slave PC. Midi signal comes in but doesn't sound anything.

When I set MIDI IN: OMNI in slave, it works. But it's not what I want.

Can you help me?

---

I'm not sure but I think there's some problem in the Multiport 6x16 Ports template. 

VE Pro Main 2 works in the 2x48 Ports template. Can you check if I'm wrong?

I need 3x16 Ports.

Hello Sunny,

Can you please send me screenshots of your Logic MIDI Environment, so I can see how things are set up on your system?

And perhaps it would also be helpful if you could re-save the project on your computer and send me a zipped copy of this, so I can try and reproduce the problem you are experiencing.

Best, Marnix

@sunnykim said:

Many thanks for your supports!

VE Pro Main 1 works. But from VE Pro Main 2, multiple ports doesn't work. 

I''d like to route VE Pro Main 2 to the slave PC. Midi signal comes in but doesn't sound anything.

When I set MIDI IN: OMNI in slave, it works. But it's not what I want.

Can you help me?

---

I'm not sure but I think there's some problem in the Multiport 6x16 Ports template. 

VE Pro Main 2 works in the 2x48 Ports template. Can you check if I'm woring?

I need 3x16 Ports.

I think I'm having a similar issue. It works if I set the midi port to 17, rather than back to 1 for VEPro Main 2. It's like it carries on straight from the VEPro Main 1 V-frame, rather than a new v-frame for VEPro Main 2. VEPro Main 3 midi port has to start at 33 rather than 1 as well. I haven't had a chance to try it with the others.

I can confirm that the 2x48 template works fine with the second V-frame midi channel set to 1 rather than 49.