# VEPro and Logic setup



## MarcusMaximus (Oct 28, 2018)

I'm sure this has been discussed a million times but searching actually found very little on this topic, though no doubt I missed some relevant threads!

I'm in the process of setting up Vienna Ensemble Pro on a slave PC with Logic on a Mac. Of course I'm trying to work out the best way to make use of more than one midi port per instance. Before I put a load more time into this I would love to know what the best setup is currently, before we have AU3 working in VEPro.

Which of the following is generally found to be the best way of running VEPro in conjunction with Logic in a master-slave setup these days?

1. Using a single Logic track/instrument per VEPro instance, resulting in a huge number of instances for a large orchestral template.

2. Using the Event Unit plugin to achieve multiport connectivity and thus vastly reducing the number of Server instances needed.

3. Using the Multiport layer templates to achieve the same thing. I've read a lot to suggest that this way isn't really viable but is that what people have actually found to be the case?

I'd appreciate any guidance so that I can put the considerable time it takes to set up a template to best use! Thanks.


----------



## Saxer (Oct 28, 2018)

There are rather fresh discussions about it here:
https://vi-control.net/community/threads/vepro-with-logic-routing.61153/

https://vi-control.net/community/threads/logic-workaround-for-bounce-in-place-on-midi-track.76162/

I personally do the instrument per instance approach which works better in Logic in my (and not only my) opinion. But I avoid monster templates anyway so I'm not limited by the 256 instrument limit in Logic.


----------



## Oguz Sehiralti (Oct 28, 2018)

When I used to use logic, I found that while the event plugin does work most of the time, it wasn’t reliable enough and I had to reconnect sometimes. I found that 16 channels per instance worked more reliably.


----------



## MarcusMaximus (Oct 28, 2018)

Thank you very much for your prompt responses. I'm embarrassed that I missed those threads though I did try a few different wordings! Will have a read through them now.

Good to hear about people's real-world experience. I've been having some success with small experiments with the E. U. plugin, apart from not being able to get the audio to show up back in the relevant Logic tracks. So it's great to get this feedback before I embark on more extensive testing.

I don't use a monster template either. Mostly just the standard orchestral setup with a limited number of other tracks for synths, audio etc. I'll probably only or mostly use VEPro for the orchestral instruments and run other plugins directly in Logic, given the PC's SSD currently houses only the orchestral libraries.


----------



## Dewdman42 (Oct 28, 2018)

If you don’t need a monster template then I would not mess around with event input plugin nor multi port template. Those are primarily advantageous for super large templates.

I personally prefer to have a say a dozen or less vep instances. You can definitely do that with 16 channel multi’s in LPX. 

There are three different ways that I know of to handle 16 channel multi’s in LPX, each with pros and cons, so pick your poison.

The single instance per instrument approach also has some pros and cons, so consider that the 4th option. 

They are all fine approaches, none stands out to me as the perfect approach they each have benefits and problems and ultimately it just depends on how you want to work.


----------



## MarcusMaximus (Oct 30, 2018)

Ok thanks for that. I probably need to dedicate a whole instance to the one instrument as I use up a lot of the 16 channels for the different articulations of each instrument (this is with EW Hollywood Orchestra). I suppose I could put more than one instrument into a single instance where I don't need too many articulations however I also use SkiSwitcher for articulation switching so I don't know if that would work out. This is using an ordinary instrument rather than a multi btw. I'll have to experiment with using multi's instead but I don't want to get into having to use too many aux channels - I believe in keeping things as simple as possible because of Logic's peculiarities!


----------



## Ashermusic (Oct 30, 2018)

I have a Hollywood Orchestra Diamond VE Pro Template with an accompanying Logic Pro X template with ArtZID scripts and articulation sets, but I charge for either giving it to people or teaching them how over Skype.


----------



## MarcusMaximus (Oct 30, 2018)

Thanks Jay. I'll certainly keep that in mind and may come back to you if I run into more problems than I can solve on my own!


----------



## Dewdman42 (Oct 30, 2018)

If you don't mind having a buzzillion VEP instances, then its not a bad way to go to avoid using LPX multis at all. You can have a single Logic track feeding a single non-multi instrument channel, with some kind of script like ski switcher to channelize different articulations. Then in VEP you could have up to 16 channels of articulations for each one. Here are the advantages and disadvantages of that as I see it:

Advantages

You can easily freeze tracks in logic
No aux channels used for the returning audio
No environment futzing around
Articulation related scripting is generally easier if you're dealing with one track at a time. In fact you get to use the midifx section of the instrument channel dedicated to one track, rather then shared by numerous tracks.
Very easy and straightforward to setup.
Disadvantages

Not possible to create large track-count templates > 250 tracks
If you use a lot of tracks (up to 255), then you end up with a lot of VEP instances which is not ideal for navigating around in VEP.
I wrote a post about some of this stuff here, might be a good read for you:

https://www.logicprohelp.com/forum/viewtopic.php?f=1&t=132635&p=697195&hilit=multi+bug#p697195

Bottom line is that there is no one best way. It just depends on which gotchas you can live with. if you can live with track templates no bigger then 255 tracks and you can live with having a lot of VEP instances to navigate around to and doing all the mixing in Logic, then definitely the one channel per instrument approach has a lot of merit.

If, on the other hand, you need larger sized templates....or if you want VEP to have less then, say 10 instances to work with at a time, then you need to consider LPX multis...and see the above link for some pros/cons about each way of working with multi's.

As to whether to use multiport or not has only to do with whether you want more than 16 channels per VEP instance. You might want that in order to keep the number of VEP instances to a minimum, or because you want to handle more than 16 articulations for a single instrument or because you want to submix sections in VEP. Or if you want truly huge templates with more than 500 tracks, then you need multiport mode.


----------



## Ashermusic (Oct 30, 2018)

Unless things have totally changed in the last year, which is possible, avoid the multiport like the plague.


----------



## Dewdman42 (Oct 30, 2018)

Ashermusic said:


> Unless things have totally changed in the last year, which is possible, avoid the multiport like the plague.



Yes they have changed, I made new macros and templates without the bugs that existed in the ones released by VSL. Have you tried it?


----------



## Ashermusic (Oct 30, 2018)

Dewdman42 said:


> Yes they have changed, I made new macros and templates without the bugs that existed in the ones released by VSL. Have you tried it?




I know you have spent a lot of time for this, so I will take your words for it. Personally, I don't find the workflow appealing though.


----------



## Dewdman42 (Oct 30, 2018)

I am not even sure whether I do either! But its an option that is available and for those that need it, I don't think people should categorically "avoid it like the plague". Mainly it provides support for super huge templates and low numbers of VEP instances and ability to submix more than 16 instruments in VEP. If you don't need those things, then I agree, its better to keep things simple.

Beyond that, the next level down of complexity is using some kind of LPX multi, but without multiport. You can still get some decent sized track counts with only a dozen or so VEP instances. LPX multis have their own bit of headaches as many here know, but they are workable. There are at least 3 different ways of handling multis in LPX.

The simplest approach is no multis at all, and there are some definite advantages due to Logic's peculiarities, but there are disadvantages too, namely, if you have a lot of instruments in your project, then you will be wading through a lot of VEP instances and no ability to submix sections in VEP. One big advantage of this approach is that some of the articulation scripting solutions can get overwhelming if you have many tracks feeding into a single LPX multi, since Scripter is hosted on the multi's channel rather then on each track. so the single track/channel per instrument approach makes articulation management much more straightforward, particularly if you're using Scripter in any way at all.

it really is a matter of picking your poison... I think I prefer to avoid multis at all if I can. But as i have messed around with this I have learned the ups and downs of multis and I'm not that afraid of them anymore. After fixing the multiport macro bug, I'm not afraid of that either, but still, if I don't need multiport, then I don't use it. Because its just one more level of complexity and if I don't need all those CC99 events flying around, then I don't want to.


----------



## Ashermusic (Oct 30, 2018)

As I said Dewdman, if you say it now works decently I am happy to take your word for it. I will stick with my"like a score page" method.


----------



## Dewdman42 (Oct 30, 2018)

can you elaborate on what your "like a score page" method is?


----------



## Ashermusic (Oct 30, 2018)

Dewdman42 said:


> can you elaborate on what your "like a score page" method is?



For instance: In VE Pro I create a single instance with 1 instance of Play for HS HS Violin 1 with however many articulations I want. I connect it to a single VE Pro software instrument, decoupled, and switch articulations on the fly as I perform the part with ArtZ ID.

I follow suit with the rest of the orchestra, except the percussion where I may switch from e.g. xylophone to marimba to glockenspiel etc.


----------



## Dewdman42 (Oct 30, 2018)

Right..that is the single-track-channel per instrument approach. So how is that more like a score page compared to using multis or even multis-with-multiport?


----------



## Ashermusic (Oct 30, 2018)

Dewdman42 said:


> Right..that is the single-track-channel per instrument approach. So how is that more like a score page compared to using multis or even multis-with-multiport?


It depends. If you use multiple tracks to address the multi, that isn't like a score page correct?


----------



## Dewdman42 (Oct 30, 2018)

So as I understand you, "like a score" is referring to one TRACK per instrument on the arrange page of Logic, regardless of whether a multi is used for the instrument channel. I prefer that way of working also, without question!

What about if you have two tracks, for example, one for oboe and one for clarinet; and each of them has 6 articulations. So both of those two tracks feed into one multi-instrument channel, which is doing whatever it needs to do to manage the 6 articulations each, it might be sending key switches or might be channelizing as if often the case with EW, for example... but that would be a case of using LPX multis...and still being "like a score" in so much that there is exactly one track per instrument, regardless of how many articulation channels are needed inside the actual instrument.

Actually the same can be true with multiport as well. You can have one track per instrument "like a score" but have numerous of those instrument tracks feeding through one multiport instrument channel, which is handled inside VEP by one or many actual channels of instruments.

I definitely agree with you about one track per instrument like a score being my preferred way to use the sequencer in Logic. What I like about using multis in the channel and VEP is that I can reduce the number of VEP instances involved and do submixing in VEP if I want, and also provide for extremely large track-count templates if I want, though I haven't gotten around to setting that up yet.


----------



## Ashermusic (Oct 30, 2018)

Dewdman42 said:


> So as I understand you, "like a score" is referring to one TRACK per instrument on the arrange page of Logic, regardless of whether a multi is used for the instrument channel. I prefer that way of working also, without question!
> 
> What about if you have two tracks, for example, one for oboe and one for clarinet; and each of them has 6 articulations. So both of those two tracks feed into one multi-instrument channel, which is doing whatever it needs to do to manage the 6 articulations each, it might be sending key switches or might be channelizing as if often the case with EW, for example... but that would be a case of using LPX multis...and still being "like a score" in so much that there is exactly one track per instrument, regardless of how many articulation channels are needed inside the actual instrument.
> 
> ...



But since articulation sets work on the software instrument channel strip and not discretely on specific tracks, then you have articulation switching issues with using e.g. a flute track and an oboe track flowing through the same one. Also, the whole cc7-panning thing.

So for me, no, creates more issues than it solves.


----------



## Dewdman42 (Oct 30, 2018)

Ashermusic said:


> But since articulation sets work on the software instrument channel strip and not discretely on specific tracks, then you have articulation switching issues with using e.g. a flute track and an oboe track flowing through the same one.



But they are each on their own midi channel. Any Scripter-based solution should easily be able to listen to each midi channel and handle each one separately, adding keyswitches or channelizing appropriately. Scripts do have to be more elaborate in order to do that then if they handle only one input midi channel, so for sure, one advantage of one VEP instance per instrument is that each script can be much simpler. I don't really see that as a technical barrier unless the 3rd party solutions are not up to that task. Logic's built in Articulation Set can definitely handle that, but it has other problems, so I digress.



> Also, the whole cc7-panning thing.



Can you describe this issue better? If you have a midi track, CC7 is sent over midi to the listening instrument and I don't see that as being any kind of problem. It CAN be confusing to deal with Apple's default approach to Multis...which makes the little slider on the track header go to the whole multi instrument rather then to the individual channel. But if you use multi-instrument from the environment or the AUX track trick, then its not an issue...For environment version CC-7 goes over midi to whatever is listening at the other end on that channel. For the AUX trick I think the fader goes to the AUX channel. Logic's handling of track headers with multis is brain dead, no argument there.

But anyway I just want to clarify that the whole one-track-per-instrument "like a score page" concept is doable with all of these approaches, using multis or not. But what is not clear is how articulations will be handled when using some third party Scripter solutions and perhaps some confusion about the track header fader when using Apple's default Multi configuration. what you're really vouching for as being different is one instrument channel per track....which means one VEP instance per track.


----------



## Ashermusic (Oct 30, 2018)

I abandoned the MIDI and MULTI Instruments that you create in the Environment and cable _years_ ago and I never want to see those f#[email protected] things again in a Track List.


----------



## MarcusMaximus (Oct 30, 2018)

Very interesting discussion guys. I'll just interject this for now.

Yes, so far I have been using the 'instrument on a single track' in Logic connected to one instance in VEPro approach. I haven't tested it on a full project as yet but it makes sense to me both in terms of keeping Logic's main window 'like a score' in that all the instruments are in that order and only take up one track each and also hopefully allowing Logic to work optimally as people have been saying. I have the instruments grouped in stacks (one for flutes, one for oboes and so on) and then all the sections grouped in another layer of stacks. I have separate windows for volume, modulation, expression, score and velocity etc., all triggered by particular number keys, with SkiSwitcher managing the articulation switching.

My template has been set up this way for years and it works very elegantly. At the moment I'm in the process of adapting it to use alongside VEPro because I needed a slave setup due to the limitations of my humble Mac. The only reason I started to look at the multiport and Event Input options was because I wanted to find a way to unify the VEP mixer, i.e. to be able to view all the instances and their respective channels in the one window. Alas that doesn't seem to be possible so it'll have to wait for whatever becomes doable with AU3 I'm guessing. It's not really a big deal because ultimately I prefer to do all my mixing in Logic as that's been my home DAW for well.. let's say a very long time!


----------



## Dewdman42 (Oct 30, 2018)

AU3 won't change the situation much for you or for how Asher likes to work. All that would do, _theoretically_, is allow Logic to assign a port to a track, in addition to a midi channel; rather than having to use the multiport environment macro to emulate that behavior. All the macro does now is insert a CC99 event front of every midi event...which when it later arrives at the VEP plugin, it is converted back to a port assignment before sending over to the VEP server. An AU3 VEP plugin will eliminate the need for the CC99 macro insertions.

but...

Logic still has a fundamental issue that it does not really support very well multi-out instruments. Its handled now by funneling all midi from multiple tracks through one instrument channel, which hosts one instrument and brings back the results either directly to the instrument's stereo feed or separately as AUX's. And as Asher has explained, this means if you have lots of tracks trying to feed a single AU3 instrument, you still have some of the same problems...you have lots of tracks going through one Scripter script to handle articulations. And if you want the audio coming back to logic to mix, then you have lots of the audio coming back on AUX channels.

The AU3 version, if it ever materializes, will be very very beneficial to those people wanting huge templates...or people that want to get more instruments into less number of VEP instances in order to navigate easier and/or for submixing sections in VEP, which some people, including myself, actually prefer in many cases. If you prefer to mix everything Logic and don't care about navigating through a hundred VEP instances, and don't need huge templates, then it will not really benefit you at all any more then the multiport macro, other then eliminating some macro complexity or the need for environment stuff at all, which many people feel like Asher about.

Apple really needs to provide proper multi instrument handling in some way. We ought to be able to have a separate midiFX plugin section for each TRACK, regardless of whether its feeding into a single or multi instrument. And the returning audio should NOT go through AUX's, it should go come back as instrument audio with PDC handled the same way. And we should definitely not be limited to 255 channels of it! Logic is way behind the curve on that front.


----------



## Dewdman42 (Oct 30, 2018)

Just a little side-note about this:



Dewdman42 said:


> Apple really needs to provide proper multi instrument handling in some way. We ought to be able to have a separate midiFX plugin section for each TRACK, regardless of whether its feeding into a single or multi instrument. And the returning audio should NOT go through AUX's, it should go come back as instrument audio with PDC handled the same way. And we should definitely not be limited to 255 channels of it! Logic is way behind the curve on that front.



What should happen is when you put a multi instrument into an instrument channel in Logic, then Logic should detect that it has n number of midi inputs, most likely 16 channels, but if its AU3, it could be n number of ports too. When you reassign a track to an object, you can reassign it to not only the specifics channel, but the specific port too. Ok so far, but then in the mixer the instrument channel should show multiple strips, one for each midi port/channel that is being used. And on that strip you would have the midifx section to use for it...as well as a place for the returning audio (not in an aux!).

Why they didn't do it like that to begin with is I guess because they didn't think anyone would be using multis or something, its beyond me. Very limited thinking on their part.

If and When Logic can support AU3 plugins, with ability to route tracks to specific port/channel...and the ability to host a complete inst sub channel with its own midifx section and returning audio...then finally we will be able to easily realize the kinds of big multi instrument templates that are easy in Cubase and DP, without resorting to Apple's peculiar multi's and the multiport macro. Until such time, this is what we got.


----------



## procreative (Oct 31, 2018)

For me after much experimentation, even though I can make multiport work with the VEP Event Input plugin/IO Insert workaround, the lack of separated audio with Multimbral/Multiport is the dealbreaker.

Initially Event Input gave the impression of independent audio as all the Mute and Solos seemed to function independently. But its a GUI fraud that does nothing...

I could deal with the lack of separated audio from a mixing point of view as if you imagine a string section coming from a specific library eg Hollywood Strings, you might do most of the balancing and spacial treatment in VEP and individual dynamics/volume would be dealt with by CC data.

But where it gets frustrating is not being able to quickly mute or solo an instrument within that section. Say I have Violins, Violas and Cellos all playing but I want to hear just Violas to check them?

My only option is to Solo the Regions. As I have a Mackie it seems wasted as the only way to achieve this is by clicking the regions or using a key command, but its just not as intuitive as clicking a Mute or Solo button.

I hate the extra Aux channels you have to use with Multi Output as you end up with 2 channels for every track. Why they cannot have some kind of I/O for internal routing like they do for external audio?

I was excited initially by the thought VEP are developing an AU3 option, but fact is for large orchestral templates, it wont change that much as we will still have the crap audio routing.


----------



## samphony (Oct 31, 2018)

procreative said:


> For me after much experimentation, even though I can make multiport work with the VEP Event Input plugin/IO Insert workaround, the lack of separated audio with Multimbral/Multiport is the dealbreaker.
> 
> Initially Event Input gave the impression of independent audio as all the Mute and Solos seemed to function independently. But its a GUI fraud that does nothing...
> 
> ...



But aux tracks in the tracks view are exactly that. They can receive audio and send midi. They even allow to have their own articulation set.


----------



## procreative (Oct 31, 2018)

samphony said:


> But aux tracks in the tracks view are exactly that. They can receive audio and send midi. They even allow to have their own articulation set.



Yes but you end up with 2 tracks if you add them to the Arrange page. Maybe there is a strategy using Hide Groups to deal with that, but its not ideal.

Then there is the conundrum that if you use Multiport in an effort to save CPU/Load Times, if you use Auxes to route the audio back from VEP you probably end up with a similar result.


----------



## Dewdman42 (Oct 31, 2018)

Just to be clear, if you use environment multi instrument objects for your tracks then you can mute and solo the midi on a track by track basis. I know that doesn’t help you procreative because of your extra requirement with the automated faders and smart controls but just wanted to point that out.


----------



## MarcusMaximus (Oct 31, 2018)

Yeah the need to have an extra aux channel/track to manage the audio from every VEPro output thus doubling up the track count in Logic is one of the main things that has put me off using the Event Input plugin. That and hearing from some people that it's not that stable anyway with occasional dropped notes and so on. I could certainly do without having to use multiple VEPro instances but I'd rather a stable and reliable system based on a simpler track count and routing setup in Logic even if that means having to navigate through all those separate instances.. pity there's no way to view them simultaneously in VEPro but that's the way it is for now.

So I'm going to need about 40-50 instances to take care of a full orchestra. I tend to keep things fairly simple and don't currently use multiple libraries for the sections, mostly Hollywood Orchestra. Obviously there will be times when a project will demand more instruments or extra layering but I envisage hosting most other libraries on the Mac and therefore bypassing VEPro in these cases. Will have to see how it all works out. Anyway I'm assuming, based on what I have read here and elsewhere, that that number of instances would be feasible with the ordinary (not multi due to probable conflict with SkiSwitcher) instrument-per-instance approach. So Flute 1 will have its own instance with the articulations using up many of the 16 channels, Flute 2 the same and so on.


----------



## Dewdman42 (Oct 31, 2018)

Also in the manual it states that the event input plugin adds more latency and that it doesn’t spread the work across cores properly.


----------



## MarcusMaximus (Oct 31, 2018)

I've been using SkiSwitcher for years and have never upgraded to ARTzID, despite having Logic 10.4. However I've just been looking into it and this jumped out at me as one of the features in version 2:

• The VEPro Multi-Port 64 Script

Send MIDI on up to 64 virtual channels across four ports to Vienna Ensemble Pro without a single environment component. Supports up to 96 articulations per track.

Could this be the answer to the multiport vs. multiple instances issue? I'm going to research it some more but this looks pretty exciting..


----------



## Nick Batzdorf (Oct 31, 2018)

procreative said:


> My only option is to Solo the Regions



Or the notes. I don't quite understand why that's a disadvantage.

As to multiple outputs from an instrument, I can't really think of a more elegant way to implement that than having them appear in the mixer if you want them. They'd be in the way if they were on the track in the Main window.


----------



## procreative (Oct 31, 2018)

Nick Batzdorf said:


> Or the notes. I don't quite understand why that's a disadvantage.
> 
> As to multiple outputs from an instrument, I can't really think of a more elegant way to implement that than having them appear in the mixer if you want them. They'd be in the way if they were on the track in the Main window.



True. But if you use a control surface, you need the Auxes visible to automate volume, pan etc (they are anyway by default) so you end up with the Multi Output tracks and their Auxes showing on say an MCU which clutters up things and gets confusing as until you touch a fader its hard to see which are Tracks and which are Auxes...


----------



## Dewdman42 (Oct 31, 2018)

MarcusMaximus said:


> I've been using SkiSwitcher for years and have never upgraded to ARTzID, despite having Logic 10.4. However I've just been looking into it and this jumped out at me as one of the features in version 2:
> 
> • The VEPro Multi-Port 64 Script
> 
> ...



You should ask Peter. I believe this is for sending only. So as stated, this will let you have more than 16 articulations per instrument....by sending articulations across ports. However, this will not support having many tracks funneling through a single instrument channel in order to have high track counts and less VEP instances. In order to do that, a script would need to be aware of incoming CC99, and handle each port/channel separately in terms of which articulation key switches to send, to which port/channel to send them, and/or channelizing of events accordingly, etc. I believe his scripts just open up the possibility of channelizing articulations across more than 16 midi channels, but still assumes all incoming events are one "instrument", probably coming from one track.


----------



## MarcusMaximus (Oct 31, 2018)

Aww.. you just rained on my parade Dewd ! Anyways, I've just bought the upgrade so I'll look into all the ins and outs over the next couple of days and see what it can and can't do in terms of my evolving workflow.


----------



## Dewdman42 (Oct 31, 2018)

Nick Batzdorf said:


> As to multiple outputs from an instrument, I can't really think of a more elegant way to implement that than having them appear in the mixer if you want them. They'd be in the way if they were on the track in the Main window.



If the multi-outs come back, they can come back as AUX channels or as instrument sub channels of some kind. Either way, extra mixer channels show up. I think it would be more clear if they were instrument sub channels rather then AUX channels tacked on the side...for a variety of reasons. 

I think people are just freaked out mostly by super huge mixer boards that are hard to organize.

One thing that is annoying is that when you choose ALL on the mixer view tab, the multi-out AUX channels are positioned way far to the right, far away from the channel 1 instrument channel of the multi. They are only grouped together if you view by TRACKS. Annoying. Anyway if multi instruments were always treated as multi channel objects, with their multi-out channels always appearing together...and distinguished from other AUX channels as being instrument channels, this would help a lot of people when they are trying to keep track of everything.

it would also be very easy for Apple to have 1:1 correspondence between arrange page track headers and the corresponding instrument multi channel outs, this would be more similar to when people use the AUX track trick...except that things would actually work entirely properly, which they don't always with the AUX track trick.

Also, its not clear to me whether multi-out AUX channels handle PDC as normal AUX channels do, if so, then that is really bad and potentially adds a lot of unnecessary latency which would be avoided if they were handled more like instrument audio channels. AUX channels in general handle PDC by delaying all other tracks by however amount is needed for the AUX channel's plugin latency. They are treated like "live" mixing channels, which multi-out instruments are not!

Instrument channels are handled by feeding the midi regions to them early during playback without adding any other delay anywhere else, in order to handle PDC. So my preference would be for all instrument tracks to have PDC handled exactly the same way... If the multi-out AUX channels are handled like other AUX channels in terms of PDC, then its poor design. Also there is the limit of only 256 AUX channels.


----------



## Nick Batzdorf (Oct 31, 2018)

Dewdman42 said:


> One thing that is annoying is that when you choose ALL on the mixer view tab, the multi-out AUX channels are positioned way far to the right, far away from the channel 1 instrument channel of the multi.



Yeah, it would be good if you could construct your own mixer in the Environment out of the new channel strips. I have that set up with the old ones - and have had for years - but it's not for mixing, it's more of an overview of my entire rig that I use to assign things to tracks, insert plug-ins, etc.


----------



## Peter Schwartz (Oct 31, 2018)

The VEPro Multi-Port Script for ARTz•ID is something I made in response to those composers who expressed an interest in implementing a multi-port setup without the environment components. It's successful in that respect, but it's of limited usefulness because of the MIDI bottleneck that Dewdman described.

That's not to imply that it's "useless", though. You just need to try it out and see how well it performs. An interesting application for it, shared with me by an ARTz•ID user, is to assemble a collection of percussion sounds in your VEPro Instance. You can amass huge collections of such sounds and access them all from one track. And if you need to process different sounds individually, you can always use the multi-output version of the VEPro plugin and return those specific sounds to Auxes. Meanwhile, all parts are played on one track, and it's all quite seamless.

In some respects, the Multi-Port Script functions like the Combinatrix Script, letting you amalgamate multiple patches (keyswitching or individual) in one place and access all of those sounds on one track. The difference between the two Scripts is the style of MIDI routing. Unfortunately, multi-port style MIDI routing requires that every single MIDI message (including every single increment of any CC) be prefixed with a MIDI "header message", and that makes multi-port routing highly inefficient. So imagine...

You play two notes, each routed to a different port, and each one is accompanied by CC#11 information for that port. Routing the notes isn't an issue, requiring only 1 extra MIDI message in front of each note message to route it to the correct port. But every single CC#11 message needs to be headed off by a routing message also. So long, continuous rides of CC#11 eat up 2x the amount of "MIDI bandwidth". While that might not be so bad for just two notes, more intense parts (more notes, more CC's, etc.) will start to tax the system.

So I'd suggest trying a setup or two with the multi-port Script and see how it works. You can always fall back on the Combinatrix script if need be.

Remember, you can always write to me and discuss applications.


----------



## MarcusMaximus (Oct 31, 2018)

Thanks for clarifying Peter. Although no doubt very useful, and I'll certainly explore the various scripts as you suggest, what I'm looking for is a solution similar to what the Event Input plugin initially appears to promise. This would be where you could have multiple tracks in Logic dedicated to say all the wind instruments routed to the different ports in one instance in VEPro and then the audio from those routed back to the original tracks in Logic without any need for additional aux's. This is probably repetitious and obvious but just thought I'd spell it out here. I would have thought this is what your composers were also looking for when they requested a multiport setup but maybe they were happy enough to use Aux's on the way back in to Logic, if I've got all this right! 

Seems like there isn't really anything that can do that without a complicated environment setup in the background and if what Dewdman says is correct, even an AU3-enabled VEPro plugin probably won't be able to achieve it. Now I might have mis-understood a lot of this partly because I haven't had the chance to properly try everything out yet and partly because my understanding of the technical ins and outs is limited but that does seem to me to be the situation for now.

Anyway, I will be installing/exploring ARTzID over the next while and I may well take you up on your offer if I need to ask you about my particular application. Many thanks for that as always.


----------



## ptram (Nov 1, 2018)

procreative said:


> Yes but you end up with 2 tracks if you add them to the Arrange page.


I may still be confused, but isn't an single Track used for each sound in the score? With Multi-Output Instruments, you use the first Out pair for a Track, Auxes for the remaining 15 Out pairs, and each of these 15 Out pairs for other 15 Tracks.

But, again, I may still be confused with this issue.

Paolo


----------



## procreative (Nov 1, 2018)

You are correct generally, but if you wish to use VEP and multiple Midi Ports things change.

For instance if I use the VEP Event Input approach, I have to have 1 Track with the VEP Server plugin and extra tracks addressing the same VEP instance need to have VEP Event Input plugins.

So if you then want to send the audio back, you need to use the Multi Output Kontakt in VEP, enable multiple Outputs in the VEP instance then create Auxes as usual in Logic.

However using this approach, you are creating an Aux and a Track with the Event Input plugin for each extra track addressing the VEP instance. So you end up with 2 tracks addressing the same element.


----------



## Dewdman42 (Nov 1, 2018)

That’s one reason the aux track trick is generally very attractive. It’s unfortunate that it’s only an undocumented “trick” and doesn’t function 100% in terms of a few things like articulation set peculiarities, no track delay, and other little things. I think if Apple made proper multi out instrument tracks/channels then it would most resemble this in terms of how it would look on the arrange page and mixer....except hopefully not using aux channels and having all those other quirks sorted out to operate 100% like any instrument track


----------



## MarcusMaximus (Nov 1, 2018)

procreative said:


> You are correct generally, but if you wish to use VEP and multiple Midi Ports things change.
> 
> For instance if I use the VEP Event Input approach, I have to have 1 Track with the VEP Server plugin and extra tracks addressing the same VEP instance need to have VEP Event Input plugins.
> 
> ...



Exactly. Which is what I'd like to avoid if possible. However am I correct in wanting to avoid that? I mean having two tracks for every instrument is a pain and would make for an unwieldy main window and mixer (which could be got around by hiding tracks/groups I suppose) but beyond that inconvenience, does it really slow down Logic's performance or add significantly to the CPU load? What are the real drawbacks (with significant impact on workflow or performance) of using the Event Input plugin, apart from this double track count? Has anyone had success with it in terms of a satisfactory and stable setup? Before I put the work into setting up a template based on an instrument-per-instance I'd like to be pretty sure I was ruling out the Event Input approach for good reason. I'm more sure about not wanting to go the multiport route.


----------



## Dewdman42 (Nov 1, 2018)

Having two tracks per instrument should not effect performance it’s more of a screen clutter annoyance.

The event input plugin has been around a long time. Read about it in the vep6 user manual. Vsl says there that it adds latency and doesn’t spread across cores right. For me that is reason enough to avoid it. I believe they tried to release the multiport macro as a later better solution then the event input plugin as it does not have those problems. Unfortunately it had other problems and didn’t work right either. Since then vsl gave up on the environment and is looking to a future AU3 solution someday for multiple ports.

Based on things you have said on this thread I think you should avoid either one. Why do you need multiport?

For me the best compromise is using LPX multi’s with 16 channel vep instances. No multiport. But on certain occasions if I do want to use more then 16 channels in a vep instance then I don’t mind using the improved multiport macro but in limited doses, a few extra ports here or there. Seems to work fine that way.


----------



## Peter Schwartz (Nov 1, 2018)

MarcusMaximus said:


> Thanks for clarifying Peter......what I'm looking for is....where you could have multiple tracks in Logic dedicated to say all the wind instruments routed to the different ports in one instance in VEPro and then the audio from those routed back to the original tracks in Logic without any need for additional aux's.



You're welcome!

What you're asking for is definitely possible. But before I elaborate, I'd like to understand why you want to have all the wind instruments located in one VEPro Instance. Would it be all the same to have separate instances, even if it was a separate instance for (say) each specific library you're using?


----------



## procreative (Nov 1, 2018)

I am just thinking about whether I could use Multitimbral/Multi Output for some of my libraries, specifically ones where they are Keyswitch based but with some I am a bit stumped how I might do it?

Some of the libraries I use for example Berlin Strings First Chairs, have more features in standalone patches than in their Capsule versions. In this example the Legato patch has more control.

So I am often ending up with 1 Master Patch and a Legato Patch in a Multi.

Now if I were to try to incorporate into a Multitimbral setup I might have to set up as:

Violin 1 KS Channel 1
Violin 1 Legato Channel 2
Violin 2 KS Channel 3
Violin 2 Legato Channel 4
Viola KS Channel 5
Viola Legato Channel 6
Cello KS Channel 7
Cello Legato Channel 8

Now obviously I can address these using either ArtzID or Articulation Sets, but I surely would need to set each track to Midi "All"? I cannot see a way to set up a track to only output to a set of channels, for example 1+2, or 1-3 etc. Is there a way to do this?

I know that once recorded with IDs it wont matter, but auditioning sounds would be hard.

Because I can see a way cut right down on VEP instances by doing this.


----------



## MarcusMaximus (Nov 1, 2018)

Dewdman, I was referring to the Event Unit plugin solution as a whole affecting performance, not the extra tracks; perhaps I didn't make that clear. Unless invoking all those extra Aux tracks in and of itself can cause performance issues.

I have read the vep6 manual through several times and am aware that the Event Input plugin has been around a long time, also the history re. VSL introducing the multiport templates later. I know that the manual states that it adds latency but it also says that that shouldn't affect playback. I have found in my short time experimenting with it that if the buffer is reduced to 'none' in the plugin, this is fairly acceptable in terms of playing parts in. I don't remember reading about how it doesn't spread well over cores but I might have missed that part.

Thanks for your suggestion to avoid either one and I may well do that. I think I have stated elsewhere that the main reason I would like fewer instances is that I would like to be able to unify the VEPro mixer so that I can view all the channel strips on the same screen, at least say all the channel strips in the Winds or Brass or whatever instance, rather than having to click on the relevant instance every time I need to adjust anything on a single channel strip that isn't currently visible.

Peter, hopefully this explains why I'd like to have fewer instances. I was thinking 4 or maybe 5, one for each of the orchestral sections. I'd be interested to hear your elaboration on how this could be achieved!


----------



## Dewdman42 (Nov 1, 2018)

MarcusMaximus said:


> Dewdman, I was referring to the Event Unit plugin solution as a whole affecting performance, not the extra tracks; perhaps I didn't make that clear. Unless invoking all those extra Aux tracks in and of itself can cause performance issues.


I don't really understand the issue. If you need the sound as separate channels, then you need it. You won't be doubling the number of those no matter what you do. The only "doubling" of tracks that occurs, happens from midi on a separate track then the returning audio, but this is really just a visual representation issue...you're not really adding anything extra. The Event Input Plugin explicitly does not return any audio, so its not technically a doubled audio channel. Well I guess it is, but its not a used audio channel.. I don't think it will be an issue in terms of performance.




> I have read the vep6 manual through several times....I know that the manual states that it adds latency but it also says that that shouldn't affect playback. I have found in my short time experimenting with it that if the buffer is reduced to 'none' in the plugin, this is fairly acceptable in terms of playing parts in.



If you have to reduce the buffers to "none", then you will have less cpu efficiency overall and so yes it will be effecting performance, then it would be otherwise if you could have the buffer set to 1 or two. You asked about performance, so its as simple as that, if you can live with the extra latency then no, but if you lower the buffer to get the latency back to tolerable levels, then yes its effecting performance.



> I don't remember reading about how it doesn't spread well over cores but I might have missed that part.



See page 59 of the current manual, section related to LogicPro.
From the manual:


> For proper functionality when using the Audio/Event Input plug-ins in Logic, both the channel that has the mainVienna Ensemble PRO Plug-in and the channels that have an Audio/Event Input Plug-in must be forced into Logic’s „Live“ mode.
> 
> *NOTE: Logic channels that are in “Live” mode as well as channels that are connected to those channels will run their processing tasks on a single CPU core.*








MarcusMaximus said:


> Thanks for your suggestion to avoid either one and I may well do that. I think I have stated elsewhere that the main reason I would like fewer instances is that I would like to be able to unify the VEPro mixer so that I can view all the channel strips on the same screen, at least say all the channel strips in the Winds or Brass or whatever instance, rather than having to click on the relevant instance every time I need to adjust anything on a single channel strip that isn't currently visible.



No doubt, I feel your pain. I feel that 16 channels per instance is usually a reasonable compromise. you can do an orch mock up with 100 tracks or so and that is only half a dozen instances if done that way. No multiport is needed for that. Half a dozen instances is not bad to wade through if they are organized well. Another thing is that 16 channels per instance kind of fits a "normal" sized VEP window, at least on my monitor, so I don't have to scroll at all to see all the channels of each instance. I still have found a benefit occasionally to have a slightly larger VEP instance when I didn't want to spread, for example, my strings or brass across multiple instances. In that case, for the time being, the only way is use Event Input or Multiport Macro. I am having good results with the Multiport macro in small doses, but not with huge templates, LPX can't keep up.


----------



## Peter Schwartz (Nov 1, 2018)

@MarcusMaximus, as I'm reading through more of this thread I saw that earlier you wrote, "I'm more sure about not wanting to go the multiport route."

Good! And since you asked for my thoughts, now maybe it's time for my stock spiel about this stuff. I'm not going to qualify anything with "YMMV" and stuff like that. This is straight talk, and intentionally didactic.

0. *Ground Zero*
The simplest workflow is to be ale to record and engineer a sound on the same track. That can't be divided down to find a smaller common denominator. It is the common denominator.  But this doesn't mean you can't take the approach of using multiple outputs. It's just a variation on a theme. Here, using multi-output plugins shouldn't preclude anyone from recording all the notes for an instrument on one track (especially if you use some whacky articulation-switching system, whether it's Articulation Sets or ARTz-n-Stuff). 

But now let's add to the mix a few other ideas, concepts, and variables that need to be considered by composers configuring a template...

1. *Efficiency (Ha!) *
This applies to the lone wolf composer, the one without staff and in-house techs or people to do take-downs and mockups for them...

There's this much-discussed notion on forums of composers working "efficiently". Ha! That's the jabber of amateurs and hobbyists. Reality check: there is no such thing as a "composer working efficiently" other than to learn over time how to write quickly. This means learning how to recognize early on when an idea just isn't working and to abandon it without regret, to accept that everything you write isn't absolutely precious, that ideas are a dime a dozen.

It also means being able to conform to changes quickly when a client gives you notes _within reason. _This implies, of course, that some clients can be outrageously unreasonable with their requests.

It absolutely does not mean having every single conceivable sound at your disposal, resulting in a template of hundreds of tracks. That's not even remotely "efficient". More on this below.

2. *Computahs... *
There is the very reasonable idea that you want to make the most of your computer. But realizing that means realizing that you can't pack 10 pounds of _shi_... sand into a 1 pound bag. For example...

If someone's trying to do full blown orchestral realizations on a laptop computer with one screen, limited hard drive space and RAM, and a mandate to minimize their computer's footprint for cosmetic reasons... well, that's going to take huge amounts of time configuring to make it work -- if it'll work at all! Every system has its technical limitations.  And that brings me to:

3. *Economics*
There are two components: hard cash, and, "the price of time". Hard cash buys you the most powerful computer you can afford (perhaps even two or three), tons of RAM and SSD's, multiple screens. OTOH, less cash means the price of your time plummets to fractions of pennies on the dollar as you try and configure a (theoretically) powerful system into what little you have to work with.

4. *The False Economy*
This is all about spending waaaay too much time configuring a system so that you have every single possible sound at your disposal, with multiple outputs and processing and -- dare I say it -- a lot of other totally unnecessary stuff like EQ's and compression on every single channel.

Add to that the idea that you must_ (!!) _minimize the number of VEPro instances, or believe you have to strictly adhere to various other protocols for composing orchestral music in a DAW likely means you'll spend way more time trying to build this system than doing any actual composing. 

5. *VEPro*
Despite what they say in their documentation, there is no downside to running lots and lots of Instances. If you start to exceed 100 Instances, well, _maybe_ you need to change your approach. Or maybe_ not._ Either way, I'd like to clear the table of the idea that running only a few Instances is somehow better than running many. It's just not. 

That said, maybe there's an important workflow reason why someone wants to use fewer Instance than more. Fair enough!  But that's when even the best-intentioned advice starts to dissolve, when it encounters the greatest variable of all:

6. *Personal Preference *
Much of what I said above might go right out the window if someone's absolutely driven to work a certain way. But that brings us back to #3 (Economics) and #4 (The False Economy).


----------



## MarcusMaximus (Nov 1, 2018)

Right. A lot here to digest.

Thanks Dewdman. The track doubling I am referring to is simply the need to use aux tracks for the returning audio alongside the midi tracks containing the Event Unit plugin. Exactly what procreative was referring to earlier in post #42. It's no big deal but does involve extra clutter, and maybe processing too. You are suggesting that the extra aux tracks shouldn't be a problem though in that regard. Ok.

The buffer setting could be changed as needed for different scenarios like recording or mixing, just like we can do in Logic, no big deal there either.

Page 59, gotcha!

I imagine I need to keep the 16 channels for a single instrument's articulations because I am using SkiSwitcher (now ARTzID). Not sure that would work so well if several instruments were spread across the 16 channels. So I don't think I can limit the number of instances by putting more instruments into each one.

Anyway, the discussion is perhaps becoming moot, because of what you have written here Peter. Highly informative, thank you and no, you're not going to get any argument from me! 

I certainly don't need that many pre-loaded sounds. In fact I've worked for years on an as-needed basis, my template consisting of everything set up but with no samples actually loaded. I might change that now that I have a slave PC but I would still keep it fairly conservative, probably only loading a limited number of stock patches.

The overall hardware system is now good enough for my needs I think though time will tell as I work with it of course. And you're right, I've already spent too much time configuring and thinking about best configuration practice. Time to get back to the music, well as soon as I get the time to actually finalise the template that is. I have another job you see so don't get to spend as much time with all this as I would ideally like. Another thing I might 're-configure' one of these days but that's another story entirely! 

Your point number 5 really says it all, which is why the discussion about alternatives such as Event Unit and multiport solutions is probably moot at this stage. Others have said it before but you've made it crystal clear: there's no real downside to running multiple instances. Right, I get it! I'll just have to live with sorting through the instances to view what I need to at any given time but given I do most if not all of my processing and mixing in Logic anyway, that shouldn't be too much of a problem. It's just that if there was an easy and efficient alternative to multiple instances then from the perspective of navigation that would be preferable. No more than that really, especially if as you say running many instances does not cause any problems. They really ought to clarify that (and a lot more imo) in their manual, especially when it's for VEPro beginners like me!

Many thanks again for sharing your excellent spiel! Much appreciated.


----------



## Dewdman42 (Nov 1, 2018)

another thing to consider is that you can potentially have humongous VEP instances with thousands of channels of instruments pre loaded in VEP and decoupled. Then in Logic, just create a track, decide which instance you want to connect to or which midi channel, etc.. You don't need the Logic template to be huge ahead of time. Just create the tracks adhoc as you go, but if its all preloaded in VEP, then that ad-hoc process could be very quick. You could create Logic Patches that load very quick because the samples are already preloaded in a known instance and midi channel over on the VEP server.

There is another thread recently where they are talking about this with regards to Reaper templates I think, they called the concept a "schema" based approach...for lack of a better word...but it might be another way to set things up so that you can get to the sounds you want to try out quickly, without having to mess around with ginormous LPX templates.


----------



## Dewdman42 (Nov 1, 2018)

procreative said:


> Now obviously I can address these using either ArtzID or Articulation Sets, but I surely would need to set each track to Midi "All"? I cannot see a way to set up a track to only output to a set of channels, for example 1+2, or 1-3 etc. Is there a way to do this?



I don't think I 100% understand your question or point, but putting all discussions about articulations aside for a moment...

In terms of a multi... You can have multiple tracks feeding a single instrument. Each track can either be set to _send out_ from the sequencer all its midi events on one single midi channel, or it can be set to ALL, in which case the channel encoded in that actual events (as viewed in event list viewer) will be sent out.

By "send out" I mean they leave the track/sequencer area and go on to feed either a mixer channel or else an environment object...and the midi channels can be transformed in either place however you want before being forwarded on to the actual instrument, or over to VEP. So you could do elaborate things in the environment to cause instruments to rechannelize things in whatever way you're wanting to do, which isn't completely clear to me right now..or you could do it in scripter.

what exactly were you hoping to accomplish? Still not clear me.


----------



## Peter Schwartz (Nov 1, 2018)

Dewdman42 said:


> another thing to consider is that you can potentially have humongous VEP instances with thousands of channels of instruments pre loaded in VEP and decoupled. Then in Logic, just create a track, decide which instance you want to connect to or which midi channel, etc.. You don't need the Logic template to be huge ahead of time. Just create the tracks adhoc as you go, but if its all preloaded in VEP, then that ad-hoc process could be very quick. You could create Logic Patches that load very quick because the samples are already preloaded in a known instance and midi channel over on the VEP server.



This is like music to my ears. 

Here's an idea... save your VEPro-based Logic instruments in which the VEPro plugin is "coupled" (my term for when decouple is off). Starting with a completely blank VEPro Server, recall one of these Logic patches. Logic will then force the creation of the entire VEPro Instance! The trick is to then remember to "decouple" the VEPro plugin so that when you save the project (or when Logic autosaves it) that it's not saving the "bloat" of all that VEPro data.


----------



## Dewdman42 (Nov 1, 2018)

Well if you think about it, the whole notion of a “template” is that you believe you have some collection of stuff that doesn’t change much and makes the basis of multiple projects. That is exactly where the vep decoupling mechanism makes sense to use. Where it doesn’t make sense is if you tend to have every project so different from the next that you need all that instrument data to load with each seperate LPX project. But you probably wouldn’t use any kind of template for that either.


----------



## Peter Schwartz (Nov 1, 2018)

You're preaching to the choir again LOL!

The belief you mentioned is exactly that, and it can manifest itself as a template that has an unwieldy number of instruments in it. The idea of saving "coupled" VEPro-based Logic patches speaks to what you said above about loading instruments on an ad hoc basis. For example, it's rare that I ever use piccolo trumpet, so it doesn't load with my template. But it lives as a Logic patch ready to be loaded if the piccolo trumpet muse strikes me. Load time: about 4 seconds. I can wait. 

I correspond with composers on a very regular basis about their setups, and you'd be amazed at the variety of approaches they take. Just today I spoke to a composer from France at length about this stuff. He wants to import Sibelius arrangements into Logic and articulate each parts one at a time. That means loading (say) his Berlin Violins 1 patch into the violin 1 track and articulating it from beginning to end. Then he'll move on to loading the patch for Violins 2 and repeat the process. He just has no interest in having everything loaded at once. And he's also very much into purging samples that aren't needed.

Then there's a name-brand Hollywood composer I work with regularly who used to have 2 PC slaves. He's since abandoned that approach and hosts all of his instruments directly in Logic. His template takes 1.5 minutes to load and he doesn't mind waiting. He also runs at a 512 buffer size and doesn't mind the latency. Go figure, right?

Your definition of "template" is perfect. It's the belief part that's a problem LOL!

Cheers,

Peter


----------



## Dewdman42 (Nov 1, 2018)

Well I do think there can be a time and place for one. I don’t have one yet. It’s overwhelming to think about making. I watch junkie xl and I think I want a setup like that too! I don’t have a big vep slave yet but if I did it would be all about having all the common instruments that i tend to use a lot, ready and waiting. Not only orch stuff but drum sets, contemporary sounds, synths and even non sample librarles. Decoupled and ready. It’s one of the main reasons I bought vep. It’s not only about load times it’s also about having easy access to browse the incredibly large collection of instruments I have and quickly try them. Having it setup so that everything is always in the same place. Actually typical orchestra work is pretty predictable, but when you start talking about all the other stuff it is just a nice dream to have it all waiting to play with on demand. Virtually speaking as if they were all hardware units sitting in my studio turned on and feeding a mixer, ready to play on demand. I think an orchestrator is different because it’s more predictable and limited. Yea you have numerous different libraries covering similar ground but after a while you kind of know which ones work for certain kind of orch sound and you don’t really need to be able to peruse for it, so to speak. And you will have your Goto orch setups that you will just get on with it. A small template could be ok for that.

But the catch here is that it doesn’t really make sense to have a buzzillion tracks in a logic template when you’re only going to record midi on 10% of those tracks. But I do think it could make sense to have a buzzillion channels loaded up in vep. However figuring out how to organize those is not that straightforward. I don’t want a buzzillion vep instances. Only one instrument channel at a time can use an existing vep instance. So some thought needs to go into how to organize vep instances with a buzzillion sounds but not a buzzllion instances and able to easily create those logic tracks adhoc to actually browse around auditioning sounds and then eventually choosing one to record midi events to a track with.

I think multis and even multiport still makes some sense in logic for that browsing around task, not that logic needs a bunch of precreated tracks, but simply in order to reduce the number of vep instances. And for the actual browsing task muliport macro or AU3 would work perfectly fine.

But when it’s time to record tracks and handle articulations and what not, then it may be preferable to avoid multis and especially multi port. But if you set it up for the above browsing nirvana then you’re kinda committed to at least some level of multis


----------



## samphony (Nov 2, 2018)

In regards to logic and vep and everything loaded I like the idea best where logic as a template has all fundamental tracks/ channel strips and routing in place, empty so startup time takes only a couple of seconds to load. In vep everything is loaded decoupled. If I need a patch of ark 1 or css I just select a track and load that patch in logic which connects to vep within seconds. 

That way a a project doesn’t get unwieldy and only stuff that is necessary, lives within that project. 

It’s crazy how colorfully different template approaches are it’s very inspiring to see and learn how others work. It also depends on the projects we do and if you work with multiple DAWs other than logic it gets even more involved. 

And still there is the dream of some to have everything inside the DAW no vep or other software involved with a computer so fast and powerful that browsing and loading is fast as the blink of an eye.


----------



## procreative (Nov 2, 2018)

Dewdman42 said:


> I don't think I 100% understand your question or point, but putting all discussions about articulations aside for a moment...
> 
> In terms of a multi... You can have multiple tracks feeding a single instrument. Each track can either be set to _send out_ from the sequencer all its midi events on one single midi channel, or it can be set to ALL, in which case the channel encoded in that actual events (as viewed in event list viewer) will be sent out.
> 
> ...



What I am saying is that where a library has one keyswitch patch per instrument, using Multitimbral instances is easy. You can simply create one VEP instance with a Kontakt Multi Output and create a Multi with each instrument separated by Midi Channel.

But what if the library has multiple patches per instrument. Some examples, most of the OT stuff has a less featured Legato in their KS patch, so to get full functionality its better to load a single Legato patch in addition. Symphony Series Brass needs multiple KS patches to access articulations as they have split them.

So the only way I can think of doing that is to program the Articulation Sets to address midi channels.

As my example:

Violin 1 KS Channel 1
Violin 1 Legato Channel 2
Violin 2 KS Channel 3
Violin 2 Legato Channel 4
Viola KS Channel 5
Viola Legato Channel 6
Cello KS Channel 7
Cello Legato Channel 8

But then auditioning sounds without encoding articulations will be tricky?

Is there a way to "limit" a track to only output on set midi channels?


----------



## MarcusMaximus (Nov 2, 2018)

I've always preferred to have everything set up in my Logic template except no samples pre-loaded. This was my approach pre-VEPro. The template loads in seconds this way and I've never particularly minded waiting for the patches to load that I choose on an as-needed basis. And that was before I had an SSD! Of course waiting for the larger legato string patches was a bit of a pain but no big deal really.

As I said before I'll probably change this now that I'm using a slave/VEPro/SSD based system but I want to keep everything else pretty much as it was in terms of the actual Logic template. Interesting what you guys are saying about the possibilities of creating Logic patches that set instances up automatically, making use of Decouple, various sized VEPro templates that have libraries pre-loaded and available but kept 'off-line' so to speak until needed, and so on. I do need to get my head around exactly what Preserve, Decouple etc. involve as I'm a little unclear about their precise usage but I'm sure I'll make more sense of them with practice.


----------



## Dewdman42 (Nov 2, 2018)

procreative said:


> What I am saying is that where a library has one keyswitch patch per instrument, using Multitimbral instances is easy. You can simply create one VEP instance with a Kontakt Multi Output and create a Multi with each instrument separated by Midi Channel.
> 
> But what if the library has multiple patches per instrument. Some examples, most of the OT stuff has a less featured Legato in their KS patch, so to get full functionality its better to load a single Legato patch in addition. Symphony Series Brass needs multiple KS patches to access articulations as they have split them.
> 
> ...



so its the auditioning part you find tricky? I mean for example, if the goal is one track per inst, like a score page...then in the example given you need one track for 1st violins. And that one track needs to feed two VI's. It feeds "Violin 2 KS" and Violin 1 Legato....each one on a different midi channel...and articulation switching being used to direct the output of the track to the right instrument... So far so good right?

But when you're auditioning, you're right, the track is set to some "source" channel, either 1 or 2 most likely. Then the state of the articulation set and/or environment or Scripter stuff would determine which one you're auditioning when you play through the track. 

I'm still missing the problem I guess...


----------



## Peter Schwartz (Nov 3, 2018)

@MarcusMaximus

Real quick... Preserve is nothing much to even bother talking about. The important one is *Decouple*. This determines what kind of information Logic saves about your VEPro instruments, as explained below. It's only confusing because of Vienna's poorly chosen terminology.

Note that decouple can be enabled or disabled individually for each VEPro plugin in your Logic project. Chances are, though, that you'll want to set all VEPro plugins to decouple on or decouple off, not a mixture of both.

*Decouple = ON* means that when you save a Logic project, the VEPro plugin for an instrument is only going to remember the  name of the Instance it's connecting to, and the IP address of the VEPro server it lives in. That's it, just the name and address.

EXAMPLE: You have a Logic project with just one instrument, contrabassoon. Your lone VEPro plugin connects to an Instance called "The Rumbler", and the decouple button is *ON*. When you save this Logic project, the only information saved about VEPro is "The Rumbler" and the IP address of the VEPro Server (127.0.0.1 or whatever).

When you reload the project, as long as an Instance called "The Rumbler" exists in the VEPro server at that same IP address, Logic will connect to it.

End of story.

*Decouple = OFF*. When you save a Logic project, and the decouple button is off for an instrument, Logic will download the entire definition of the VEPro Instance it's connected to and save it as part of the Logic project file.

This is the only way to make a complete, single file save of a Logic project that includes all of the information about your VEPro setup.

EXAMPLE: You just built a new template in VEPro with 25 instruments, but you haven't saved the VEPro server setup as its own file. Your Logic project is connecting to all 25 of those instruments, and decouple = *OFF* for all of them.

When you save your Logic project you'll probably find that it takes longer than usual. That's because Logic is saving all of the data that defines each Instance you've connected to: the Instance name, the plugins you've loaded into it, the patches they use, the mixer settings, and so on.

And then...

The power goes out. 

Damn, you never actually saved the VEPro server setup on its own. But that's OK. When the power comes back on, launch VEPro and then load your Logic project. As it loads, all of the data for each Instance (and all of the plugins, etc. etc. etc.) is _uploaded_ from Logic to VEPro, forcing the creation of each individual Instance.


----------



## Ashermusic (Nov 3, 2018)

AND in. my experience, work decoupled. When coupled, your Logic project gets bogged down and slower and more subject to project corruption. If you feel you absolutely _must_ couple, decouple while working, then couple just before quitting Logic.


----------



## Dewdman42 (Nov 3, 2018)

I just had a situation the other day where the coupling between logic and vep got corrupted causing the vep windows to behave all whacked out and unusable. No matter how many times I tried to restart and reload the logic project the vep windows would be scrambled and unusable. Finally i decoupled and saved the vep project and reloaded it. Worked perfectly after that.

Moral of the story, what ash said is true, coupling with logic is able to get corrupted enough, and even saved that way with the logic project, to cause vep to have problems. My thoughts are that frame files have been around longer and more solid code inside and the coupling mechanism still needs some work.

Regarding the name “decoupled” that is confusing to many, I think vsl blew that by giving it a double negative. You have to turn *de*-coupling *off* to get coupling behavior.


----------



## MarcusMaximus (Nov 3, 2018)

Thanks Peter for that clear explanation. I'm also relieved to hear that I'm not the only one who finds the terminology in the manual difficult. It's probably a language thing but I also find it confusing when they interchange certain important terms. Makes it unclear what they're referring to at times. Also the double negative thing you refer to Dewdman.

In fact I had griped about this in my last post but decided to edit it out because I didn't want to be complaining about something I presumed everyone else found straight-forward and simple to understand! 

So in your Decouple - On example above Peter, if the power went off after I had saved the Logic project as in the 2nd example but I hadn't also saved the VEPro Server project separately, I'd lose everything that was set up there, i.e. plugins and patches loaded etc. On re-loading the Logic project it would remember what to look for and where to look for it but it would not be able to recall any other aspects of the instance, providing the relevant instance was present in the first place. I'd have to set everything up there again. Have I got that right?

If so then it would seem to make more sense to work with Decouple off, i.e. coupled, as it seems much more straight-forward to simply save everything in the one go, as part of the Logic project. I save and backup at frequent intervals having had enough experiences of losing valuable work if something goes wrong.

So it's great to get that heads-up Jay as I'd never have thought that would be the best approach. I suppose experience counts for everything.


----------



## MarcusMaximus (Nov 3, 2018)

On a side note given the language issue, is there an 'alternative' VEPro manual, tutorial or video series or whatever anywhere that gives a better explanation and guide to using it? Must check this out myself but if anyone knows of anything it would be great to hear about it.


----------



## Heinigoldstein (Nov 3, 2018)

Ashermusic said:


> AND in. my experience, work decoupled. When coupled, your Logic project gets bogged down and slower and more subject to project corruption. If you feel you absolutely _must_ couple, decouple while working, then couple just before quitting Logic.


I can confirm this. I tried it for a while and went back to work decoupled again. The coupled projects very often seem to behave weird after a while. 
I even stoped importing tracks from coupled templates I created, because I've the impression, even this makes a project weak and unstable.


----------



## Dewdman42 (Nov 3, 2018)

Personally I think it can still make sense to work in coupled mode. I do think VSL needs to work out some bugs with that. But here is why it can make sense.

De-coupled mode makes sense when you are using a VEP setup that is very generic and intended to use across multiple different music projects. This can make sense, for example, if you're working on a film and intend to basically use the same orchestra setup for every cue. Same instruments, with the same presets loaded into every channel, same MIRPRO panning and reverb settings across all the cues, etc. Basically if you change ANYTHING in the VEP instances, including any plugin parameters or faders or pans or anything...then assume those changes will be reflected across all the cues of the project. 

However if you change anything about the VEP instance setups, including which plugins are loaded, which presets of those plugins are loaded, even what the knob settings are within each plugin..unless you automate those things using Logic automation, then anything you change inside VEP that is specific to one logic project you're working on...means you will basically have to save both the logic project as well as the corresponding VEP project at all stages as you go.

The beauty of coupled mode is that all of those configurations within VEP are saved with the Logic Project, just like any other plugin that is hosted in Logic. tweak away, it will be saved with the Logic project and will always play back as its supposed to. 

Using a VEP template to start out makes sense, but whether or not you use it de-coupled really depends on just how much you are customizing it for each musical project. If you're customizing it a lot, then I submit you'd be better off working in coupled mode...(ignoring the bugs that have been mentioned that hopefully VSL will eventually fix).

So coupled mode, in my view can still be advantageous. Now if you are the kind of person that basically uses the same VEP setup every time and never changes anything inside VEP at all, leaves it pristine and generic, doing all project-specific things using Logic...then de-coupled mode will make more sense.

Or you could just work de-coupled and make sure you always save both the logic project and the corresponding VEP project at every point in time you need to, which is obviously more cumbersome, but has the advantage of avoiding the aforementioned bugs in coupled mode.


----------



## Saxer (Nov 3, 2018)

In coupled mode Logic songs (including 10 backup files) rise easily over a GB even in smaller templates. That happens without VEPro too (just by loading a bunch of filled Kontakt's) so the decoupled mode is a good reason for me to use VEPro at all! It keeps the song files slim. For safety reasons I save one coupled version to backup the template but for working it's wise to decouple.


----------



## MarcusMaximus (Nov 3, 2018)

All makes sense and thanks for the confirmations and suggestions. My use of instruments tends to change across projects, not too radically but enough to mean that I will probably need to make use of coupled for saving, at least at the end of a session. Either that or save on both sides regularly, which will be cumbersome indeed! I don't mind the file sizes so much but would obviously mind if Logic projects became slow, glitchy or at worst corrupted because of coupling. What does seem clear is it's best to actually work decoupled, whatever about saving procedures.


----------



## MarcusMaximus (Nov 3, 2018)

I just tried this out. One instance set up with several flute articulations, decoupled. Saved Logic and VEPro projects separately and then deleted the instance from the server. When I re-loaded the Logic project it re-loaded the instance but with no sounds. Re-loaded the VEPro project and it loaded all the sounds. Same behaviour when I quit both apps entirely first. So Logic actually loaded and connected to the instance even though it wasn't present in the server at the time. A minor detail but worth noting perhaps.


----------



## Peter Schwartz (Nov 3, 2018)

@MarcusMaximus, you're discovering the wily ways of this crazy scheme. And pretty much everything there is to say about it has been said above. I'll just take a stab at summarizing...

1) Always work with decouple on, and save your Logic projects and VEPro Server setups separately.

2) At some point mid-project and/or at the end of a project, you might want to consider making a safety copy of your Logic project that contains all the VEPro data too. To do this, temporarily turn OFF decouple for all plugins and save the Logic project under a new name that includes the word "coupled" This fits in with my scheme of referring to decoupled-on as "decoupled", and decoupled-off as "coupled".

You can later search for "coupled" in the Finder to easily view any and all such safety copies of your projects.


----------



## ptram (Nov 3, 2018)

Does cleaning up the Logic project, from time to time, decrease the size of the project file and make things smoother?

Paolo


----------



## Peter Schwartz (Nov 3, 2018)

I'd say yes. You can use the function shown below to purge Logic projects of backups. Not only does performing this function decrease the overall file size, but sometimes doing this makes a project run more smoothly. DISCLAIMER: the part about running more smoothly is _totally _digital voodoo. I don't know that there's any real "science" behind it, but it's a long-standing observation.


----------



## Peter Schwartz (Nov 3, 2018)




----------



## Ashermusic (Nov 3, 2018)

Dewdman42 said:


> Personally I think it can still make sense to work in coupled mode. I do think VSL needs to work out some bugs with that. But here is why it can make sense.
> 
> 
> The beauty of coupled mode is that all of those configurations within VEP are saved with the Logic Project, just like any other plugin that is hosted in Logic. tweak away, it will be saved with the Logic project and will always play back as its supposed to.
> ...



Again, you can turn off coupling while you do your work, then re-couple and save when you are stopping.

And NOTHING "makes sense" if in the real world it does not work well, no matter how advantageous it is in theory. And, again in my experience, working coupled frequently leads to problems.

But people can do as they like as I am not the workflow police


----------



## MarcusMaximus (Nov 3, 2018)

Thanks Peter for the summing up and the helpful tips.

In the middle of working my way through the ARTzID manuals and setup. Excellent stuff. Might have a question or two at some stage. Will drop you a quick email if that’s the case.

Love the doll. Did you make him yourself?! I just finished watching Mandy so I’m in a kinda dark voodoo-ish mood right now. Far out movie with an amazing score. Poor Johan..

That's solid advice and very clear Jay. Will definitely work decoupled and save according to Peter’s suggestions.

So great to hear from people with real-world experience. Much appreciated.


----------



## stonzthro (Nov 3, 2018)

Do what Peter suggests - in fact, I have all 3 checked and clean my projects regularly.
Also, Jay's observation is echoed here as well - I see no reason NOT to work this way. Working coupled is a pain.
To each his own.


----------



## MarcusMaximus (Nov 3, 2018)

Will do. Yes, another great tip, something which I’ve neglected to do previously. I’ve not faired too badly in terms of projects generally behaving well but anything that can help keep things running smoothly is definitely worth doing.


----------

