Yeah this one's pretty obvious. Mixdown in Cubase parlance means the export process. Nothing is indicated as having been changed with regards to the track changing behavior. And it hasn't.

Unfortunately no change in Cubase 8.5. The known issues document from Steinberg simply states:

7519: Switching between tracks using instruments from Vienna mutes the audio playback for a short moment

Please deactivate ASIO-Guard for these plug-ins using the Plug-in Manager. 

Originally Posted by: dlpmusic

So......if we still can get the benefit of the low CPU and no audio muting that might be good enough.

I didn't really get that out of it, seems like there's no other way except to disable ASIO Guard for VE Pro.

 I really dislike that idea, because with Cubase 8 the performance with all VSTis including VE Pro hosted ones has gone down, and only with ASIO Guard enabled does the whole thing make any sense. So there needs to still be a way to manually enable it for heavy sessions, even if VE Pro will default to disabled.

Originally Posted by: MS

Originally Posted by: dlpmusic

VE PRO VST2 does not support ASIO-Guard 2 you have to disable ASIO GUARD, also VSL has to implement a VST-3 interface that supports ASIO- Guard. 

They have been informed about this. 

The latest VST SDK available for download is 3.6.0, built 22 nov 2013. There is no way to inform the host of ASIO Guard support within this SDK, beyond setting the instrument as an external instrument - which also disables offline bounce. Last I heard, you planned to release such an update last month. If you have any updated information, I would love to take part of it.
 
Thanks,
 

I thought I'd bump this thread since I'm sure many are eager for this fix -- looks like Steinberg has version 3.6.5 up from a few days ago. I couldn't find anything on this topic in the documentation with a quick look, but hopefully it's buried there somewhere. Any news on the issue?

This is kind of strange and used to work fine on Windows 7. My new studio computer has Windows 8.1 and apparently its behavior at assigning taskbar icons is slightly different.

Basically double-clicking an .mframe64 from File Explorer opens VE Pro (5.4.13715 x64) in server mode as expected, but Windows just calls the icon Vienna Ensemble Pro. As is expected, of course, since that's what the EXE is, as server mode is a command line parameter.

However, the problem here is that if I pin that icon to the taskbar, then launching that icon launches VE Pro in non-server mode which I don't want. If I modify the command line of the icon, it becomes the "server icon" again (the duplicate icon actually vanishes if I already have the server icon assigned to the taskbar).

So basically at the moment there's no way to have just one pinned VE Pro icon in the taskbar if I want to achieve two things: 1) be able to launch a fresh VE Pro server application 2) switch to VE Pro that has been launched by double-clicking an .mframe64.

Anyone figured out a way around this in Windows 8.1?

I was just wondering if there's any chance we'd get VST support on the OS X version of VE Pro at some point in the future. One of the things I like most about VE Pro is being able to make heavy sessions a bit more agnostic about whether they run on one or multiple computers based on where I happen to be working, but not being able to load 3rd party plugin instances across Windows and OS X makes it kind of a pain in crossplatform environments. Probably best to just standardize for one platform at the moment, but hopefully this is coming at some point. 

I thought maybe someone here might find this useful. I did a small JS plugin for my own template and perhaps someone else could use it as well. It has a template ready to for VI. Simply create a 8x2 matrix and assign X-axis to CC46 and Y-axis to CC47. Then using the ViennaInstruments.txt articulation map from this plugin will work for you directly. So a note on MIDI channel 2 in the REAPER arrangement will play the articulation at slot 2 on row 1, whereas a note on MIDI channel 11 will play slot 3 on row 2. And so on.

http://stash.reaper.fm/v/18047/articulation_mapper_v0.1.zip

Would it be possible to get a comment from VE Pro developers on whether this is an issue that should be fixed in REAPER (in which case I will file a bug report with Cockos) or if it's something VE Pro will do differently in the future?

The problem is that using a lot of VE Pro instances in a single REAPER session will produce a long delay for starting playback. I have about 30 VE Pro instances and it takes three seconds for the playback to start. An identical comparison session on Cubase starts instantly.

This might be related to another problem: running VE Pro with decouple off will make REAPER entirely unusable, as it stops to wait for the patch information from the slaves almost all the time. Based on this I felt perhaps also the playback problem is due to REAPER causing VE Pro to request data over the network way too often.

Clearly the best solution would be for REAPER to support VST3 (or the earlier reported Event Input problem to be solved) so only a few instances are needed, but I'm trying to look for an immediate solution. And the session works fine otherwise running with all instances decoupled, just the playback start freezes are a problem.

Specs: VE Pro 5 latest build, Win 7 x64 (on slave machines as well), REAPER 4.52

Just to add, it seems disabling Anticipative FX processing under Preferences / Audio / Buffering fixes the latency issue for me. But frankly that feature is one of the best parts of the REAPER audio engine, allowing for much heavier sessions while still keeping latency low for live playing. So hopefully it would be possible to make Event Input play nicely with it.

I can confirm the problem here as well, it's completely unusable. REAPER is making big strides in MIDI and the scripting and development possibilities for it make replicating Cubase-style articulation mapping and other features possible, so I think it's becoming a really interesting platform for orchestral composers. I hope to see VE Pro working on it properly soon.

Certainly the best solution would be for Cockos to implement VST3 for REAPER, but in the meantime it would be important to have the Event Input plugin work properly.

Thanks for the update, glad to know it's fixed already. This is why I keep praising VSL to everyone I know -- the responsiveness to fixing problems is unparalled.

Thanks for the port descriptions, very informative. Both computers here are running build 5436, and the ports should be open, since I don't even have a router in between, just a switch (and for what it's worth, the same happens with a direct link with a crossover cable). And the computers have their firewalls turned off.

However, what is really interesting is that as I mentioned in the other thread, I changed my slave computer name and the instance name to only include letters from "89eiodfghjklcbn", which are the only characters I can input manually in the VST3 client on this build. Of course, I did that so that when the computer doesn't appear in the list, I could input it manually... the only thing is, now it appears every time, so I don't need to!

So, unless I'm having weird luck here, it *could* be the input and discovery bug are related in some way.

I haven't even realized you _can_ edit the hostname or IP address manually, because the field seems to ignore most keyboard input. Activating the field by double-clicking, I notice it accepts some keys though. Going through the number and letter rows the accepted ones are: 89eiodfghjklcbnm.

So, I renamed my slave computer to the majestic name of "eiodfgh" and sure enough, it works: I can connect to it even when it's not listed. Although I also have to limit my instance name to the special letters if I want to be able to connect to it manually as well. A little awkward, although should make for some creative word play (and potentially offensive instance names).

This is only for the VST3 version. The VST2 version doesn't seem to accept any keyboard input.

I'm running build 5436 on two computers. The host computer runs Cubase 5.1.1 in Windows 7 x64 and the slave runs Windows XP. I'm running VE Pro 32-bit Server both locally on the host as well as on the slave.The firewalls are disabled for both.

Most of the time these days when I fire up my session, the plugin in Cubase simply doesn't see the slave computer over the network. Usually this gets fixed by closing all the programs and then starting again. It's frustrating because there doesn't seem to be a pattern to this, and I'm spending a lot of time doing restarting, basically every day.

The weirdest thing is that I can start an empty session in Cubase and then the plugin *will* see the slave, but when I load my full session, it's missing again. It's just really random. Then it suddenly gets fixed when I close everything and start everything up again.

Is there any way to debug this issue further? There doesn't seem to be e.g. a manual way to connect to an IP address from the plugin. I've made sure again and again that the network is fine between the computers and traffic's not getting blocked, so there's something else going on, but it's really hard to tell what.

EDIT: Forgot to mention that the local server appears in the plugin every time. It's simply the other computer that's randomly missing.

So is the VST3 version known to cause disconnection problems? I suppose then that might also apply for OS X.

I'm running Cubase on a MacBook Pro with a local VE Pro instance, with another computer running VE Pro on Windows (gigabit ethernet), and both the local and the networked VE Pro Servers seem to lose connection with the VE Pro plugins in Cubase, especially if I save without enabling decouple first. This seems to correlate with how heavy the VE Pro instances are. If it's just a couple of instruments, no problems. But around 10 things start to get shaky.

I'll try with the VST2 plugin next. Does anyone know whether we actually even get any benefit for using VST3 with VE Pro? I don't know if the VST3 idling functionality is even applicable to basically having an entire host within the plugin (i.e. mostly no idle moments anyway), and I suppose from the user side that's the only reason to be using VST3 right now anyway.

EDIT: Oh of course one big thing with VST3 is you get multiple MIDI ports into VE Pro. That would be kind of a drag to go without.

Wanted to post an update to this. I was looking through the forum and just stumbled on a thread about the Kontakt Memory Server causing some problems. It didn't seem to apply to this particular problem, but I thought I'd give it a go anyway.

And sure enough, looks like no more dropped voices after I disabled KMS! So just in case someone here has the same problem with VE Pro and Kontakt, that's something to try.

I'd like to add my vote for this one, a disconnect function would be great.

I was wondering if this problem still occurs for people here. Searching for it I can find a bunch of threads, but not really any solutions. I'm running VE Pro (4834) with a bunch of Kontakt 3.5 instances on a MacBook Pro 17" (Mid-2009) 8GB, OS X 10.6.2, Fireface 400, Cubase 5.1.1. All the offline bouncing just seems very prone to having notes cut in the middle or just not play at all.

Anyone had success fixing this on any platform or DAW? 

VE Pro is working great here, but there's two issues with Kontakt that seem to recur. Unfortunately I haven't been able to figure out a sure way to reproduce either one, so I'm hoping someone has more input on these.

I'm using VE Pro as a plugin in Cubase 5.1.0 on OS X 10.6.1. Kontakt is version 3.5 as mentioned.

The first problem has to do with the latency compensation. Sometimes when loading up the session, one of the Kontakt instances within VE Pro will have a huge latency and be out of sync with the rest of the instruments in VE Pro. It's about a second late.The problem is fixed by closing the session _and_ closing and restarting the VE Pro Server. If I don't close the server app, and just reload the session, the problem remains, and it'll be the same Kontakt instance every time (I had multiple ones in that session).

But that's unfortunately as far as I got with trying to test that thing. I'll post more if I figure out steps to reproduce it from scratch. Just happens with one of my sessions right now.

Another thing kind of seems like it's entirely a problem within Kontakt, but it doesn't happen to me outside VE Pro, so I'm a bit puzzled. What happens is some of the time, like 30%, when I load a patch in Kontakt, it loads up and receives MIDI according to the indicators, but nothing plays back. Then if I remove the patch and load it again, it works. Again, obviously doesn't sound like a VE Pro problem, but curiously that's never happened to me when using Kontakt in Logic for example. Anyone else have this happen? Seems there's a post about a similar thing with Omnisphere, maybe it's the same thing.