194,143 users have contributed to 42,912 threads and 257,925 posts.
In the past 24 hours, we have 1 new thread(s), 13 new post(s) and 80 new user(s).
@MS said:
I was more thinking about an option which decouples saving/loading. This way, a save could be pretty much instant - all that would be saved in the project would be the preserved session name and the IP address of the server, instead of all data belonging to the VE Pro instance (which in the case of 20 Kontakt instances, can be ALOT of data). I'll see if I can add that for an update.
Thanks, Martin. That's a brilliant idea. I can hardly wait to... [:D]
I'm puzzled whether this is a real problem or not.
Isn't it true that you can, even without VST3, run 16 instances of Kontakt (one for each MIDI channel) inside each instance of VEPro, and then run 8 instances of VEPro?
Therefore even with this 8-sever limitation you can run 16x8 = 128 instances of Kontakt on each PC or MAC.
And then, given that you could run the 64bit server alongside the 32bit server, you could put 64bit Kontakts in the former and 32bit Kontakts in the latter.
And therefore you can actually run 128 x 2 = 256 instances of Kontakt on a single machine, even without VST3.
Isn't that so? Isn't that enough?
The problem with your math dag, is that if you run 16 instances of Kontakt in 1 instance of VEpro, you still only have access to 16 different patches because you still only have 16 midi channels to use per VEPro instance. This is the same as if you only had 1 instance of Kontakt loaded with 16 patches. Either way, you only get 16 patches per VEpro instance.
Then, if you are using a mac, Kontakt does not register as a 64bit plugin, so you are unable to use the 64bit server as well.
In my case, I was running plogue with 16 instances of Kontakt each with 16 patches loaded on a MacPro.
VEPro now limits me to having 8 instances of Kontakt each with 16 patches.
DP and Logic users unfortunately do not have access to VST3.
However, the forums are all a buzz with what doesn't work, and I have to say that this is an absolutely AMAZING piece of software that will single-handedly revolutionize the way large-project-workflow happens. I just can't (as I had dreamed about :) replace my current setup quite yet, but am looking forward to further refinements in VEPro.
@MS said:
Try instantiating 20 Kontakts in your sequencer, and see if you get the same saving speed.
Hi Martin, I have just tested it. With the same 20 Kontakt instances in Cubase the saving speed only takes 5 seconds. I hope this is helpful to you. Thanks a lot for your good work!
Best regards,
Peter
@orchetect said:
If I may, a feature suggestion may help with this (in parallel with an actual fix of course) but this would be a fantastic feature to have... why are external MIDI inputs unavailable to the VEPro Server? Technically it is possible and would not be hard to implement.. it is already implemented in the VEPro stand-alone, why was it taken out of the Server?
Unfortunately, this IS technically impossible with a VE Pro server, since it lives in its own timing universe.
I can understand that, but that usually is only an issue with audio sample rate sync. MIDI seems it could be feasible, even if it was just implemented as an ad-hoc measure and not bound to VEPro's delay compensation framework. I'm trying to find a proof-of-concept. Right now, Bidule crashes VEPro. If that were not the case, the Bidule plugin is able to instantiate external MIDI inputs inside itself and pass it thru. In theory, could this not be used as a temporary workaround? Insert Bidule as a VST "effects" insert on a track inside VEPro and the MIDI would be passed thru to whatever VSTi is on that track? (assuming whatever bugs that are making Bidule crash when loaded are fixed - or if there's another plugin out there that can do this without being a resource hog) Or is the current VEPro coding only making effects inserts process audio and discard MIDI data?@MS said:
Unfortunately, this IS technically impossible with a VE Pro server, since it lives in its own timing universe.
