When listing ALL the channels down rhe left hand side in narrow mode - and showing the plugin editor or mixer channel-strip for a selected channel on the right hand side  it would be really useful to have an option to display the channel-strip view for just the selcted channel alongside the plugin editor being viewed. 

In the left-hand single-line view the resize handle simply doesnt seem to do anything on OSX in v7.

Plus i need to be able to view all MIDI channel, port and output audio routings  for each channel too - when in single line. This would be so useful for large instances.

Is it not possible to just add the for an "alias" name that us users can optionally just set ourselves?

Currently it doesnt seem possible to highlight more than one channel and in one operation set all of them to a common MIDI channel or port.

Adding this feature would speed up workflow

In fact a collection of tools to manage multiple selection of channels would be very useful.

For example:

1   - assigning a sequentially increasing range of contiguous MIDI channel numbers to a selection 

2 - reassignign a sequence starting from 1 - 

3 - DELETE - with reassignment channel option  - where a gap in MIDI channel range gets filled in so numbers are still contiguous after one has been deleted.

This is VEP 7   and Cubase 10.30

The Kontakt instrument is Una Corda Piano  ( felt or cotton ) 

In addition I tried to edit the very long parameter string to something shorter in the Cubase inspector - for Smart Controls. BUt for some reason Cubase seems not to remember the rename once i save the cubase project and reopen it.  This is of course a Cubase issue or bug  but just makes it even more important that there's some way in VEP to have custom shorter names - aliases for use in the DAW in order to clearly see which parameter one is automating in the DAW

I set up a bunch of automation parameters from my Kontakt instrument ( Una Corda ) and saw them appear as names in the Cubase Quick Control list in the inspector. 

However the names of all the paremeters as passed from VEP server to VEP client plugin and onto the VST  host (Cubase ) are extremely long and unreadable. 

It would be very helpful if one could create shorter "alias" names for these parameters so that they become readable and managable in the DAW.

In fact some of this could be made automatable -  for example VEP could optionally generate just the parameter names, stripping off the channel name, plugin name, and even ( with a little bit of simple algorithmic string processing code ) remove the end name section - which in the case of Kontakt is the Kontakt Instrument name.

In any case - seems to me there's a big case for adding ability to rename automation parameters in VEP7.

( unless i've missed something in the manual and its already possibe )

This suggestion requires the VEP developers, Steinberg VST3 API developers and NI Kontakt developers all liaise together to agree on the best way to modify the VST3 API and underlying code in order to support what I discuss below:

The new feature is intended to help address the slow speed of communicating COUPLED instance data from VEP plugin to VEP Server in KONTAKT and other plugins which store very large amounts of plugin  saved-state data.

Kontakt has a feature called SNAPSHOTS which allows one to save different parameter settings for things like reverb, effects, volumes etc while leaving data such as sample metadata, KSP scripts and everything to do with the particular Kontakt insrtument “core” datas alone. The amount of data involved in Kontakt snapshots is generally tiny in comparison  with the complete data needed for the Kontakt instrument itself and its sample layer metadata - so to save and recall just this alone would  be significantly faster - arguably near-instant compared the waits for Kontakt to load and initialise the Kontakt instrument saved-state data in its entirety. 

If  an updated version of VST3   incorporated the additional concept of snapshot state-saving and loading - then VST3 plugin hosts like VEP could use this to make saving and restoring small tweaks to plugins hosted in VEP very fast. 

Of course because a single instance of KONTAKT can use more than one KONTAKT instrument in the form of MULTIS. There would have to be support for saving and loading more snapshot data for potentially more than just one “instrument” but this could easily be added to an API by means of an index to indicate “multi-instrument 1, multi-instrument 2 etc etc  

Such an improvement in VST3 would have a huge positive effect on workflow.  The only other major aspect in a VST3 “+” would be to allow the plugin editor panel to be presented on the CLIENT machine - ie in a VEP CLIENT plugin if one could tweak a plugin held on a VEP server as if it were local - instead of having to use VNC or some other remote access software - then again there would be a huge benefit to workflow. 

As well as this - it would allow KOMPLETE KONTROL to be used for plugins hosted in VEP. 

Originally Posted by: civilization 3

You're probably in the VEP Server not connected to a DAW. Kontakt's GUI doesn't fully load unless it's connected.

Ah yes.  that does seem to be the case.  Works now ive connected to a cubase client.

Clearly Kontakt could do with a few dummy audio refresh cycles to update and draw its GUI properly.

 In VEP 7  on OSX High Sierra (16GB RAM )   i'm finding KONTAKT LAYOUR redraw issues in

Action Strings and Emotive Strings. as this shows.    It appears all pages are being drawn over each other at once

I'm having this issue too - on VEP 7 on OSX High Sierra.

In my case it seems to only happen if I launch VEP by double clicking on my default VEP server startup file (.vesp64) which loads my three VEP instances into VEP server - all instances being 100% KONTAKT libraries.

Now here's something that migh provide a clue to a solution:

I gather that VEP is written in JUCE. Several years ago I actually had a C++ project of my own - which was in fact - also a plugin server - and it was written in JUCE. The project has been temporarily shelved but got to 90% - ish  feature complete as far as the main engine guts was concerned but GUI work was unfinished and needed redoing. But I came across a very similar issue I and people here are having whenever my C++  plugin server app was set up to automatically load my KONTAKT instances on bootup.

It resulted me in carrying out months of email discussions with the JUCE developer team - and in the end the issue only got resolved by Julian Storer himself suggesting a solution which when i implemented it solved the problem in my host server app. 

The issue in my case had to do with how the JUCE App went through its startup process and involved a need in the end to introduce a timer delay in order to let the JUCE framework go through its entire initialisation process on bootup for the GUI run loop not to clash with initialisation code and something in KONTAKT that caused this hang. - By means of the timer delay - the actual plugin loading proces only started after that.   I think as i recall that the issue was particular to OSX and thus any solution here would not apply to Windows. ( my code was onlty at this time being developed for OSX ) 

The VEP team might want to contact Julian Storer and mention my name dan stenning - and maybe Jules can point the VEP team in the right direction. Or the VEP dev team can PM me.  

Wow I didnt know that either. Not having owned or used Cubase for aeons. 

But i'm an Ableton user and note that VST3 is in v10.1 in that DAW. 

In away I can live with it - IF in return VST3  supports a robust  preset query API where one just gets lists of preset names - chooses by category etc etc..  

And PC historically  was always problematic.  I remember the days back in the 90s with Performer and all those custom PC patch-list files one needed to get working for modules like the JV2080.  Real headaches. 

Guess its high time for me to look into VST3.   But in any case - the same principle could apply to VST3 providing VEP X supported the preset-protocol. 

thanks for responding.

<So to perhaps put it in simpler terms...a program change sent on any channel to be interpreted by VEP to enable/disable whatever collection of channels you wish that happening to be listening to that channel.  or something like that..  Its an interesting idea..>

Yes.

And more.

So one could  even switch out the audio from one instance to another.  For example a 5 channel setup for string ensembles could have three instances -one for each such library one owns -  each with string sections set up with their violin 1/2's cellos etc - in the same channel order but only one has their audio feeding the client. 

Ideally the whole MIDI PROGRAM CHANGE thing would be able to be hidden though - and instead of all that hassle - the client would just see and select between NAMES. 

If both client and back-end are VEP-owned the whole program-change thing could be hidden and never seen by the user.   And in fact the developers could just decide to use some hidden proprietary protocol to switch multitimbrally.  Only caveat is I always hated ( as im sure people here do ) the whole business of burying PC messages in one's midi tracks as one used to have to do in the 90s  and times of modules like the JV2080

Instead - it would be better for the client VEP plugin to just save the state of whichever instrument/"patch" is being used and selected on the back-end of a track -  save all that in the VST/AU  saved-state data.

I AM aware - that KONTAKT   has an 128 PC Bank mode.

But there are downsides with using that method.

Hopefully Hans Z and Junkie XL can put in a good word and lobby for us on this

Is it not fair to say that this is one major gripe with many of us - the KK thing ? 

:) 

This is a question to both the composers here who - by necessity - use enourmous track-count DAW templates and the developers of VEP. 

My idea would greatly reduce the track-counts needed for master templates - and might even - for *some* (probably more production-oriented)  users eliminate the need for such templates at all..... Although I still do like the idea of a very MINIMAL template.....

What do people here think of an alternate paradigm - whereby plugin instruments hosted in a VEP server were not only accessible via seperate tracks on different MIDI channels -  but also - like the multitimbral sound-modules of the past - via switchable via PROGRAM CHANGE messages? 

So for example if one wants to use a single instance of VEP for all one's favourite basses, and assuming one typically just wants ONE bass ( or -say Grand Piano ) to be playing at any one time -  one has just a single MIDI track and audio input channel - but one can flip between the bass instruments held on VEP simply by sending a PROGRAM CHANGE? ( including bank-info if necessary )  

And what if this applied in a more sophisticated way to orchestral section - so for example - if one ownet three different string section libraries - one just has a bunch of tracks for Violin 1,2 violas, cellos etc. 

But - given that only ONE library is intended to be used at any one time in one's project (not always the case of course )   to simply audition the sound of each string section with - say 5 tracks - one just sends a PC to the VEP instance - which flips between - say a Vienna string section and an Albion or East West section.. 

 This way one wouldnt need N x L  tracks - where  N is the number of tracks required for one's "Section" and L is the number of libraries for such a section one is holding instantiated on the VEP server.  Instead one would just need N tracks. And each of the L libraries gets chosen via MIDI Program/Bank change. 

 Is this a way of working - a modus operandi - that might appeal to some here?  or is the current way of just filtering on tracks out of a vast track count - a perfect workflow for orchestral composers here ?

And ideally one wouldnt actually even need to memorise or use PC numbers becaus the VEP develpers could just give names to all the PC instrument options and display them in user-friendly fashion in the VEP client plugin. 

I have just one question and big hope for Version 7 - having purchased V6 via the pre-release offer.

Will there be anything in V7 ( via collaboration with Native Instruments one hopes ) that makes owners of KOMPLETE KONTROL keyboards be able to use the functionality in that unit and its plugin - with VEP that improves things over how they are now? 

Particulary when VEP is running on  a seperate server? 

Given how much KONTAKT is part of many VEP users lives - Clearly this is a issue that has been of interest and concern both here and on the N.I. Forums.