Snake Oil VEP Multiport Workaround - AVOID

[Macker]

While we're waiting for Apple to fix up AUv3 properly, some users might be tempted to revert to using VEPro AUv2 with a multiport workaround. But there's a serious risk lurking in this case. One particular 3rd party "workaround" for VEP (AUv2) multiport operation that's been noisily promoted turns out to be snake oil. In fact, tests show that its performance is substantially inferior to VSL's original workaround. I won't name this 3rd party here for obvious reasons. 

Hypothesis

MIDI 1 is essentially a so-called Character Count Protocol (CCP), in which the meaning of a serial stream of  MIDI data can be parsed only according to the relative position of MIDI bytes (or 'characters') in a sequence. By contrast, more modern serial data communications use so-called Bit-Oriented Protocols (BOP), in which information is organised within an 'unbreakable' data frame or "packet" usually much larger than a single MIDI event. In Logic's Environment, it appears that MIDI events are organised and administered only as individual events consisting of 2 or 3 MIDI bytes, with no way of keeping multiple events locked together when merging multiple streams.

VSL's original VEPro multiport workaround employs a dual MIDI event construct; the 1st event specifies the port number to which the 2nd event is to be routed. Alas, there is apparently no way in which Logic's Environment can guarantee to keep these two particular MIDI events together without the possibility of another MIDI event from a different source becoming inserted between them when streams are merged. If such an accidental insertion occurs, subsequent parsing will be thrown into error and the 2nd MIDI event will be routed wrongly.

Simply by virtue of the very high speed operation of the Environment's Transformer, the two MIDI events of the dual event construct are extremely close together in time; hence it's not very likely - though not impossible - that the two events will become separated in a merged stream of multiple MIDI events from many sources. VSL wisely recommend that their original workaround scheme is used for no more than 16 ports per VEP instance.

The 3rd party workaround is not superior to VSL's workaround; the former does nothing to address the vulnerabilty of the Environment's CCP to loss of the all-important dual-event sequence, caused by other events getting in between the two events. I cannot see any possibility of devising a functional equivalent of a BOP in the Environment. Waiting for Apple to fix AUv3 in Logic is the best bet.

But hard evidence is needed to show that the dual-event construct can be broken apart in a merged and busy MIDI stream. Hence I set up a stress test to try to break the dual event construct.

Stress-Test Setup (See 1st Attachment)

In Logic 10.4.8 in Big Sur, a single MIDI half note (created in the Region Editor) was copied to every instrument track in 31 ports. But instead of feeding these ports to VEPro, they're all fed to one Standard Instrument that transmits all channels on IAC Bus 1. The MIDI Note number of each note is set to the port number in which it plays back; thus MIDi Note No. 2 (C#-2) plays back on all channels of Port 2, MIDI Note No. 3 on all channels of Port 3, etc.. Port 1 was not used in the tests. All notes were originally placed at the same start position, then the start position of half of the notes were randomised within 6 ticks. Playback is looped, leaving half a bar between loop start and note start, also between note end and loop end. Tempo is 120 BPM.

Two sets of tests have been conducted: one using VSL's original workaround; the other using the 3rd party workaround (shown in 1st Attachment).

Error Detector (See 2nd Attachment)

IAC Bus 1 is received by an error detection setup in the Environment. This detector uses the CC99 value to route the next MIDI event to one of 32 'port' transformers, each of which filters out the MIDI Note number expected for that port only. Thus any data appearing on the output of these 'port' transformers will have been routed wrongly.

Results (See 3rd Attachment)

Using the VSL workaround, I've not yet encountered any wrong-routing during playback.

When using the snake oil workaround, in every test run so far there have been multiple instances of wrong-routing - thus far always for Note Off events. (2nd Attachment also shows an example of snake oil failure.) I recall the snake oil salesman, when introducing 'his' revision (the key idea came from someone else), saying that the VSL workaround doesn't handle Note Offs correctly. Back at ya bud.

Conclusion

The tests furnish good evidence in support of the hypothesis; it does appear possible to break apart the dual-event construct used in Logic's Environment as a workaround for VEP(AUv2) multiport operation. This particular 3rd Party workaround is substantially more error-prone than VSL's original, despite having been vaunted as superior to VSL's original. It's snake oil. Avoid.

[Dewdman42]

The thing you just explained is a potential issue but as you correctly surmised, probably very rare to happen; if at all.  And there is no possible way with the environment to work around that either since VePro plugin requires numerous cables to merge together to one instrument channel.  There is no good work around.  I even tried to do some Scripter solutions that would listen to the stream and when it detects two CC99's in a row, attempt to re-correlate to ensure that correct order is maintained.  That may or may not have been helpful its hard to say, but in my view there was no way to completely ensure that atomic ordering particularly with more than a couple of cables merging together.  However, I also found, like you, that I'm not sure if it was ever really happening; hard to say for sure.  If it did happen it would have been rarely and hard to detect other then experiencing rare occasional hung or missing notes.

However the above is not what was causing so many people to have hanging note problems with the old AU2 CC99 templates that were provided by VSL.  The problems with the original templates, which VSL did not ever address, are mainly a couple things:

1. When you hit STOP in logicPro, it is normal to send out an All Notes Off and/or various note Off messages to cover notes that are currently sustaining at the time you hit STOP.  Unfortunately, it does not know anything about multiple ports in this case so it does not send enough NoteOff events and/or the ALL NOTES OFF operation also does not properly get routed with CC99 to all the places where Vepro is playing notes...thus leaving some notes hanging when you hit STOP.
   
   
2. The second problem is related to a bug in the transformer which causes the CC99 transform to not always work correctly with NoteOff, particularly for notes stored in the region, in contrast to notes played live.  You can read more about this bug at the following link: https://www.logicprohelp.com/forum/viewtopic.php?f=9&t=137085&hilit=cc99, read down through the post until you see the section that explains the transformer bug.
   
   
3. I vaguely recall also that when articulation sets came out, they were not properly routing keyswitches from the articulation set through the environment in order to insert CC99 in front of those events also.  I never tried to fix that issue, by the time I found out about that I was already moving on to AU3, which in fact works much much better then the CC99 trick.  But most likely this problem is also not solvable.
   
   
4. The problem you mentioned in your post is also a potential issue, but in my view un-solvable and most likely pretty rare in any case.

The templates I provided as alternatives to VSL's; worked-around the first two issues.  The first is accomplished with a Scripter script to clean up Notes when you hit STOP, across all ports using CC99.  The second issue required some tricky environment programming to work around the transformer bug, which you can read about at the above link if you are interested.  As I said, I never bothered to fix the third problem, AU3 was already happening by then and much better.

All of this is really a moot point, I have recommended since a long time ago that that AU3 should be used instead, The AU2 CC99 trick was developed prior to VePro7.  AU3 is absolutely the way to go now for LogicPro-VePro multi port instances; since VePro7.

[Cyril Blanc]

Maker has time to speak rubbish ; the screen copy of the Screen Monitor that he post on another thread show a bug that is causing traffic overload.

I have proposed to look at his Environnement to correct it but apparently he prefer to post long mails that do not help

@Dewdman42 said:

The thing you just explained is a potential issue but as you correctly surmised, probably very rare to happen; if at all.  And there is no possible way with the environment to work around that either since VePro plugin requires numerous cables to merge together to one instrument channel.  There is no good work around.  I even tried to do some Scripter solutions that would listen to the stream and when it detects two CC99's in a row, attempt to re-correlate to ensure that correct order is maintained.  That may or may not have been helpful its hard to say, but in my view there was no way to completely ensure that atomic ordering particularly with more than a couple of cables merging together.  However, I also found, like you, that I'm not sure if it was ever really happening; hard to say for sure.  If it did happen it would have been rarely and hard to detect other then experiencing rare occasional hung or missing notes.

However the above is not what was causing so many people to have hanging note problems with the old AU2 CC99 templates that were provided by VSL.  The problems with the original templates, which VSL did not ever address, are mainly a couple things:

1. When you hit STOP in logicPro, it is normal to send out an All Notes Off and/or various note Off messages to cover notes that are currently sustaining at the time you hit STOP.  Unfortunately, it does not know anything about multiple ports in this case so it does not send enough NoteOff events and/or the ALL NOTES OFF operation also does not properly get routed with CC99 to all the places where Vepro is playing notes...thus leaving some notes hanging when you hit STOP.
   
   
2. The second problem is related to a bug in the transformer which causes the CC99 transform to not always work correctly with NoteOff, particularly for notes stored in the region, in contrast to notes played live.  You can read more about this bug at the following link: https://www.logicprohelp.com/forum/viewtopic.php?f=9&t=137085&hilit=cc99, read down through the post until you see the section that explains the transformer bug.
   
   
3. I vaguely recall also that when articulation sets came out, they were not properly routing keyswitches from the articulation set through the environment in order to insert CC99 in front of those events also.  I never tried to fix that issue, by the time I found out about that I was already moving on to AU3, which in fact works much much better then the CC99 trick.  But most likely this problem is also not solvable.
   
   
4. The problem you mentioned in your post is also a potential issue, but in my view un-solvable and most likely pretty rare in any case.

The templates I provided as alternatives to VSL's; worked-around the first two issues.  The first is accomplished with a Scripter script to clean up Notes when you hit STOP, across all ports using CC99.  The second issue required some tricky environment programming to work around the transformer bug, which you can read about at the above link if you are interested.  As I said, I never bothered to fix the third problem, AU3 was already happening by then and much better.

All of this is really a moot point, I have recommended since a long time ago that that AU3 should be used instead, The AU2 CC99 trick was developed prior to VePro7.  AU3 is absolutely the way to go now for LogicPro-VePro multi port instances; since VePro7.

[Macker]

Any experts on Logic's Environment care to comment on the actual evidence? If not I'll assume the case is over and done with - snake oil well and truly exposed, Q.E.D..

[Dewdman42]

I don't really understand why you're even bringing this up.  The old AU2 CC99 templates are truly deprecated at this point..and as I have laid out, have numerous problems..  The CC99 trick simply was not a very good idea to begin with.  

It seems Macker that you just want to use this forum to attack and bully me in some childish way, so I'll just leave it at that... Nobody cares about this now.  I have stated the facts in case it will help you or anyone else with their LogicPro environment problems in the transformer, and for anyone that might still be trying to use those old CC99 templates, despite the problems.

Furthermore, as I have said numerous times already, people should be using VePro7 with the Au3 approach at this point in time if they want multi port midi in LogicPro->VePro.

[Macker]

[Moved owing to trolling]

[Cyril Blanc]

You do not need to be an expert in Logic environnement to see that for one note and a CTRL this note is send many time creating traffic overhead

@Macker said:

Any experts on Logic's Environment care to comment on the actual evidence? If not I'll assume the case is over and done with - snake oil well and truly exposed, Q.E.D..

[Macker]

[Moved owing to trolling]

[Dewdman42]

no, the original CC99 templates from VSL are broken due to bugs I have mentioned above.  Sorry, but Macker in your quest to be argumentative and frankly an internet troll, you are now spreading mis information.  Doesn't matter though, people should not use any of those CC99 templates, not mine, nor VSL's....they should use Vepro7 and AU3.

regards

[Macker]

[Moved owing to  trolling]

[Cyril Blanc]

bla bla bla

Sorry for him he is getting old and does not have all his head

 

@Macker said:

[Addendum 2]

Up to a point, it's interesting and beneficial to examine how a situation like this comes about. How does an item of snake oil like this 3rd party workaround come into existence and get to be distributed and promoted, and yet take so long to be objectively recognised for what it actually is - an inferior piece of junk?

The well-being, productivity and development of any community who use and deal with technical products and technical matters in their everyday endeavours, depends very much on the qualities of truthfulness, objectivity and intellectual integrity in communications between and conduct of members of the community. Indeed modern science and engineering became what they are today by virtue of these qualities. 

Unfortunately, even today we still find a tiny minority who do not (typically because they cannot) adhere to these virtuous ways which are the hallmark of good technological development and usage. For example, these unwholesome few favour mendacious self-serving narrative above objectivity. When everything is going well they exhibit plenty of fake friendliness and civilised 'niceness'. But the worst and most destructive part of it is, they readily use lies, projection, gaslighting, smear tactics, trolling, pity-plays, etc, etc, in their efforts to protect, preserve, propagate and promote their narratives in the face of any and all criticism.

There is no remorse, humility or shame to be found in these toxic types. Unless it serves a cunning purpose, they never accept responsibility or accountability for any wrongdoing; they'll always try to blame others. In their mendacious narratives, so-called "optics" are the principal concern rather than substance, objectivity or crucial facts. This is nothing new, but in today's world it is astonishing to discover it in play in technical matters, where empiricism has ruled for centuries. (The convicted fraudster Elizabeth Holmes is a notorious recent example.)

For these toxic few, reality is indeed "an aggression", because it threatens to upset their dysfunctional optic narratives about themselves and their activities. And then they so readily play the victim, inviting pity while busily projecting their own vices onto the 'perpetrator' of such 'aggression'. Sadly but obviously, such individuals are not suited to any technological endeavour.

There's no need for me to analyse this particular case any further. Many of us here have already seen the incredible doubling down on obvious technical untruth in the face of hard objective evidence to the contrary (e.g. "the volume control is linear", lol), by the individual involved. And his trolling, smearing, deflection, projection, 'victimhood', etc, have been in play in several controversies here and elsewhere.

Meanwhile, yet more realities await us. The technical underpinnings of our musical endeavours will no doubt continue to distract us sometimes and perhaps become a thorn in our side. But we persevere. We know that "fake it 'til you make it" is not the way for us. And we know that science and engineering are far too strong to be even dented by a toxic few who desperately need their self-serving interests and narratives to prevail above all.

[Macker]

[Addendum 1]

I was curious to know just how bad this 3rd party workaround is, so I ran the stochastic tests again with progressively fewer ports switched on.

With 16 ports on, wrong-routing still occurs, though less frequently, as expected; it also occurs with 8 ports, 4 ports and, get this: 2 ports!

If this 3rd party workaround can't handle even 32 notes in unison without getting its knickers in a twist, it's an irresponsible piece of junk that wasn't tested properly before release. AVOID.

If you want to revert to VEPro AUv2 multiport operation (because AUv3 is now very buggy with the new and heavily revised "Logic Pro"), use VSL's original multiport workaround with LPX 10.4.8. This VSL scheme is not ideal; but then again, VSL have said so, and have called it a "workaround" rather than a production-standard solution. VSL recommend using their workaround with no more than 16 ports per VEP instance. I would also suggest that if you do ever encounter wrong routing occurrences in VSL's workaround, try not using Port No. 1 (just a hunch - no guarantees, sorry to say).

I'm willing to be wrong if there is hard evidence to the contrary, but I believe there's no way of modifying VSL's AUv2 multiport workaround in Logic's environment without increasing the probability of wrong-routing errors.

[Addendum 2]

Up to a point, it's interesting and beneficial to examine how a situation like this comes about. How does an item of snake oil like this 3rd party workaround come into existence and get to be distributed and promoted, and yet take so long to be objectively recognised for what it actually is - an inferior piece of junk?

The well-being, productivity and development of any community who use and deal with technical products and technical matters in their everyday endeavours, depends very much on the qualities of truthfulness, objectivity and intellectual integrity in communications between and conduct of members of the community. Indeed modern science and engineering became what they are today by virtue of these qualities. 

Unfortunately, even today we still find a tiny minority who do not (typically because they cannot) adhere to these virtuous qualities which are the hallmark of good technological development and usage. For example, these unwholesome few favour mendacious self-serving narrative above objectivity. When everything is going well they exhibit plenty of fake friendliness and civilised 'niceness'. But the worst and most destructive part of it is, they readily use lies, projection, gaslighting, smear tactics, trolling, pity-plays, etc, etc, in their efforts to protect, preserve, propagate and promote their narratives in the face of any and all criticism.

There is no remorse, humility or shame to be found in these toxic types. Unless it serves a cunning purpose, they never accept responsibility or accountability for any wrongdoing; they'll always try to blame others. In their mendacious narratives, so-called "optics" are the principal concern rather than substance, objectivity or crucial facts. This is nothing new, but in today's world it is astonishing to discover it in play in technical matters, where empiricism has ruled for centuries. (The convicted fraudster Elizabeth Holmes is a notorious recent example.)

For these toxic few, reality is indeed "an aggression", because it threatens to upset their dysfunctional 'optic' narratives about themselves and their activities. And then they so readily play the victim, inviting pity while busily projecting their own vices onto the 'perpetrator' of such 'aggression'. Sadly but obviously, such individuals are not suited to any technological endeavour.

There's no need for me to analyse this particular case any further. Many of us here have already seen the incredible doubling down on obvious technical untruth in the face of hard objective evidence to the contrary (e.g. "the volume control is linear", lol), by the individual involved. And his trolling, smearing, deflection, projection, 'victimhood', etc, have been evident in several controversies here and elsewhere.

Meanwhile, other more pressing realities await us. The technical underpinnings of our musical endeavours will no doubt continue to distract us sometimes and perhaps become a thorn in our side. But we persevere. We know that "fake it 'til you make it" is not the way for us. And we know that science and engineering are far too strong to be even dented by a toxic few who desperately need their self-serving interests and narratives to prevail above all.