Posted
The question came up what might be the best way to run VEP servers with Synfire. Now that containers can be stored in libraries, you will want to make sure that all sounds get restored to VEP instances without manual intervention. I don't know what the most efficient way is, but I can share they way I am currently doing it, just to kick of the discussion.
Running multiple VEP apps on different machines is probably not necessary when your main computer has sufficient resources. I run one empty VEP 7 app in the background on a Mac with 10 CPUs (20 virtual cores) and 48GB RAM. It sits there waiting for VEP plug-ins in Synfire to create new server instances as needed.
In Synfire I have 4 rack module presets for Brass, Strings, Woodwinds and Percussion. Creating a preset goes like this:
- Add a new server instance in the VEP app and populate it with the desired sounds (plug-ins or internal) and setup your default mix there.
- Load a VEP plug-in in a rack module in Synfire and connect it to that new server.
- Edit a fixed-channel device description for that rack module which lists all sounds on their respective channels over there in the VEP server. You can add up to 16 instruments (or instrument sections) per server.
- Save the rack module as a preset.
When you use this rack module in an arrangement, it is also saved along with containers and phrases that you add to a library. When these items are restored, the VEP app will automatically start and restore the server instance as it was last saved and then connect to it.
Synfire takes care of loading rack modules only as needed. If one library item uses a "Flute" and another uses "Oboe", they will both be served by a single "Woodwinds" rack module. However, if you load another arrangement or another library, that will create a separate server instance (just like Sketches, which also load their own rack).
Sat, 2024-04-27 - 10:26 Permalink
Connecting VEP to your local main computer has only one way of connecting as you describe if I look at it this way.
You need to reserve 4 midi ports in Synfire for VEP to enable the 4 instrument groups (Brass, Strings, Woodwinds and Percussion) of 16 midi channels/instruments each.
The 4 rack modules are built via templates and each stored as a preset.
On the VEP server you want all 4 rack modules instruments to be displayed in 1 mixer setup.
Sat, 2024-04-27 - 11:55 Permalink
The following is interesting:
” takes care of loading rack modules only as needed. If one library item uses a "Flute" and another uses "Oboe", they will both be served by a single "Woodwinds" rack module”
Does this mean that if I drag VSL Prime Edition Woodwinds into the arrangement from the preset list twice, it will not create two separate VEPro instances?
Sat, 2024-04-27 - 13:37 Permalink
This setup in synfire to get multiple midi ports from the racks into one mixer on the VEP server succeeded via trial and error I thought. ( a trick )
Need to do it again sometime this setup.
Don't think the developers of VEP thought of to assign every midi port available to a
separate mixer to start assigning?
For few instruments say 6 the separate mixers are still manageable.
Sat, 2024-04-27 - 16:48 Permalink
Made it another setup and can set up a midi port 1 and midi port 2 as racks with 16 midi channels each
This allows 1 mixer setup
So the 4 racks with instruments can be put on midiport 1 to 4 and all instruments on 1 mixer , as I look at it now.
If you have made your own templates you can also put them on midiport 1 with 16 chosen instruments.
Do you know in advance which instruments you want to use in the example of André, then he can compose himself 1 rack (fill) through templates device descriptions and all instruments are on 1 mixer (for midiport 1 )
There is a Vienna ensemble pro device to choose (for midi port 1) and a vienna ensemble pro event device to choose ( for midi ports 2,3,4,... ) for racks
Sat, 2024-04-27 - 18:56 Permalink
Does this mean that if I drag VSL Prime Edition Woodwinds into the arrangement from the preset list twice, it will not create two separate VEPro instances?
Not quite.
If you import a phrase (or multiple in a container), Synfire first looks into the arrangement's rack if the desired sound is already available. If a module with multiple sounds has the desired sound, it will be used (instead of loading the module again). For example, no matter how many VSL Woodwinds you use in a project, the module will only be loaded once the first time one of its sounds is imported.
If you deliberately add a module twice, it will be loaded twice.
Note that you don't need to add anything to your rack in advance. Importing phrases with sounds will automatically load whatever is needed to play them.
Sun, 2024-04-28 - 01:18 Permalink
Hi Andre, I don’t think this works well with the VEPro Event workflow. The VEpro event VSTs allow more than 16 midi channels to be accessed per instance, which provides decent flexibility for orchestral setups and also allows easier routing for FX sends and mixing inside VEPro. The alternative would be for Synfire to have the capability to route to multiple parts of the instance using VEPro’s VST3 multi port capability as with othe DAWs but I don’t think you’ve been able to implement that.
My workaround for now is to create VEPro VST instances in one arrangement or in the global rack, and then set up VE Pro event VSTs for all my instruments that routes to these instances. As long as that original arrangement or the global rack open I can get the set up to work, but the link between the event VSTs and the main instances breaks easily.
Sun, 2024-04-28 - 22:57 Permalink
In order of preference, I think the following would be ideal:
- Being able to have a Synfire device description target the VEPro VST3 plugin instance's ports as well as channels.
- Gave a facility to move or drag drop rack items (such as a VEPro VST3 plugin based rack) from one rack to another rack - i.e. not copy, but actually move so that it doesn't create a new instance on VEPro server.
Mon, 2024-04-29 - 08:05 Permalink
Using more than one VST3 port is certainly doable. Device descriptions already support variants which could be somehow repurposed to be used as VST3 ports.
Sharing sounds between projects is currently the job of the global rack.
Sharing the sounds of one arrangement with others is hairy. Which arrangement would be responsible for saving the last used state? How would other dependent arrangements be updated, if one of them changed something? Keeping track of dependencies between external files is complex and unstable.
That's why every arrangement needs to load and maintain its own sounds and all shared sounds are managed by a global rack.
Mon, 2024-04-29 - 10:10 Permalink
If we could address multiple VEP ports that would be a huge workflow booster.
For now I’m storing VST3s alongside the events that address them in libraries. Just need to be careful not to delete unused modules in the the library rack. As long as I have that library open I can use multiple arrangements with it.
But multi VEP ports would be best!