Thanks for your response and support emails. I am pleased that you have been able to repeat and verify that there is an issue with the backwards compatibility of the iLok version of Vienna Instruments on my Mac system. I also appreciate and greatly value the apology that you express. These forms of communication go a long way towards fostering teamwork and positivity. 
  My understanding is that I must wait for a fix from VSL, and continue using the eLicenser based libraries. I will hold on updating any systems (including OS)  that may affect eLicense functionality in the hope that I can once again resume full compatibility when your fix is release.
  Thank you.

Hi

I have tried moving to the iLok version of Vienna Instruments Pro, on my Mac Pro under Monterrey. After the install, done with Vienna Assistant, previously created project tracks that contained patches loaded into Vienna Instruments Pro 2, now load BLANK. 

I have experienced the same error attempting to load previously created VST Instrument Presets also. BLANK. (This is in Nuendo 12). I am not interested in Vienna Presets - this is not my issue. My instruments settings are saved by VST Presets, or track archives or projects.

I tried rolling back to 2.5.18664 (the last version I believe before iLok) and the presets and project tracks now load again as originally saved out. So at least I am not insane. 

Yes, I have updated the directory manager. Yes I am online. Yes I have updated my iLok and activated the relevant licenses. Yes I have taken this to support - and they say "weird enough, VI Pro indeed opened empty here as well. This is the first time I see such behaviour myself here on my system...".

This is as far as support have gotten with this case. They offer no solution or even hope of one. They have had two weeks with it. I share here to discover if I am alone in this problem, and ask if anyone else is having this issue?

As a test, to see if the issue is that my VST Presets or Projects were created on really old versions of VI Pro, I created a new Project track with 2.5.18664, saved this, then rolled forwards to iLok using Vienna Assistant and this, too, loads BLANK. 

Also for the avoidance of doubt, I tested the whole of the above on a totally brand new (Silicon) Apple laptop. No dice.

Needless to say, iLok and the transition to it is a complete non-starter for me. I am currently rolled back to 2.5.18664 and not feeling any too pleased with VSL, where I have spent a small fortune over the years. I frequently must revert to opening legacy projects as my clients often request remixes of tracks going back some time. This is called backwards compatibility and it is a difficult area for us modern composers - affecting how we approach archiving and loading our old work. Vienna Symphonic Library, for me  at least, has added to the stress of this with their iLok transition, as it has proven to be non backwards compatible. 

I am in fact contemplating employing an assistant to, under the E-License install, load up EVERY SINGLE cue that I have created in the last 5 years, stem all the VSL tracks out as individual audio tracks, and let go of the VSL platform once and for all. 

Ben Bartlett 

Fine.

The license is now deleted and I await a refund.

Ben

This is my system:

Brand-new Mac pro 24 core.

Built-in solid state drive as part of the original machine build by Apple, 8 TB formatted APFS.

Sample drive: OWC excelsior for N2, on a PCIe card, 8 TB solid state, formatted as a soft raid HFS+ journaled.

This machine is screamingly fast. I wouldn’t go near a fusion drive in my music studio!

As my network accesses the internet from behind a DHCP server, I have no firewall and use no port mapping. No gaming or anything else is installed on the pure music work machine.


It feels like you are not facing the reality, that your software has got some major problem. Perhaps it’s Catalina?
Perhaps it’s the presence of an APFS drive on the system, that the installer is using in the background?
Seems like the users that are reporting this problem, have modern macs. Most modern macs have APFS drives.

Just my two cents.

Hi

Same problem here on a Mac HFS+ formatted drive on a 2020 macPro. This machine is doing NOTHING else and I am stuck at 1% for hours. I am running Catalina, which I suspected immediately. But after reading these various posts it is clearly trouble at the VSL end. 

This installer is CLEARLY broken and needs an update. 

If it doesn't install overnight I will be getting refund for this library. I bought it as an experiment to see if VSL has developed - what a disappointment. 

FYI this computer can write to disk at 6000MB a second. It has 24 cores. This install of about 120GB of data should be very very fast.

Ben 

Ok, understandable. Thanks for the reply.

From my persepctive I must also now obtain another physical slave for my assistant. 

I know this is not your fault, but the issue of liscensing across the whole industry is annoying - and the result of a few malicious people who want things for free. 

Maybe a special "side user liscense" that would release the whole machine - for a reasonable cost or based upon the libraries installed, might be a useful solution. This would obviate the need for me to obtain another physical machine. It's not just VSL libraries that are being run here. Kontakt allows more than one instal per liscense, but tops out at a certain point.

So for example, for a fee of £xxx, my slave would look for an eLiscense that says - "this machine can serve 2 hosts". The fee could bebased (or the key could limit the machine) to a certain number of libraries.

Just a thought.

Thanks

Why has VSL created this new limit? The ability to work two stations to one slave has been incredibly useful when using an assistant on a very complex project. 

My way of doing this is not some clever way to avoid getting legitimate liscenses by the way. This is a team effort working on single cues, passing the work from one station to another. Various other music sources are networked too in this environment.

Is there any possibilty that VSL could re-instate the ability to serve more than one host?

B

Hi

I am just wondering if anyone has ever attempted to connect their slaves over a network FASTER than 1Gb? For example 2Gb or 10Gb?

Would this be an advantage with latency? It ought to be possible to upgrade the machines to run faster Ethernet, but I am wondering what threshold of strain (ie how heavy a use of track counts etc) might warrent it?

Thanks

Can I get this straight:

With this version can I no longer run origihnal VI instances? Would a project containing VI (original) instances now NOT load?

Thanks

See this thread at the Steinberg Cubase forum:

http://www.steinberg.net/forum/viewtopic.php?f=19&t=20516

I'd read that it was CPU hogging. That was the main thing. And also I prefer to upgrade one thing at a time!

I'm on VI Pro 2 now. So water under the bridge...

B

As I explained, there's quite a difference. For one thing, it would be possible to be at risk of creating a feedback loop, as it would be possible to send to VSL from a channel that is receiving from the same VSL channel.

For another, you need to place the VSL Input plug in a group. Fine, so one simply sends from any given channel to that group to send to the FX. Just like an FX channel. But, the return MUST come through a VST channel. One could then mute this and send it pre-fader to another group, which would be the return. But if you then solo a channel that is sending, the send group will be correctly solo protected, but the return would not. 

It is a mess. But reading the posts above, it does make sense that the real point of the Plugin was to bring MIR into the picture. The mess is really a by product of that situation.

I would like to add my own encouragement and recommendation to VSL that they look at the audio engineering market.

One bright poster above as pointed out that there is a jungle of plugin formats right now. For example, in Cubendo, it is not possible to run ANY Waves plugins under 64 bit, as the bridge does not work. In fact, it was for running Waves that I explored the VEPro 5 plugin, as an FX solution.

For now, I will use my tried and tested solution, which is to run Vienna Ensemble Pro (non server) with audio hard wired, set up as external FX in Nuendo. This really does work well. Indeed. A networked version of this would be very very attractive indeed.

VSL, are you tempted?

B

Hi

Although the audio input plugin in VE Pro 5 is great, it could be a whole lot better. My workflow in Nuendo is organised in such a way that I want FX audio to return to my FX return track classes. This is not possible, as VEPro 5 must return all audio to an instrument track. Which basically ruins the whole point of using VEPro 5 to serve up FX.

IT's messy. The send will be sitting on one instrument track (or an FX track) but the return is coming back as an instrument. This makes soloing with FX not really work, and my mixer is just, well, ugly. If you solo a track sending to the plug, the return gets soloed too. Yes I could solo protect, but I have various mixer windows divided by track class. This does not suit.

One could do a workaround and setup a group with the send on prefader, and another group with the return, etc etc. But again not great. And there is no way to get audio to feed into an FX track in Nuendo. It MUST come from an insert within the track architecture itself.

What we need is for the Audio Input Plugin to be able to RECEIVE the audio back from the VEPro5 server. Obviously this would be quite a major bit of programming on VEPRo5, with the requirement for VEPro 5 to target it's audio output selectively to the Audio Input Plugin in the DAW. But in effect, the Audio Input PLugin needs to work properly as an insert. Inserts must provide a return to work within the way DAWs are designed. As it is, the Audio Input Plug is a pretty bizarre thing really. Why would one use it this way?

I have no idea if my request is posisble, but it would be the only way for this to work for me. I can imagine a new track class type in VEPro5, which would allow an input (from the DAW via the Audio Input Plug as we have now) AND an output back to the plug (using up a pair from the outputs available perhaps). This return would probably have to be classed separately within VEPro.

This way you would (in Nuendo/Cubase) therefore create an FX track, and instatiate the Audio Input Plugin as an insert on that FX track. Voila.

VEPro 5.1 maybe?

Thanks.

After installing VE Pro5, I could not get VE Pro 5 to recognize VI Pro 1. The shortcut was missing too at the bottom. I read that this was a common problem and one should re-install VIPro2. But no one is talking about VIPro 1, only VIPro 2.

I've now installed VIPro 2 and it is recognised. But, if I want to stick with VIPro 1, can I run this in VEPRo 5? Can I de-install VIPro 2 and go back to VIPro 1 leaving VEPro 5 installed?

Thanks

B

PPC is great for "legacy" software that can't run elegantly any other way. I run on my PPC:

The Grand 2 by Steinberg (I just have a a particular liking fo this piano set)

VE Pro 4 Server 32 hosting Kontakt 3, in turn hosting NI LX Piano through Guitar Rig 3 (you can't run GR 3 any other way without hogging the life out of an Intel machine (YMMV) and GR 4 does NOT load GR 3 sounds correctly).

Spectrasonics Trilogy often gets an airing on my PPC too. I have done this via Kore Player hardwired, and not tried this through VE Pro.

But yes, forget running anything that NEEDS K4 and up (eg Spitfire).

I have also used it as an external effects rack, running Altiverb etc. Or one could consider using it for Powercore, if you have it, to presever THAT particular piece of "legacyware". Whether or not plugs work via VE Pro is anybodies guess, but I have tested Powercore this way and the few plugs I tried DID work.

I have also run VI on the PPC too. It used to be my woodwind deck. But a little pointless now with the power of the newer Macs.

Don't sell that PPC. You will get £100 and then regret it immediately.

B

It's still a great original post though!

How about a "gateway" Application on the main DAW machine. I am not a programmer so I am guessing here, but it would seem possible to run a VSL type mixer on the main DAW, that is receiving all the audio from all the various slaves on the network. This "VSL Mixer Ap" would then slave to the sequencer running on the DAW, perhaps as a locally connected server.

In effect, this "VSL Mixer Ap" would hijack all the ethernet streams being received by the DAW machine, and create a submix. It would host pugins etc etc. Perhaps this "VSL Mixer AP" could be running on one of the slaves? 

The point is, professional users like myself and the original poster, are spending much too much time "hunting around our slaves" to work out what is what. At the same time, maintaining templates so that a whole bunch of sequencer projects can be loaded quickly. The ability to have a "mixer" up and running all the time would be amazing.

In fact, it crosses my mind to try this approach dusing another copy of Nuendo or something on a machine, and spit the submix to my DAW via ADAT or something. Worth trying out at least to see if the work flow makes sense. I know I am tired of hunting.....

Hi

A large VE Pro slave project can very quickly become rather unweildy to manage. One ends up with basically a long list of very similarly coloured tracks down the left hand side. It would be great if we could have a way to organise all these tracks into folders perhaps.

Thx

Hmm, but I have found that the power of the slave can impose another "ceiling" to low latency. Or "floor" I should say. 

What I mean is, I have disovered that a fully loaded slave will exhibit much more CPU usage as you take latency down on the DAW, to the point where it can't cope. So the slave needs to be at least as powerful as would be required to catch up with the network demand for processed audio to be fed back. 

But yes - Thunderbolt has got to be a good thing, although at the moment it's all daisy chaining and no hubs. A far as I know.

B

DG: Yes you are right - and I seem to have jumped on the update rather prematurely too! Not my usual approach with updates...

I am in a dialogue with Audioease now so am "at the coalface" for a bit. And backing up to VE Pro 4 for a while linger until I have some downtime.

By the way - I would be very interested in your views on this topic:

http://community.vsl.co.at/forums/t/29669.aspx

I know you have answered on it, but it's whether we can really pin down the best approach to the MIDI port vs Instances question. You seem pretty versed on it in general...

Best

Ben

Hi again

I seem to be a lone voice here. Anyway:

I upgraded to VE Pro 5 to test if Alitiverb 7 really will load Altiverb 6 projects in the version of VE Pro 5 that Audioease apparently beta tested.

Well, it does NOT work. VE Pro 5 will put up an error when it fails to find AV 6 (even though AV 7 is now installed).

This is all quite game changing stuff if you have legacy projects or templates that use Altiverb 6 that oner MUST be able to load up for whatever reason. I know I know - Audioease is a clear competitor of VSL, but this is the name of the game with hosting 3rd party plugins.

Can VSL and Audioease please get their heads together on this one? It's VERY tricky for a user to beta test this, as once you have installed AV 7, your license to AV 6 is revoked on iLok and replaced with AV 7 license. So creating clean AV 6 test projects to test AV 7 is really not fun.

Also, if I instantiate a new Altiverb 7 insert effect on a channel in VE Pro 5 (non LAN version at 32 bit) all is fine. If I try and delete that instance, VE Pro 5 suddenly quits with no warning. Odd. VE Pro 5 doesn't seem ready, at least not in my setup. Rolling back to 4. It could be that AV 7 is not ready, but I don't have time to work this out. (It does not quit VE Pro 4 BTW).

I will send my troublesome project to Audioease.

If they can't get it to work I will send it to VSL.

Thanks for reading.

Hi

On first launch, the plugin validation process can easily get stuck when a non-authorised plugin is scanned. It is often the case when relegating machines to slave work that 3rd party plugins may remain installed even though their authorisation devices may have migrated to another machine.

Basically I must force quit VE Pro5 (32 bit) if I can not authorise a plugin. Even adding the necessary 3rd part dongle and predssing retry does not work. In fact, Vienna Suite was a case in point. The slavde in question does not require it, and yet VS is installed due to the machine's previous usage. And I don't think we should be expected to create a clean OS just for VE Pro 5 to be aboe to initialise.

Please can VE Pro have a more effective "escape" routine so that no authorised plugins can be passed over at the first launch.

B

Hi

You may be aware Audioease have now released Altiverb 7. Unusually, the install OVERWRITES Altiverb 6 in the plugins directories, for all formats.

(AV 7 now installs under Lion. There is also a new release of AV 6 that is Lion compatible at install too, before you jump to 7 for that single reason).

Audioease state on their website that projects that load up an AV 6 will automatically load up AV 7 and sound exactly the same. Well this is true on Nuendo (Mac) at least. I have tested an old project and AV 7 does indeed load into the Plugin slot where AV 6 was previously loading.

Unfortunately, VE Pro standalone (32 bit) does NOT do this. Despite the surprise that AV 7 (vst) magically slots in with Nuendo (and Protools I have read) this magic is not working in VE Pro.

Is this a VE Pro issue? Or an Altiverb issue?

Has anyone found that their AU version of AV 7 upgrade is behaving correctly? I cannot test this outside of VE Pro as I do not run Logic.

I will send a ticket to Audioease in the meantime.

Thanks

Ben

EDIT UPDATE:

Audioease support have answered my ticket. They say that their beta testing was with VE Pro 5, which is supported - meaning that AV 7 will transparently replace AV 6 in VE Pro 5 projects. (I have not tested this - still on VE Pro 4). They will investigate my case as it was not what they were expecting, so we will see if it is a one off on my system or not in due course.

Hi

The answer of how best to distribute all the instruments we need across multiple instances is still eluding me. Here is the dilemma as I understand it:

On the one hand, I am hearing that TOO MANY instances of VE PRo (on slaves and plug-in interfaces) can slow things down.

On the other hand, I am hearing that too many MIDI ports (VST 3) can also slow things down, especially loading with Cubendo.

Ok. What is the best approach?

My current setup (which I realize may be a little weak on the slave side of things) is as follows:

Mac ONE 10.6.8 on Brand New hexacore (Main DAW running Nuendo 5 via RME PCIe MADI)

Mac TWO 10.6.8 on 2008 Dual Quad Core 2.8 GHz (24 GB Ram) Slave

Mac THREE 10.6.8 on 2008 Dual Quad Core 3.0 GHz (12 GB Ram) Slave

Networking via independent Ethernet network separate from internet/screen-sharing.

I am definitely realizing that I should have pushed my money onto a 12 core slave, rather than the hexacore (which I recently slotted in as my main DAW) but the main point is, to get the best from THIS SETUP, should I:

A: have approximately 8-16 instances of VE PRo with a minimal number of MIDI ports (say 1 or 2) per instance

or

B: have just two instances of VE PRo (one for each slave) with about 4-6 ports available in each instance.

The maths is:

1 port/instance multiplied by say 10 instances = 10x16=160 MIDI channels.

OR

5 ports/instance multiplies by 2 = 2x5x16=160 MIDI channels.

The mileage will obviously vary (I do not tend to create massive templates, rather they build up as a project evolves, leaving me creatively free of baggage) but my general experience is that I need around 10 sets of 16 channels to be covered.

Creatively, and workflow wise, I prefer lots of modular, smaller instances. But I am hesitating to do this because of "what I heard" about having too many instances.

Added to this mix of tips and balances, is the number of audio channels to "permit" on the system. This really relates to the number of MIDI channels, kind of, from a milage point of view again. But, is this also a key player in performance? At present I allow 32 stereo pairs per instance, but rarely go beyond about 24 pairs in actual use.

Going for the "granular" approach (ie more instances with less ports/instance) I could pull that down to probably 16 stereo pairs or even 8 pairs per instance.  mean, how much mixing do we really want to be burdened with? 

Knowledgeable readers please advise. From experience if possible!

Thanks for reading

Ben

On this subject, can we PLEASE have VI Pro open instruments in their originally designed mode of MONO not POLYPHONIC. This is the major problem when loading up VI (old) setups. The legato prgramming for old projects assumes that the instruments are monophonc. In fact I still want them monophonic!

Actually, the ability to remotely control the poly/mono mode of VI instances would be really really useful too. I have requested this before,

Thanks for reading

B

You can still get phasing issues if you're not carefull, when manufacturing a Vln II. Then thing is, Violin II is not just different players, it's different fiddles too. Different instruments and bows. Even moving the microphones and recording everything again is not enough to create that 2nd section.

I think we are all agreeing really. If VSL come up with "Dimension Strings" or something similar, as a whole new product to swat off the competition, and if that included Vlns II then I, for one would happy. It's kinda what I was saying eralier - we need a new strings library, and it must have some basic features.

For me Vln II is one of those basic features. Divisi is another. 

I am not aware of any library that has a genuine Vln II (please correct me anyone) including LASS. The Vln II in LASS is made by "cleverly EQ'ing the firsts to avoid phasing problems" from the manual (not verbatim). To me that is a weakness of LASS - the ensemble feels empty somehow. A strength of LASS is an immediacy of sound, a sense that there is a session in front of you. But this could well be because of the (slightly complicated-to-use) divisi feature. VSL, however, can sometimes get a little "wall of sound ish" if that makes sense. Both Orch and Apass strings get a bit "blocky" when you build up the arrangement. Don't get me wrong - LASS is inferior for sure, on balance. No question. 

The best and most beautiful string library in my opinion is the Chamber Strings of VSL. Really precise progamming and bags of experience have gone into this library and it shows. It would be great to get this quality but perhaps at the scale of the (rather aging now) Ortchestral Strings library.

I hope VSL are reading this little thread....

Best

Ben