Playback templates using a multi Player with IVP enabled

[dlb]

I’ve been in discussions about this problem for quite some time and I’ve discovered some new (to me) information. I thought it might be helpful for the team to see this as it may shed some light on the situation.

The problem I am talking about is when using a multi with IVP enabled, playback templates create extra instances of the player (one for each IVP voice in the instrument in question).

It has always baffled me that the factory playback templates work with IVP enabled even though it is loading a multi (HALion Sonic).

I believe this is because the factory templates use playback template generators with default settings and do not use endpoint files to create the playback devices.

If one wants to alter the mixer (e.g., add some EQ or limiters or anything at all and then run the factory template it will just remove all that and load the default playback devices. So, in order to preserve the mixer alterations, one must create a user playback template that saves the endpoints. It’s this user template that does not work with IVP enabled. It will create a new instance for each IVP-enabled voice using HALion Sonic or any other multi (such as VE Pro or Aria player). The problem only exists if the template uses saved endpoints.

Some evidence involving HALion Sonic is shown in the following screenshots. In the first image, the factory template (IVP enabled) was used. This creates a single instance of HALion Sonic and routes both IVP voices to that insance each to a different MIDI channel as expected. In the second image, a user playback template with endpoints saved (IVP enabled) was used. This unexpectedly creates a second instance of HALion Sonic and routes the first IVP voice to the first instance of HALion Sonic and routes the second IVP voice to the second instance. The routing for the user playback template is shown in images 3 and 4.

So to sum up, the algorithm used to build a playback system with the factory templates (that use template generators and do not use saved endpoints) is not executing in the same manner as the algorithm used in the user templates (that use saved endpoints).

Screenshot 1. Factory template used

S

Screenshot 2. User template used

Screenshot 2. First IVP voice routing

Screenshot 4. Second IVP voice routing

[mavros]

Thanks for this interesting investigation. Do you know if we can make a template ourselves like the functioning Halion with VEP instead? This would finally solve or maybe better said offer an elegant work around for this issue which has not been solved since the ivp introduction.

[dlb]

It is possible. It’s not well documented. It’s also not clear how this solves the general problem. With VEPro it’s much more likely that different projects require some modifications in the VEPro mixer. So coming up with a consistent useful playbacktemplategen xml file which serves all needs seems difficult at best.

I actually created one (didn’t finish it) because I wanted to see if I could come up with something useful, Every time I tried I ran into a wall and was looking for a solution that wouldn’t require endpoints to be saved.

[mavros]

The playbacktemplategen.xml file is indeed somewhat puzzling. Even if the mixer would always be the same where to add what in the xml is at least to me not clear.

So I will stay with a Project template instead.

[dlb]

I am not sure how feasible this is. I got as far as creating a playbacktemplategen file and it shows up as a factory template (see image below), and it even initializes the VEPro server. But I never figured out how to add an instance (I suppose one could start out with an instance loaded and connected. As I was thinking about it, I just realized that user templates is the right way to go. There are simply too many possibilities otherwise.

[mavros]

Absolutely project templates seems the only way today. I tried accommodating Dorico providing multiple instances in VEP to connect to but it refuses to connect to them and creates new entries.