In Play mode, we have on the right the list of VST instruments that correspond to the playback model. These VSTs appear in the mixer. But when
Logic would have it that the term “erase” and its option would allow to erase. A solution?
Unfortunately you can’t easily shift entries in the rack: your “Soprano” plug-in at entry 10 means that the preceding 8 entries have to exist. The best way to remove them would be to re-apply the playback template, but if you’re setting things up manually, that will require you to perform the manual setup for each plug-in again.
are there any plans to change the way this works for v.4? In practice, it can be actually more annoying than one might think as even when a new instance is automatically added such as when adding new instruments in setup, Dorico can mess around around with previously assigned numbers which means having to redo them if you’re working from a template (such as VEPro).
Hello Daniel. It is indeed unfortunate. In the construction of a VST list, we must be able to correct. We should at least be able to move the vsts in the list and thus be able to lower the empty VSTs down, to delete them.
In the present case, I have several pianos. A piano in the orchestra, but also several pianos which I use to listen to the basis, the diagrams of the composition which will be applied in the arrangement. These latter pianos, I want them all to one VST, because I don’t need a VST piano per instrument in this case. I do not see this possibility on the configuration of the templates, which give me an additional VST for each piano.
Maybe you have a solution for this scenario? I may be working the wrong way. I need 1) my basic score and 2) my orchestral score for arrangement or instrumentation. I am currently using 2 layouts, base and orchestra. And all the tracks of the base must go to a single VST.
In short, no, though we may at least make it possible to hide empty slots.
fair enough, I wasn’t too hopeful as I appreciate that this is far from a trivial task. Hiding empties would help with one part of the problem at least.
I don’t really understand this. If your pianos are different VST’s then obviously you need to create a different instance for each one. If they are not than it depends on what player is used. Is it multi-timbral (like Kontakt, VSL etc)? Perhaps the best solution is to use software like Vienna Ensemble Pro where a number of number of instruments from completely different manufacturers even can be all put together under just one VEPro instance if you prefer.
I write in French at the base, and use the French version of Dorico, so it’s not always easy with the terms.
I use VSL for everything (in this case). The piano is the Boserdorfer Synchon in Vienna. The other instruments are all under VI pro. I have VE pro, but I don’t see why use it here.
In short, I have 5 piano staffs. I want them all towards the same VST. I can do this manually, of course, but I want my reading model to understand it and do it at the opening. For now, he is opening 5 VST of the Boserdorfer Synchon.
I understand it’s not so easy if you’re having to write in English. But if you’re using all VSL you can surely just put 5 channels of your Bösendorfer Synchron into the standard Vienna Ensemble (or fewer if you want to use divisi). That is only one instance of the plug-in. I though the problem is having too many instances of the plug-in?
I think this is part of the issue that some of us have with the whole premise of endpoint configurations. I refer back to this thread from Nov 2020: (Endpoint configurations)
As Paulo pointed out in the above thread, many of us use multiple libraries for the same instrument, but the way the endpoint configurations and playback templates are set up, doesn’t allow for loading of preconfigured sets of vst’s which you would then choose from and assign in PLAY mode. In this way, cmbourget would simply load his piano vst as an endpoint configuration, (not associated with the template as such), and then assign his five pianos to the single vst.
The solution right now is to NOT use the playback template. Use a VEPro vst in the rack, but decouple it. Have one instance of the piano in VEPro and link your piano to it. You will however have to save your VEPro instance and load it up before you load the Dorico project. As long as you are decoupled but connected to the VEPro the last time you saved the project, it should work fine. This is how I work. I have all my sounds loaded into VEPro ahead of loading the Dorico project, as long as it is all decoupled, Dorico will not automatically start loading sounds.
In the above thread, Paul mentioned that the team had not considered this kind of use case before and that they would consider it for the future. I’m hopeful that it is still on the radar for some point in the future so that we can work in an alternate way to the present playback template system.
The problem is that the template, when it sees 5 pianos, prepare 5 instances of VI Pro. I’ll see what I can do with my VE Pro. It is time I knew how to use it in that sense, I guess.
Very well explained. I’m going to go to the side of VE Pro. As I said above, I need to learn this plugin better. I have always organized myself without EVs.
That said, when Dorico (and his template) goes to see 5 pianos, he’s going to open 5 instances sde VE Pro, right?
Update: Ok, you say not to use the playback template. Impossible for me, because I use a model from Articulate-preset (Symphonic Riot). Or I don’t put anything for the piano.
Since Expression Maps are assigned by MIDI channel rather than by VST, having different instrument on different channels (even from different VST’s within VEP) ought to be manageable, no?
well that shouldn’t happen if you use VEPro. @Grainger2001 is right when he suggests to decouple the instances but I tend to leave VEPro open after closing Dorico anyway to eliminate loading time between sessions.
The current implementation of endpoint configurations and how they relate to playback templates is widely regarded as confusing and suboptimal – I would also go along with this to a degree.
I thought Symphonic Riot only write VI templates, not Synchron? I don’t quite see how or why you would use that model in this situation.
Okay, cmbourget,…Using the Symphonic Riot Templates will certainly complicate things a little and I’m not entirely sure exactly how they configure everything. I’m sure it’s possible to ‘reverse engineer’ the Symphonic Riot Playback Template to fit in with the way of working that I described above, but it’s probably quite a lot of fiddling about, and maybe it’s not worth it simply to stop 5 separate pianos from loading.
Maybe putting all the pianos on the same midi channel, saving and rebooting Dorico might work?..Not sure…Maybe the template will still see 5 piano staves and try and load 5 pianos.
I am perplexed about deleting these vst slots though…Sometimes I can delete them using the trash can no problem, and other times they simply won’t delete, even if I’ve selected ‘no vst’ or ‘blank’ in the slot. Maybe Daniel or Paul could explain why that is?
as far as I’m aware, if it’s the last slot, you can delete it and if it’s not you can’t. That’s certainly my experience.
Exactly. That is why we should be able to change the order, as in Cubase (if I remember).
I don’t know. I’ll look, but indeed, it’s faster to adjust the session. It’s still annoying, but we participate in the development of Dorico (which is, it must be said, a wonder in many ways, but a wonder still young).
Is there some advancement on the horizon, for this issue? I’ve now a template with tens of empty VSTi elements, and it doesn’t look good.
Paolo
No, at the moment we don’t have any plans to make any changes here, though I will at some point discuss with Paul and Ulf whether something might be possible, e.g. to remove empty slots when loading a project. If it can be done entirely in Dorico’s data then it should be doable, but if it requires us to also change data in the separate data maintained by the audio engine, it might be a lot trickier.
