I’m digging this post back up because I’m still having this problem. I never used to have to tell the VEPro plugin what the network address is and name of the instance is on either of the remote computers. It used to just appear under the local host as an option. This is with the latest version of VEPro 6. Wondering a few things: if this issue is a known thing, if it’s resolved in VEPro 7, and if my 5,1 12-Core Mac Pro slave computer running High Sierra is going to take a performance hit if I move to VEPro 7.

(I’m not running any new network software - nothing has changed there on any machine I use, though if I think about it, I have installed the latest security update to the OS. But though the firewall is on, the VEPro software is allowed, and is set on the slave computer to advertise its presence on the network.)

Paul, any thoughts?

Hello folks -

I'm looking to avoid bringing my slave 5,1 Mac Pro 12-Core up to Mojave spec by buying a Metal-capable video card - I don't even use a screen with it, as it's accessed via screen sharing - so I'm wondering if anyone is using Mojave on their main computer (in my case a 2013 Mac Pro) and High Sierra on a slave, and successfully using VEPro 7 on both.  Or is this just asking for trouble?

Both computers are on High Sierra currently.

I’m against improvement? Not so. I’m just unwilling to do it in a way that is only marginally better than what can already be done (in a cumbersome way, yes, as I have previously mentioned). I am for improvement, but we don’t think of it in the same way, that’s all. Good luck to you.

I see you really like the slots idea. Great. Just saying it’s nothing new, and too close to what you can already do to be compelling.

If that’s all you want, that’s cool. But is there some reason you wouldn’t want more functionality that didn’t involve, say, twenty slightly different MIDI processes in slots when it could be done more elegantly with a more object-oriented system?

A single-slot-only solution is extremely limited. Much more versatile if, rather than a single MIDI process addressing a single instrument, instruments were objects that could be addressed collectively if desired. There are already lots of ways to transpose, delay, arpeggiate and so on, and simply putting a plug-in before an instrument can be done in virtually every sequencer on the market. And I have done this kind of thing with Logic scripts, OrangeTree Mind Control, TransMIDIfier and just plain after-the-fact MIDI editing. What I’m describing here is something that is not being done in any plug-in host, or using any single solution, or in anything resembling an elegant way. But intelligent articulation time alignment is a basic need that’s not going away. Until it’s all modeled in real time, we will need to deal with samples that can think ahead. But while we are at it, there are other things we can do - if we change the metaphor from mixing board to network, we can do a lot more, in elegant and intuitive ways. Doesn’t mean you have to - but everyone doesn’t have to do it your way. If the system is flexible enough it should accommodate whatever metaphor the user wants. Maybe asking a lot of this software, but these are the people who built special rooms just to record orchestras in. They can make big moves to get big results.

Maybe a starting place for them would be using the model of the Vienna Instrument or Synchron player- except that each cell would actually be able to be pointed at any MIDI destination in VEPro.

Almost.  The issue is that when using a legato articulation, the first note is just like any sustain patch.  No delay required.  When an overlapping note is played, it triggers the legato transition, and it's this delay that must be addressed and compensated for.  So the script has to look for an overlap - a note-on before the previous note-on's note-off - and then do the script.  That's why it either has to be done in the sequencer, where the sequencer could read MIDI ahead, interpret articulations and overlap, and offset playback per note accordingly - OR... in a script in a host like VEPro, there's an overall delay to all notes, but for legato overlaps the delay is less.  So, say 1000ms for everything but if an overlap occurs the note-on delay is only 900ms if a fingered legato, 500ms if portamento, and so on.  So the offset for this script would be advancing 1000ms.  And this would obviously be a playback-only thing - useless and annoying for realtime performances, but great for output from Dorico or step entry or what have you.

And one wouldn't be able to do all the fun things I was describing before (and also enjoy life) if one had to put a script on every instrument.  It would be better to have a folder with all of your targets for a given combination patch inside it, or just the ability to target any instrument that's loaded in RAM in one of these combined patches.

Lots of these things can be done if you don't mind fifty steps.  It's just that we have these machines in front of us that can think like this all day long.  And I know I can figure out what average legato transition delays are - but I'd like it if the manufacturers would do that for me.  (One does.)

If that plugin included scripting that would be amazing.  I'd love to have legato offset scripts in there, though that might be done best in a sequencer host - not sure if a host could successfully report delay compensation to a sequencer, given the amount of time involved, on the order of hundreds of milliseconds as opposed to samples.  But I would settle for TransMIDIfier-style routing of incoming MIDI data.

Hi - getting ready to install VEPro 7, and just wishing (perhaps too soon) for a few things, prefaced of course by "maybe it's just me":

I would love the ability to put a bunch of instruments in a folder, and be able to put some MIDI rules out ahead of the folder, controllable by keyswitches or CC, that would allow me to create a single-channel (to the sequencer) meta-instrument for all of the combining and layering that I do, but with controller-, note-range-, velocity-range- and transposition-modifying for each instrument, and perhaps the transposition-modifying could be constrained by a scale, and maybe even one that follows a key change map.  So one could, for instance, use a string library's sections, spread out across whatever range one chooses, but on the keyswitch for short staccato, add in the VSL Chamber shorts as well, with their volume controllable separately, and at a high velocity on that articulation add in brass shorts from Metropolis Ark - and because this could be following the scale pattern you have entered in, on one or two fingers you could harmonize a line very rapidly.   

(I know one can do a lot of this already, but we don't all only use VSL libraries, do we? And wouldn't we rather program a host than program variations on a basic patch for twenty different instruments?)

The reason I suggest this is because it seems to me that hosts ought to do this kind of thing - facilitate combination of libraries and add flexibility to them by modifying what they do with MIDI data.  I don't know if that would make it impossible to render faster than realtime, but if it didn't then why not have these features?

Just thinking about it.

Pro Tools HDX, version 18.12.0.37, Synchron 1.1.1497, VEPro 6.0.17226. Mac OS 10.13.6. 12-Core nMP with 64 GB RAM, Samsung 970Pro SSD on a Lycom PCIe card for library.

So I was recently writing some trailery music and wanted to use the lovely Yamaha CFX. Immediately had weird dropouts - the CPU meter in the player matched them perfectly with peaks - and I noticed that on other attempts when using bits of the new Synchron Epic Orchestra in VEPro that I had the same dropouts, but that they were not metering in VEPro - only in ProTools. On further experimentation I found that the dropouts were vastly reduced or eliminated when ProTools was playing (transport running), but were not affected by changes in buffer sizes in ProTools, changing the number of cores allocated to the Synchron player or VEPro, or reducing the number of mic positions used. Subsequent tests in Logic Pro showed no problems playing any of the instruments whether in play or not and at much lower buffer sizes. This indicates to me that there is an issue in how PT handles these instruments. Thoughts?

Richard F.W. Davis

Wow - can I try it with VEP7 too? :D

As it turns out, it started showing the server address again - I tried manually entering it, but it didn’t work - but what did work was dropping the cursor in that field and waiting a moment - and then the local host appeared above it and the server address appeared on its own. Some kind of appearance bug maybe. Anyway, back to work.

OS X 10.13.6, VEPro 6.012766, PT2018, Logic Pro 10.4.4, Cubase 9.5, eLicencer control 6.11.6.1247.

After a recent hellscape while trying to audition MIR fraught with sysopos and other errors, I finally got through that by updating from an elicenser I'd been using since 2006.  (13 years of dragging a piece of plastic around the world is not bad at all, really.)  Now VEPro launches without a problem.  Yay!  Except now, every time I launch the plugin in any application, and have the server app going, the plugin can't see any server instances available - not even to make a new one.  And then when I try to quit the audio app that's hosting VEPro, it crashes, no matter which one it is.  I have uninstalled and reinstalled all the VSL apps, to no effect.

Any thoughts, anyone?  This is running VEPro on the same machine.

Hello folks -

Runnng Cubase 9.5 and the most recent update of VEPro. The remote computer is a 12-core Mac 5,1. Both it and the 6,1 master Mac are running High Sierra .6. Buffer size in the plugin is 2. Sound hardware for this experiment is an Apollo twin duo. Using screen sharing to control the remote Mac.

I have a template of SWAM strings on the slave, duplicating the sections in an orchestra (for example, the violins I is made of 8 SWAM violins with placement and delays). I’ve used this same template with Pro Tools controlling it.

When I was setting Cubase up to push it, I made my MIDI tracks that were pointed at the ensemble plugin on the master computer, then connected the plugin instance to its target on the network. Loaded Violin I no problem. Then went to connect Violin II, and that worked. When I attempted to connect Viola, I got a lovely loud buffer buzz, and the connection worked for a moment, but then VEPro crashed. Since then I have not been able to get more than one instance connected without VEPro quitting.

Anyone else run into this?

 

It says it does.  You have to use a script that talks to matrices.  Haven't updated yet.

Your first problem could be a heat-related RAM issue.

You could use a utility to see (when it's reporting less RAM than you have) how big it thinks the RAM sticks are in each slot. Failing that you could pull all but one chip and wait to see if it fails, and go through this process with each chip. You didn't say the size of your chips - is it three 8's or 6 4's?

Hi folks -

The other day I decided to try MIDIOverLAN to enhance my rig a bit.  The goal is to sequence with all articulations of Hollywood Strings or Brass for a given section on one track, controlling articulation selection with keyswitches using TransMIDIfier.  Since I have PLAY instruments quarantined on a slave machine due to their almost hilarious memory allocation scheme, the idea is that I could send a single track output from ProTools 12 to MIDIOverLAN and have that feed TransMIDIfier on the slave machine, which uses keyswitches or program changes to reroute the incoming MIDI to internal MIDIOverLAN ports that push External MIDI ins on VEPro and thus the PLAY libraries hosted therein.

I know External MIDI is a sort of "experimental" thing with VEPro, but I'm wondering if there is any information about how much worse the MIDI latency is when using external MIDI than when using the internal VEPro network MIDI.  

I've always gotten great results from VEPro's embedded MIDI and am only using externals out of necessity.  Using externals means that there's no offline bounce, which is a major drag (though not anyone's fault, of course, that's just how things work).  See my earlier post regarding expanding VEPro Functionality about a potential future way around all of this nonsense.  In any event, were I able to use MIDIOverLAN in a sufficiently low-latency mode it would allow me to build massive patches spanning multiple machines (for instance, I have huge one- and two-fingered patches that layer string, brass or wind sections, but would like to build meta-patches that control all sections on different slave computers simultaneously).

 

Thanks -

Richard

Hi Paul - 

I'm glad you're hearing this.  I realize that I'm essentially asking you to upgrade everyone else's libraries' functionality, and that's a little odd.  But I think that a top-of-the-line host should have more transforming hosting features, and I can't imagine what I'd be doing without VEPro.  Surely cobbling things together with spit and chewing gum.  

What if the instrument matrix simply had hosted instruments as targets as well?  Such that the patch browser also listed available VI's and MIDI channels, and in the Channels column of the main display each channel would have the option of setting a VIPro as a MIDI source?  Not much of an interface change, no internal windows of third-party GUI's or anything.

Just thinking.

I know this has been talked about before, but I'm digging the subject back up to possibly renew interest.

 

Vienna Ensemble Pro solves a lot of problems for me. And it's utterly amazing how it's changed my work flow. The fact that you can do off-line bouncing with it is a huge timesaver and changes the way that I set up my sessions because I don't need to do a lot of bussing to print things.  I recently discovered something that it doesn't do that I really, really wish it did.  

 

One of the libraries that I use is 8Dio's Adagietto.  It sounds really nice and is very expressive. Its main flaw for me at the moment, besides some pitch issues, is that the articulations are generally separated into discrete patches, such that the sustain patches are not key-switchable with staccato patches, for example.  So I ran across this fabulous app called TransMIDIfier, mentioned by many on this forum, which allows very sophisticated internal MIDI patching, routing, filtering, layering and mapping via IAC bus.  It has allowed me to have a single track in Pro Tools for Violins I, for example, that addresses every articulation for that section via keyswitches or program changes, even if they were to span multiple Kontakt instances or VEPro instances.  Great so far.  But when I go to commit a MIDI track offline, I can't because its target is an IAC bus.  

 

So - what I'd love is if VEPro had a sort of Vienna-Instruments-type shell available inside VEPro, in which I could point each cell to a channel of an instrument inside VEPro.  The shell would be a single MIDI channel target that would address any and all instruments loaded into VEPro.  Imagine being able to address all those PLAY articulations any way you wanted to, or EXACTLY like you address the VSL stuff - or build layers of all the string libraries in the ways you use to make the rest of them work - like, say, adding VSL chamber short staccato strings to HS for sharper attacks, only controllable with a CC, and so on.  Or even taking the complex VIPro chord patches further by adding other libraries to them.  These are the kinds of things I do with TransMIDIfier, but I'd love for it to all be inside VEPro so it could happen offline, without IAC, and be platform-independent so I could have the same capabilities in the same way with the same keyswitches should I choose to work in Logic or Cubase or DP or whatever.  Expression maps from the host would still work with these, of course, but could actually be a little "dumber", perhaps.

 

I recall a post earlier where someone suggested TransMIDIfier because they wanted to do keyswitching with VSL instruments, and the reply from Paul (I think) was, essentially, "why would you want to do that, when Vienna Instruments already does all that?"  The answer is, because nobody else does as well as VSL, and I'd like them to be able to.

 

Thoughts?

Never mind - asked and answered. Same version of VEPro is all that's required.

Hi folks -

Is it possible to have a master computer run Yosemite and a slave run El Capitan if they are using the same version of VEPro?

I'm isolating PLAY on the slave and that works great, but I've lost my mind temporarily and want to use an NVMe drive in the slave because of its increased random read performance, and the driver that makes that possible only supports 10.11.

I'm hearing reports that El Cap 10.11.1 fixed the AU validation issue that would prevent PLAY from launching in VEPro, which is why I even consider all of this.

Thoughts?

From an old post of mine:

 dragsquares:



 mosso:

Can I ask why you don't want to use remote access like RDP or VNC? These protocols are well established and stable and there are already good applications out there to make use of them. Maybe if I understood your issue I could offer some solutions.

The thing is, I don't want more software, I want less.  It would be great if I could program the remote instances from the main machine, in the same environment, without changing windows or launching a remote environment.  That's it.  I know about the other solutions, I just don't want to do it that way.

 

Well I guess you're out of luck then.

DG

Not anymore.  :D

The comparison cues are really interesting.  I have a question for Erik - are you using the same articulation types for HS and VSL?  I've always felt VSL to be a little bit more agile in terms of fast things, but there are faster articulations available in HS than may be represented in the comparisons... also, am I wrong or have the files been replaced with newer and perhaps more ambient versions?

As has been said, thanks very much for taking the time to do this!

Also, even though VSL does a bit less in terms of things like modwheel crossfades in the stock library, I don't ever run into things I can't do with it because my system is choking.  And I like my Hollywood sound that I get from it...

I don't mean to appear argumentative, but let me clear up a few points.

First, the last one.  Gold is 16-bit.  Less data throughput.  Easier on a system.  Not the same as Diamond using only one mic position.

Second, the second to last.  I've never run HS on a system with less than 16GB RAM.  That's a good thought, of course.

Third, SSD's are an emerging standard.  But they are not the industry standard yet in our business.  Why?  Not inexpensive enough.  They'll be the standard when nobody's buying platters anymore - or when a library that really (come on, now, it really does) requires SSD actually ships on one and it doesn't increase the price by half or more.  So a library that really doesn't do everything it should without the fastest tech available was a bit of a shock to many people, I think - certainly based on lots of posts here and elsewhere.  Also, I'm guessing there may be a minor misunderstanding here - but within reason, a drive like the OWC top-of-the-line SSD could easily be considered the fastest tech available, standard or not.  Arguably faster and more suitable for sample streaming by virtue of its large numbers of iops than, say, fiber-channel 15k drives.

I suppose what I'm really getting at is this: I could be wrong, but to my memory, before HS was released there wasn't any (or much of any) mention of the fact that to really do a full contemporary arrangement with everything online, that you would really want to spend @$950 on an SSD system - and oddly enough, before Play 3 was released there wasn't any mention of the fact that to get the same functionality as Play 2 in certain instances, that you would have to upgrade your RAM.

Now, I don't have anything against upgrading hardware for software.  I built PC's to run Giga and later VSL.  I remember when MOTU seemed to code for computers that hadn't quite been built yet.  And the price I pay for being an early adopter of EW software and libraries is that I often don't find out until I install the stuff that my system is lacking in some way.  It's not EW's fault if I'm eager and willing to live on the bleeding edge (when I'm not in the middle of a project, anyway).  It is, however, worth noting that the FAQ that was just released is the first document that indicates that Play 3 might require an upgrade - and it was released after the beta cycle and after the product was released.  I don't know why that is, and I don't really care.  Someone else can go there (and has).  

Anyway, just clarifying my position.  

Yes, it sounds good and big, etc.  We all know that, which is why we bought it.  My point is, as far as I can recall, before Diamond came out they didn't say anything about it requiring more hardware to actually work in the way it should - I could be wrong about that, but I kind of expected it to work as well as the other libraries under the same conditions.  Then I was thinking, at least it ships on a drive...but it was a drive they didn't recommend for optimal use.  At the time, although it did a few things that VSL didn't (like crossfading dynamics on legato, for instance) and although it sounded great out of the box, it seemed way less efficient, and I wound up getting Gold as my second license so that I could use it without spending $5k at a minimum for another Mac to play a $1400 library.  (With intonation issues, that takes a bit more work than VSL to get the timing on legato patches right.)  Don't get me wrong - I do really like the way it sounds.  But let's not say it isn't a bit of a pig for resources if it requires the absolute fastest tech available to really do what it's designed to do.  Because that is what a pig is.  A resource hog.  Fortunately, bacon makes everything taste better.