Another reason to get some champaigne - and share the anticipation [;)]
Always a good move.
Best,
Paul
Paul Kopf Product Manager VSL
194,472 users have contributed to 42,922 threads and 257,973 posts.
In the past 24 hours, we have 3 new thread(s), 13 new post(s) and 77 new user(s).
I would like the return of the dots in the instruments panning arches.
Is there any particular reason they are not there anymore?
I hope that program change pass-trough will be integrated for the VST3 version. That would be an "out of the ballpark" hit.
I also vote for Program Change pass through to VST3
But here's another big one for me. It seems that overall latency is not passed to the host for correct Plugin Delay Compensation when using insert effects that have a large delay.
For example, load up a cpu intensive plugin with a large delay like a multiband compressor into an insert slot within VE Pro, and hosts like cubase with plugin delay compensation cannot adjust for this additional latency upon playback. This means that this VE Pro track is out of sync with the rest of the project. Is this right? Could you confirm this Martin?
Brett
[edit] thanks to another members question over at Cubendo, it seems that VEP does not even have plugin delay compensation within itself! This means if you have a high latency plugin like a compressor on one track within VEP, it is now out of sync with a second track in VEP. This restricts the sort of plugins you can use within VEP doesn't it. Am I mistaken Martin, or is there a fix coming for this?
@brett said:
But here's another big one for me. It seems that overall latency is not passed to the host for correct Plugin Delay Compensation when using insert effects that have a large delay.
That is correct. If you think a little bit about it - it is not a very trivial task. VE Pro would basically have to report the latency of the "slowest" channel, then internally delay all the other channels - and report back this longest delay to the host. Thus, the playback latency when playing live - would be exactly that of the "slowest" channel. Not very nice imho. This is why we have chosen not to implement it so far.
In VE Pro, I would suggest to use effects which don't introduce such latencies. Vienna Suite is a good match.
@jvdieks said:
a thing that would be nice is a midi controller learn function, like in live.. so you can choose what midi controller does what on each plugin. this would fill the automation gap
Huh? That's been in Vienna Instruments since day 1. Over 4 years now, AFAIK. [;)]
If you are talking about plugs from other developers, then go and hassle them.
DG
- Display of free RAM in the status bar would be very helpful.
- brighter font color of the preset list (now it's black on dark blue)
- Server Window Option: Automatic load a specific metaframe save
- Server Window Option: Automatic minimize to taskbar after opening
@michael_12374 said:
- Display of free RAM in the status bar would be very helpful.
Yes! I just wanted to write about free ram as well. Maybe a used / free display if possible. Could be a pulldown menu or mouse over effect on server or instance window (where CPU usage is). Just display it somewhere besides VI.
The automated minimize and mframe load would be great, too. Anything to reduce clicking things. [:D]
Hi Vienna-Team,
at the moment you can only globally define the number of midi and audio ports for all instances (in the "preferences" in the Server Instances Window)
It would be great if you could define these settings individually for every single instance.
For example I have 8 instances. 7 of them only needs 2 midi port. But the last one needs 32 ports. My only choice is to define 32 midi ports for all instances. And that's a huge waste of resources/performance. Try to open a VSTi with 2 and one with 32 midiports in Cubase. The difference of loading time is enormous.
Best regards,
Peter
I have small wish for the AU pluginGUI: add a scroll bar in the connection selector window. Scrolling with the arrows is quite slow on my setup.
And, if I understand working procedures correctly, it is imperative to disconnect all VE Pros before closing a project. (is this correct? I had bad results when I didn't) It would be great to have a function that disconnects all instances.
@petera said:
It would be great if you could define these settings individually for every single instance.
For example I have 8 instances. 7 of them only needs 2 midi port. But the last one needs 32 ports. My only choice is to define 32 midi ports for all instances. And that's a huge waste of resources/performance. Try to open a VSTi with 2 and one with 32 midiports in Cubase. The difference of loading time is enormous.
This is not obvious how to do and would complicate things quite a bit in terms of setup. It will stay like it is for now.
@MS said:
You don't need to manually disconnect the instances before closing a project, why would you do that?
I'm just guessing/trying to find out what works best. I tried not disconnecting in one project and I now have major bugs which I'm still trying to resolve: Some channels, mostly channels 4 and 8 do not play any more in VE PROs with contact loaded. This happens on 2 slave Macs. VE PRO receives the midi (little indicator blinks) but Kontakt does not seem to receive it. When I play notes on the Kontakt keyboard, the samples play though. It happened with LASS and other kontakt libraries; not with any VSL instruments on the 64 bit server. This behavior remains after shutting everything down and restarting; and using a new Logic project (to rule out a bug with the Logic song). Any insights on this would be a life saver for me right now.