Vienna Symphonic Library Forum
Forum Statistics

194,444 users have contributed to 42,922 threads and 257,971 posts.

In the past 24 hours, we have 6 new thread(s), 15 new post(s) and 74 new user(s).

  • To use VEP as an FX rack, you use the Audio Input plugin. I don't know what DAW host you're using. But you instantiate the instance of VEP first in order to connect to it via that plugin. It's more involved in Logic than it is in Cubase iirc. 

    Once in VEP, you instantiate the type of Input channel "Input" and connect to it in the dialog from Audio Input (the other type, "Channel" is for sending an output from an instrument channel to an Aux bus type, ie., to process it separately). Now you have [both kinds of] automation you may set up, Host Automation or MIDI, found in separate tabs in the Automation Mapping dialog, which is accessible via F5 or from the View menu.

     

    So the two types are for [mostly] mutually exclusive use cases, the FX rack paradigm, as _not_ an instrument type  is not dealing with note-on or note-off data but will take control data from a MIDI track or event. The other is just an extension of an instrument in VEP. Both, however are automatable exactly the same way.


  • Thank you for the reply Civi-3!
    I should be provide greater detail about my set up and desired result. My DAW is Digital Performer which is on one computer. I have two other computers which run VEP7 as servers. One server hosts virtual instruments and the other server hosts FX. I generally have the virtual instruments running smoothly with MIDI control, the FX server is where I am running into issues. Hosting instruments and using MIDI automation of CC data, and routing audio back to my DAW is no issue.

    My desired outcome is to have 5 instances of VEP7 hosted on a server computer, with FX plugins in each instance that accept both program changes and process audio from my DAW. I can automate CC and parameter changes fine, but I wish to automate snapshot selection in Reaktor FX, and automate presets on my other FX plugins while still maintaining an audio chain from DAW through the server FX and back to my DAW. 

    I can set up the VEP7 instance with an audio bus which allows me to input audio into the plugin, but it will not accept MIDI program changes, or can set up the VEP7 instance as an instrument channel which will accept MIDI program changes, but it will not accept audio. I need a channel strip that will do both. If I were simply setting this rig up for studio recording then the preset automation would not be an issue, but instead I am building a performance rig that requires preset automation. Within DP I have a large number of song sequences installed into chucks. As this is a performance setup, I can then load any chuck on demand without having to load a new project for each song. To save on memory and processing, I loaded all my VEP connections in the virtual rack so that all the chunks share the same virtual instrument connections. If I was hosting the FX plugins within each sequence, then automating presets would not be an issue, but that would take way too much memory and processing considering the number of sequences I am loading all at once, hence the virtual rack which shares the virtual instruments and FX. 

    In the screen shot, you can see I am attempting to use Reaktor as a FX plugin in both an audio bus and an instrument channel within an instance of VEP7. One offers MIDI input but no audio throughput, the other offers audio throughput but no MIDI channelization for preset automation. 

    Image


  • I think probably you can not send both midi and audio to any single channel strip in VePro.  You have to choose either an audio input pair, or an instrument plugin(which will produce audio).  When you choose an instrument than you have the opportunity to specify which midi channel to use for it, but lose the opportunity to select and route any audio.

    I would suggest the work around is to learn how to actually create your own custom parameters in Reaktor, so that you can basically use parameter automation to control whatever it is you want to control inside Reaktor, then you can use parameter automation instead of midi.

    If Reaktor can't support that...(I'm not sure, I think it probably does support it, but just in case it can't), then you could look into something like KushView element, put that in VePro and Reaktor inside that.  Then in Kushview you can create user parameters I believe, which can be mapped to midi.  For sure BlueCatAudio patchworks can do that, but Patchworks has gui problems inside VePro.


  • Thanks for the reply DewDMan, 
    You must be correct in the capabilities of channels in VEP, MIDI input is limited to parameter input through CC only in an audio bus. A work-around may be possible with Reaktor and I have been exploring that. VSL cheerfully touts VEP as an excellent FX rack, but most any hardware FX unit worth its salt would respond to MIDI Program Changes and still be able to process incoming audio. As a result I have been forced to seek other alternatives. 

    Really, who has time during a live performance to open a channel strip in VEP, launch the GUI for a plugin, and search out a preset for the next tune? Automation of presets should be easy, but instead it appears impossible with FX within VEP.


  • To be fair to vsl, very few audio fx plugins respond to Midi of any kind including program change. There are only a handful of so called midi controlled fx which use midi to dynamically control them such as stutteredit by izotope. But even that one probably does not respond to program change for changing presets. Plugins in general also do not respond to program change for changing their preset. The exception to that are a subset of Instrument t Plugins which use key switches such as program change to change sounds within the Instrument. I don’t know of a single daw that provides a way to change the preset of any plugin dynamically during playback with or without midi. Now that being said, I can see where it might be useful in the case of using vepro to host fx, But would just suggest to find various workarounds.

  • Thanks for the insight on plugins and it is true that many do not accept MIDI preset changes. In my system, the ones that do include most of the virtual instruments such as Arturia Analog Lab, Kontakt, Reaktor, Keyscape and Omnisphere. With FX plugins they are certainly harder to find. So as a work around I am exploring the Kushview Element right now. I am wondering how that would work as a plugin within VEP7 because it would still be constrained by the issue of either being on an input bus or an instrument channel. I see that it has excellent routing capabilities in the Graph Window, for both audio and MIDI, but being embedded in an AUDIO bus, would I be able to choose an external MIDI source, or if embedded within an Instrument Channel, how could I bus audio into an input. of an FX plugin? I assume it does not operate in a standalone mode.


  • I’m not sure kushview will help with your particular desire to change presets dynamically. You should ask the author through his GitHub site (create an issue). The entire plugin interface does not really have a way to respond dynamically to preset changes other then through the user selecting one I don’t think. Some plugin hosts that are designed for live playback such as mainstage, gig performer , and a couple others,,,.they provide this but the way they do it is by loading into memory many instances of whatever plugin you’re taking about; each instance with a preloaded preset. Then the plugin host itself responds to program change in order to switch which plugin instance is currently the active one. I don’t know of any host that can do that while also running itself as a plugin within another host such as vepro. Maybe Unify? I don’t use that one so I don’t know. Kushview might be able to cable together something along those lines but I’ve never tried it.

  • First let me say I greatly appreciate your knowledge and help in my quest.

    I had considered Mainstage as a solution. I am running Mac OS Mojave and was thwarted at the Apple App Store when I was prevented from downloading due to my older OS. I looked for a legacy version but could not find any.  The Blue Cat Patchwork also looks promising as I can run it as a standalone version. However moving audio to and fro the DAW computer to the FX server computer via ethernet is another issue. Moving MIDI through ethernet is of course no problem. I am unfortunately not Dante compatible which would be perfect. I am exploring Sonobus right now and perhaps in tandem with Loopback I could move audio into a standalone instance of Blue Cat Patchwork or a legacy version of Mainstage. 

    Thanks again!


  • Apple App Store strikes again..sorry to hear you can't buy MainStage...I would have thought they would let you buy the older version before they updated it to require Catalina...but doesn't surprise me that you can't buy it now unless you go to Catalina.  One thing you can do is find a friend that has Catalina installed on their Mac, log into the App Store from their computer using your Id.  Buy MainStage, then log out.  Then go back to your Mojave machine and you should be able to download the last known version of MainStage that runs on Mojave...  its a little work around.

    Anyway, there is another program you can check out called Gig Performer, which is similar as MainStage, runs on Mac or windows.  Its considerably more expensive though.

    As you pointed out, by going that route you will have to use some combination fo networked midi and audio, which can get expensive...

    I want to say VePro has one huge advantage which is that is handles Plugin Delay compensation and will make sure that if you are playing back a project from a DAW, everything will be sample accurate.  When you go the route of using a "Live" tool like Minstage or Gig Performer..then there is no sample accuracy...but if you're live....there is no sample accuracy anyway; just unavoidable latency.

    Pathchworks could work, I'm not sure if it can respond to Program change or not like that though.  Patchworks has problems running inside VePro, FYI...gui problems.


  • I just checked Kushview and indeed you can setup multiple "graphs".  Each graph is a cabled setup of instruments and/or FX.  And you can use Program Change to switch which graph is activated.  So you could potentially use something like that, but still you have the problem of midi and audio both getting to it in order to do that.  It can also use OSC and other things, so check with the author to find out if your need can be met inside VePro somehow.

    I would do some more experiments out of curiosity, but running out the door shortly.


  • Networking MIDI is no problem as I am already running 5 network MIDI connections (80 MIDI channels) using Audio-MIDI setup in Mac OS. The audio is the problem.

    I was able to use Sonobus to create a stereo audio send and return between the two computers, but I am not sold on the audio quality as of yet. 

    Switching graphs via parameter change in Elements might work. 

    I will keep experimenting.


  • So check this out...(click on attached image).  You can see Kushview hosted inside VePro as an audio FX plugin.  I can bring midi in from IAC (and it supports OSX network midi too).  

    So yes that would let you get both midi and audio into Reaktor that way.

    One thing to watch out for will be the timing because its hard to say when your host will send the relevant midi over network midi, and meanwhile VePro's audio stream is based on a buffers-based audio stream with perhaps significant latency...but Plugin Delay Compensation also happening...meanwhile your midi would be coming over more like realtime.  But anyway its worth a try...

    Image


  • Brilliant! Thanks!  I will try this out for the two instances of Reaktor I have going on in my FX rack.  I think there may only one, possibly two other FX plugin I use that responds to preset changes and they are both NI products that possibly could be embedded within Reaktor.   As you pointed out, many FX plugins do not support preset changes of which I may only wish to include one or two for on stage automation. So in those cases I am wondering if these individual presets could be embedded in a series of graphs that could be called up via MIDI presets.  

    Kushview also reminds me of MAXmsp which was something I was considering as a solution. The learning curve seemed a bit steep so I was holding off. Kushview is less expensive and seems more focused to the task at hand. I am curious if you chose the single subscription or the ongoing $2-$5 subscription for Kushview. 


  • Also, perhaps this might be interesting to you. I will share two images of two V-Racks that I have set up within one instance of Digital Performer on a Mac. I have another instance of DP on another Mac that runs the sequence and sends automation commands to the V-Racks. It is an unconventional setup, but it does seem to work to distribute processing and allow for access to all my virtual synths as well as route MIDI connections and automate FX mixing. 

    Image

    Image


  • I am personally opposed to subscription software so I pay kushview for each one-time Download, which so far updates have happened 2-:3x per year. That being said, I am not yet actually using it that much. If it becomes a critical part of my workflow I would definitely get a subscription. There is a new lua scripting module added recently but not documented yet which I see as being a huge potential for articulation management. I plan to explore that eventually. There are several tools out there that do this graph oriented plugin management inside a plugin: plogue bidule, ddmf, patchwork’s. But all of those have GUI problems inside vepro but somehow kushview element does not have GUI problems inside vepro. Those tools are in the $50-100 range.

  • Pardon, but did you test that IAC connection to see if it passed MIDI into VEP? No matter what I do, I can't seem to get the Kushview IAC Input Device to work inside VEP. I put a MIDI monitor on my IAC port outside VEP and it is working there, but the MIDI Monitor inside VEP shows no MIDI data.  


  • I did not test it. Does the iac port work into kushview when it’s a plugin inside other hosts? I will try it more tonight

  • I have some bad news and some good news.  the bad news is that apparently that particular feature of KushView only works in the standalone version of Kushview....not any of the plugin versions of it.  :-(. I will submit a bug.

    Semi good news. I tested out PlogueBidule, and that works for this purpose in the plugin version, but you have to make sure to use the AU version of PlogueBidule, the VST version crashes VePro a lot.  There might come up other strange GUI bugs, but right now anyway, seems to work fine.

    Unfortunately I am not able to test out your complete desired FX routing because for the life of me I can't figure out how to make the Audio Input plugin work correctly in LogicPro..there is a note in the manual for LogicPro and some work arounds, but I am still not getting it right...no more time to spend on it...but anyway, at least the midi from PlogueBidule works.  Bad news...its about $100 for PlogueBidule.  

    Image


  • Thanks again. I have not bought Bidule yet, but I have read something on their forum that a user was concerned about audio latency inside VEP. I was going to download a trial version but they only offer trials of standalone, and even that is not available presently. 


  • Plogue bidule does not do any automatic plugin delay compensation. It has tools to manually do it. Their excuse is that graphs are too complicated to figure it out automatically. I did ask them once. It’s possible that plogue does not even automatically report the resulting latency of the graph to the host but I haven’t tested that Find out. It does have a lot of tools inside and probably there is a way to manually insert a module that will report the latency that needs to be reported to the host. Then vepro will respond correctly. If not you can always put expert sleepers latency fixer on the same channel strip in vepro where bidule is, and manually report the latency that way which should solve that issue. The main issue I have had with plogue bidule inside vepro is that the vst version sometimes crashes vepro, at least in the past. But the AU version didn’t. Then I occasionally had some weird GUI bugs, which I can’t remember now if they were specifically related to using vepro on a remote slave and ms remote desktop, but anyway I would not buy without a proper demo either. Ask the author and tell him you need to test inside vepro. He kind of does his demos in a weird way. But seems to me you will get more mileage out of tweaking your reaktor setup to use parameter automation instead of midi