Since I always play my parts in rather than step enter, I would not want that.

@Ashermusic said:

Since I always play my parts in rather than step enter, I would not want that.

Up to you 😉

If you need to provide the  score to a real orchestra you have to do the work twice

That is a fair point.

FWIW, after many attempts over many years to get Logic to either automatically enter score symbols "on input" in response to live-played articulation switching events, or, to transform manually entered score symbols into those same events (or MIDI channel selection), it's just not possible. There are limitations and bugs all over the place.

I don't want to take advantage of the forum to hawk my wares, but at least with my SkiSwitcher2 system you can apply articulation selection directly to notes in the score or any other editor, and then use your sense of musicianship to place score symbols as appropriate. 

Reading earlier in the thread, I've been wondering for a while now why the multi-port layer transformers used such a complicated process. The Transformer's Copy/Reverse Order process has always been quite reliable.

Regards,

Peter Schwartz

@ski said:

Reading earlier in the thread, I've been wondering for a while now why the multi-port layer transformers used such a complicated process. The Transformer's Copy/Reverse Order process has always been quite reliable.

Peter Schwartz

As I send them this fix, apparently the VSL man that wrote the Multi port did not know the function ;)))))))))

:))  Congratulations on supplying the fix!  💡

@ski said:

 

I don't want to take advantage of the forum to hawk my wares, but at least with my SkiSwitcher2 system you can apply articulation selection directly to notes in the score or any other editor, and then use your sense of musicianship to place score symbols as appropriate. 

I had a look to your site, I did not see the articulation change printed in the score window

@ski said:

 

I don't want to take advantage of the forum to hawk my wares, but at least with my SkiSwitcher2 system you can apply articulation selection directly to notes in the score or any other editor, and then use your sense of musicianship to place score symbols as appropriate. 

I had a look to your site, I did not see the articulation change printed in the score window

It isn't,  you have to add them with "your sense of musicianship."

@Cyril said:

I had a look to your site, I did not see the articulation change printed in the score window

Thanks for having a look! But as I said above, adding score symbols in conjunction with selection articulations is not possible. So... getting notes to each select their own articulations is one thing. Score markup is another. 

@ski said:

 

I don't want to take advantage of the forum to hawk my wares, but at least with my SkiSwitcher2 system you can apply articulation selection directly to notes in the score or any other editor, and then use your sense of musicianship to place score symbols as appropriate. 

I had a look to your site, I did not see the articulation change printed in the score window

It isn't,  you have to add them with "your sense of musicianship."

When you give a score to an Orchestra, articulation should be printed

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

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.