@flying-poo said:
Re: VEP 7 with different Midi Ports on Logic does not work here
Hi Everyone. Apologies for any redundancy. As I'm bopping around from forum to forum I'm getting mixed information. Hopefully some can chime in and help clarify.
Tiny bit of background. I was happily running Logic on a 2013 Mac trashcan, with a PC slave running VEPro and hosting the majority of my libraries. If my memory serves me, I was using a hacked multiport created by a fellow named Dewdman42 (thank you!). It worked well (after I painfully discovered the multiport template offered by the fine people at Vienna did not actually work) and allowed me to get a lot of work done. Flash forward...finally upgrading. Any day an M1 Ultra Mac Studio, 128gb arrives. Expecting a lot of the usual migration headaches, and planning to start rebuilding templates. I've already seen many complaining about stuck midi notes when using VEPro alongside Logic (sounds like a Logic issue), but before I contend with that potential hurdle, my main question is...is anyone successfully using a multiport with the latest versions of Logic and VEPro on an Apple Silicon machine at this stage?
I saw a composer named Jeff Beal (jeff_5479) posting about a similar setup, and I believe he stated he did get multiport to work in a current Logic/VEPro/Silicon combination, but then I also saw that he was rebuilding a template entirely within Logic due to the hanging notes issue. So I'm not entirely sure where he's at with things at this point, and if he has abandoned the usage of VEPro in order to get his workflow stable again. I did send him a message to inquire, but also wanted to put this all out here.
I am aware the significant increase in save times as well as the bloated project storage sizes when NOT using VEPro and operating entirely within Logic. So in my ideal world I'd still be using VEPro to take advantage of those benefits. Not to mention I'd still like to take advantage of my additional PC as a slave given it is a solid machine. But without stable multiport functionality I'm not certain if this would still be the way to go.
Any thoughts or insights greatly appreciated!
'FP', you've made some statements here that don't stand up to fact-checking and need to be sorted out to avert yet more misinformation, gaslighting and misleading of users on the topic of VEP-Logic multiport functionality and performance.
The VEP-multiport workaround provided by VSL for use in Logic's Environment, though not perfect, is nevertheless effective and still by far the best workaround available. There is currently no known way of providing flawless multiport operation for VEP by means of user-constructs in Logic's Environment; this is due to Logic's inherent design being unable to make 2 or more Environment messages 'stick together' under all circumstances.
Having seen and studied the stress-test results and technical explanation provided by @Macker in this forum, I'm in no doubt that the VSL workaround is head and shoulders above the 3rd party "hack" from @dewdman42 you mentioned, in terms of freedom from hanging notes under realistically stressful operational conditions. @dewdman42's "hack" was based on the unsupported assertion that VSL's workaround was not handling note-offs correctly, and was configured using a technically irrelevant (and as it turns out, substantially more fault-prone) trick suggested by a member of the Logic Pro Help forum. (BTW, this particular 3rd party seems to have a habit of crying "wolf!" - e.g. yelling that X Daw by AudioGrocery was now fatally flawed by Apple's removal of certain - actually arcane and irrelevant - javascript constructs from Logic's MIDI Scripter, but which 'dramatic news' turned out to be wholly untrue.)
But in fact the actual issue, as revealed by @Macker's tests, can be understood as an old-fashioned asynchronous realtime event queueing problem; it's not simply a 'missing' MIDI Note-Off problem. Specifically, a port address tag message can become separated from its accompanying MIDI data message intended for that port address, by another message intended for a different port, unfortunately occurring asynchronously at precisely that moment of vulnerability in between the two messages of the intended pair. Hence, for example, a MIDI Note Off can be sent to the wrong port and thereby leave the originally addressed MIDI note to hang forever. This 'queue-jumping' problem can occur only within one cluster of port address-tagging objects in Logic's Environment that are all connected to one VEP client plugin.
What are the chances of this accidental separation of - by unfortunate asynchronous insertion between - the port address tag message and its accompanying MIDI data message, in the Logic Environment workaround? It appears to be dependant on (1) how much time elapses between the port address tag message being asserted and the accompanying MIDI message being asserted, and (2) how busy the other ports and MIDI channels are within any one particular cluster of ports connected to any one particular VEP Client plugin.
@Macker's tests ran the VSL Environment workaround (16 ports in all tests) side by side with @dewdman42's hack (using port counts between 2 and 16 in various separate test runs), using a common input stream of MIDI note messages for both. The tests showed no separation of port message-pairs in the VSL case during test runs of up to half an hour. But the @dewdman42 case - in a matter of minutes - suffered separation of message-pairs even in the least stressful scenario of only 2 different ports in the port-cluster! Why should this be? It appears the VSL workaround is the best possible way to minimise the vulnerable time gap between the port address tag and the associated MIDI data in every message-pair; but @dewdman42's hack happens to lengthen that all-important time gap to the point at which the hack is horribly vulnerable to stochastic interruption and disordering of port messages - even in not-so-busy conditions.
I'll go so far as to say that even compared to the much more convenient use of the AUv3 Beta version of VEP client plugins in Logic (AS or Intel), users are probably still better off using VSL's venerable and still successful Environment workaround with standard AUv2 VEP client plugins - given that the number of ports in each port cluster does not exceed, say, 16. (I seem to recall an advisory note from VSL that recommended using their Environment workaround with no more than about 10 ports per VEP instance; but I can't find it now and my recollection of that number might be incorrect.) That is, "better off" until we have an unconditionally-released version of the AUv3 VEP client plugin.
As scientists in the field of medical research are painfully aware, mere testimonials - no matter how powerful or persuasive the propaganda element may be - are no substitute for hard scientific or engineering evidence. I don't know why you've attempted to tilt the pitch in favour of @dewdman42's technically irrelevant and operationally inferior "snake oil" hack, compared to VSL's workaround, given that objective and reproducible engineering test results have well and truly settled that 'contest' - oh, unless of course you are him, posting here in a another new disguise again, LOL.
