Methinks something's getting lost in translation. I don't think anyone disagrees that scores have to marked up. And no, score markings can't be entered into the score automatically as a result of selecting articulations.

And to combine the two subjects, there's really only a limited degree to which automatic markup entry -- if it were possible -- would be accurate anyway, so to a large degree I'm not sure how it could ever be a substitute for applying musicianship to score prep. For example...

Let's say I'm writing a staccato passage for strings at a slow tempo. And in my instrument I have the choice of staccato and staccatissimo. At the slow tempo, the duration of the staccato samples are too long, but the staccatissimo's are just right so that's what I use. At this point, the names of the samples don't matter. But if automatic symbol entry were possible, I'd end up with a whole bunch of staccatissimo markings which I'd then have to erase and replace with dots.

Sure, it would be nice to have text indications such as "pizz" or "arco" automatically entered in the score when those articulations are selected. Stopped horn symbols, harmonics, and others for which there's no ambiguity or room for interpretation would be great to have auto-entered in the score. But even a simple staccato, per my previous example, is open to interpretation, and in particular, dynamic markings would face the same fate because their meanings are relative.

Anyway, weren't we talking about the multi-port layer? 😃

@Ashermusic said:

Well, of course, but you have to enter them as text, which I have been doing since 1990.

If Apple develop Logic Expression Maps you won't need to enter them as text (as does Cubase)

Apologies for being an idiot, but would someone be kind enough to explain the neccessity for the CC 99 transformer, and then the summing transformer before the instrument channel?  Thank you.

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,