Migrate large VEP 7 Logic template to AU3?

[rogerdp]

I have a fairly complex Logic template, based on the original VSL multiport design: an iMac with 2 slave PCs, hosting around 500 instruments in 7 instances of VEPro (separate instances for woodwind, brass, strings etc). In the environment, I'm using up to 10 ports per VEPro instance. So most of my Logic tracks are External MIDI, with a limited number of aux returns from each VEPro instance. This has worked reasonably well and allows me to use the same slave setup with both Logic and Cubase. 

However, articulation sets weren't working reliably so I have been modifying my template to use AU3, replacing External MIDI + aux returns with multiple Software Instrument tracks (all linked to one of the 7 VEPro instances). This seems to create as many issues as it solves, so I'm interested to know if there are compelling reasons for or against AU3. This is my provisional assessment:

Advantages of AU3:

• Easier to create/check new tracks, with both Port and MIDI numbers viewable/editable in the Inspector
• Greater flexibility with Articulation switching (e.g. using Art Conductor sets or AG scripting)
• Avoids the need for complex routing in the environment.

Disadvantages of AU3:

• Logic's multitimbral 'issues' make it difficult to control multiple SI tracks that share a common VEPro instance (e.g. loss of track-based MIDI control compared to separate Ext MIDI tracks).
• Confusing mixer display - also due to shared VEPro tracks
• Possible instability with some libraries (I've read that AU3 templates are generally stable, but I'm already having to consult a well-known library company to resolve persistent crashes in certain circumstances).

My combination of Logic + a small number of heavily populated VEPro instances is far from ideal (given Logic's limitations re large templates) and perhaps means it is not worth switching to AU3 in my case, but I'd be interested to know if my assessment sounds accurate and whether I've missed obvious reasons for or against AU3.

[rogerdp]

Update:

I've clarified a couple of issues:

• Articulation sets don't work with the old multiport templates unless you only use port 1:

https://vi-control.net/community/threads/articulation-sets-not-working-in-logic-x-vepro-7.91978/page-3

I'm grateful to Dewdman42 for his research into this area. It looks as though recent Logic updates may not be compatible with Environment routing/processing. This is concerning but strengthens the case for 'going with the flow' and switching to AU3.

• However, I've also confirmed with Spitfire that there's currently a bug with BBC SO artic switching when using AU3 & VE Pro (bizarrely, selecting any 'multi-tongue' artic causes crashes). This wasn't a problem with AU2/VEP (and port 1) artic changes.

Switching to AU3 now feels unavoidable if I want to use artic sets. I can disable the useless and confusing Mute and Solo options in the AU3 multi-timbral track headers and restrict myself to region-based operations, but I miss full MIDI control at track level - e.g. setting timing offsets for particular instruments.

So my conclusion is that the AU3 approach still involves compromises and workarounds in the way that the old multiport template did. I've been using Logic since Notator days, but I can increasingly see the advantages of Cubase for large-template work & articulation control.

[Macker]

AU3 is still not a clean, consolidated, properly integrated new feature in Logic Pro. On top of the cumbersome faff involved in setting up AU3 mixer strips and tracks, I've been encountering horrors when dealing with the AU3 client mixer strip's extension into aux audio strips. It's all a bit depressing but I'm still battling on with it - I have to, for now, because I use a huge intonation subsytem I've built in Logic's Environment.

What was previously a masterpiece of real-time software engineering developed by E-Magic, now seems to have fallen victim to Apple's questionable abilities in software app development. (I go back only as far as Logic Audio Platinum 3.5F, and don't know what Notator was like.)

You might indeed do better with Cubase, but a lot depends on whether you're comfortable with Steinberg's long-term marked preference for old-school PC-type functional structure and user-interaction. Recently I bought Cubase as a hedge against Logic's increasing mess - having previously tried and failed to get along with Cubase back in 2001. Although Steinberg have been trying hard to move Cubase towards today's more slick, glamorous and intuitive styles in music production software, I'm finding that learning Cubase Pro 11 involves me in something akin to a change of religion, lol. (I've been commited exclusively to Macs since 1984.) However, I'm now pretty confident that Cubase is a hugely capable and thoroughly professional DAW. One day I'll probably dump the ever more amateurish and bug-afflicted Logic and become a full-on Cubase user.

[rogerdp]

Many thanks for your reply, Macker. I think we've come to very similar conclusions about Apple's inability or unwillingness to update/rebuild the Environment. It used to be Logic's USP, but they now seem embarrassed by it and I've seen other users posting concerns about 'code rot' which doesn't inspire confidence.

Like you, I bought Cubase as a hedge and I've created a duplicate template (using common VEPro slave instances to reduce the setup work). But your 'change of religion' comment is spot on! It does some things SO much better than Logic, but other aspects feel plain wrong and I dislike the UI's comparatively crude graphics.

But I plan to persevere with both Logic & Cubase in the hope of updates which fix some of the frustrations - or at least greater familiarity with alternative options!

[Dewdman42]

what specific problem are you having with the environment?

AU3 support is still considered beta by VSL, FWIW.  There are a couple known issues and if we can identify other specific issues to watch out for, it would be good, so I'd like to understand exactly that problem you're having with AU3, precisely.

The known issues I know of as of now are:

1. The VePro.AU3 connection with VePro7 does not support playing the transport properly.  This only matters for plugins that need to use the actual transport to play sequencing from within the plugin itself or other features which are tempo related.  Plugins can DETECT the current tempo, but they can't seem to detect when playing is actually happening in order to play along with the DAW.  Its not clear yet if the bug is in LogicPro or VePro or the VePro.AU3 plugin, but the problem exists as of now.
   
   
2. When you use AU3 instruments, a port attribute becomes available for each track, in addition to midi channel.  If you use LogicPro's patch saving capability, it is currently not saving the port setting with saved patch files.
   
   
3. It appears that when an articulation set is used in LogicPro to channelize notes by articulationID, this feature does not appear to work when used together with AU3 instrument plugins such as VePro.AU3.  
   
   
4. If you use any 3rd party midi fx plugins (AU2mfx) in LogicPro, they appear to strip the port assignment from midi events as midi is passed through them on the way to VePro.AU3.  Therefore, 3rd party midi fx should not be used with VePro.AU3 if and when multiport operation is desired.

[Dewdman42]

if you like working with midi tracks, you should also check out the template I did for 1536 tracks, which uses environment multi-instruments for each VePro.AU3 port.  This results, first of all, in being able to have 768 midi tracks on 768 channels into VePro7.  Secondly it gets rid of some of the multi-timbral annoyances.

Unfortunately you still have the problem that the midi port might get stripped away or some of the others bugs mentioned, but depends on what you're trying to do exactly, might be able to work around it, need to hear more details.

[rogerdp]

Hi Dewdman42 and many thanks for your comments. Your list of known AU3 issues is very useful - it's interesting that two of them relate to port data loss - and ironic that I only started considering the use of AU3 to resolve articulation/port problems (see below).

You are right that I prefer to work with MIDI tracks and your 1536 track template sounds interesting.

My non-AU3 template uses around 500 external MIDI tracks, routed via environment multi-instruments plus up to 10 ports to one of 7 large VEPro instances, mostly hosted on two slave PCs. I like the clear separation of MIDI (send) tracks and aux returns. This setup has worked pretty well for years, but it has 2 main limitations as far as I'm concerned:

• It's not easy to check port routing and setting up new tracks can involve cumbersome new wiring in the environment.
• Crucially, AU2 articulation switching only survives the multiport routing on port 1 - this is the main answer to your question about my specific problems with the environment - and hence my interest in AU3.

In principle, I like the simplicity of being able to quickly create new AU3 tracks (and see both port and MIDI number in the inspector) without needing to change environment plugging. But the 'multi-timbral annoyances' of using SIs rather than External MIDI tracks include the loss of separate Mute/Solo controls & MIDI track parameters (e.g. delay), plus confusing mixer displays.

I hadn't previously considered trying to use multi-instruments to 'feed' the AU3/VEPro tracks. I can see that this might allow me to retain MIDI tracks, provided that the articulation switching survives the extra routing on all ports. I must investigate your 1536 track template.

Finally, re your list of AU3 issues, I'm concerned about the bizarre AU3/VEPro7/Spitfire BBC SO 'multi-tongue' articulation crashes I mentioned in previous posts (articulation switching works fine until I select multi-tongue - this causes the system to hang every time). Spitfire tech support has replicated the problem and they are investigating, but I wonder if similar problems affect other libraries and are a reflection of the beta nature of AU3 development? BBC SO was one of the first libraries I tested with my AU3 template, so I don't know if it's an isolated bug or a symptom of a wider problem.

[Dewdman42]

@Another User said:

Finally youre your list of AU3 issues, I'm concerned about the bizarre AU3/VEPro7/Spitfire BBC SO 'multi-tongue' articulation crashes I mentioned in previous posts (articulation switching works fine until I select multi-tongue - this causes the system to hang every time). Spitfire tech support has replicated the problem and they are investigating, but I wonder if similar problems affect other libraries and are a reflection of the beta nature of AU3 development? BBC SO was one of the first libraries I tested with my AU3 template, so I don't know if it's an isolated bug or a symptom of a wider problem.

That sounds to me like a bug in BBCSO, albeit, it could be because they are receiving some unexpected situation, but their software should be resilient than that.  IMHO.

[Dewdman42]

@rogerdp said:

You are right that I prefer to work with MIDI tracks and your 1536 track template sounds interesting.

• Crucially, AU2 articulation switching only survives the multiport routing on port 1 - this is the main answer to your question about my specific problems with the environment - and hence my interest in AU3.

I just tested my 1536 track AU3 template and articulation switching does go to the correct port.  So maybe give that a try.  I think its possible to make the old VePro6 multiport macro work with AU2, but you would have to go into more details about that for me to help you figure out why its not working for you.  But I still rather recommend you use the AU3 template I mentioned.

[rogerdp]

Many thanks again for all your help, Dewdman42. I've checked out your 1536 AU3 template and I think it fits the bill very well - allowing me to rebuild my old template with a similar workflow, but with a simpler environment and fewer bugs!

For the record, I was indeed still using the old VSL multiport design, with multi-instrument objects feeding port objects which in turn were connected to the VEP tracks. After tests, I established that articulation set changes were only reaching the destination instruments if those tracks were routed via the port 1 objects. For Ports 2 and above, notes were playing fine, but artic changes were being ignored.

I've now read the VI control thread above in its entirety (apologies for not doing this before) and your replies cover these issues pretty comprehensively. It sounds as though it might be possible to fix my original AU2 template (perhaps with new port objects?) but I think this would be a waste of time. You've persuaded me to rebuild, based on your 1536 AU3 template. This will take quite a while, but please assume all is well unless I post again. Best wishes, Roger

[Dewdman42]

One of the things you mentioned earlier is that in this mode you cannot see the port assignment in the track header.  Aside from including the port number in the tracker header name somehow, or grouping them in folders, etc, it may be easy to lose track of which port each track is routed to.

The easiest way I have found to verify the port# is to right click on the track header and follow the "reassign" menu option, if you keep following the sub menus you will see "-" or checkmark next to the current assignment and I have grouped them in this menu in a sensible way so that you will be able to see that way which port its assigned to, without having to enter the environment.  Its not as quick as looking at the track inspector though, so grouping your folders by port or adding something like "P2" to the track header name is not a terrible idea either.

[rogerdp]

Thanks - yes I like the way putting each VEP on a separate environment page helps simplify the 'reassign' checks.

I've already modified your template by creating 8 VEP pages, but reducing the number of channels in each to 16x16. This allows me to keep my existing VEP instances (woodwind, brass, perc etc.) and removing the extra ports keeps the nested 'reassign' menus nice and simple. All good so far!

[Dewdman42]

Great to hear!