Originally Posted by: Guin

Originally Posted by: Mayyar Namek

Giun: Thank you for your reply, that sounds great! Or isn't it? I'm a beginner, therefore could you please explain what real time playability is and elaborate a bit on that point? Thanks! 

I think it's what Paul Kopf once mentioned as "auto-trills": when using a legato patch, you hold down one note and then trigger and release another. With VI engine, it will perform as trill, or fast notes. With Synchron, it will stop after the second note, because the first one won't recall.

The lack of that feature keeps me on VI Pro as well. I wish they would support that mode in Synchron Player, at least as an option. Most sample players behave the same way VI Pro does, and many electronic keyboardists rely on that feature for performance.

Originally Posted by: PaoloT

I did my tests, and I admit it's an impressive acoustic effect.

Room mics do contain position information, but very much blended with the ambience, much more diffuse and less directional.

Add the mid, or even close mics, and you have the image move towards the spot/medium mics.

Paolo

It's not the phase you need to switch, but you can swap L/R in the power pan of the tree/room mics to complete the effect. I've done this both for second violins and to move Synchron pianos around, with much success.

Originally Posted by: PaoloT

Having to decide what to move away from the SSD drives, if having to re-edit older pieces is not an issue: I guess Dimension Brass and Dimension Sthings are two libraries that have not lost anything when going from VI to SYzd.

Do I remember correctly?

Paolo

That has been my experience, only those two are intact regarding both articulation set and sound.

Originally Posted by: PaoloT

Originally Posted by: Seventh Sam

To be more specific, you have legato, fast legato, expressive (baked in swell) legato, perf. detache, fast perf. detache, long, expressive long, portamento, and expressive portamento.  All of those have three types of vibrato (regular, without, and strong) that can be crossfaded or individually chosen. …

But — aren't these things for the most part also available in Chamber Strings? Can you elaborate on the differences?

Paolo

For me the biggest differences are:

• Wet vs dry - Elite can't get the presence of CS even with only the close mics. CS can be put in any space.
• Elite has a "normalized" system of 3 vibratos and 4 note attacks, i.e. most every combination is present for most of the long articulations.
• Elite has performance detache. This is a huge feature for idiomatic non-legato bowed lines.
• Elite's two solo mics give you the ability to get more "texture" to the ensemble than CS, which is quite tight and uniform.

If anyone wants to try this, and has both DP11 and Synchron Elite Strings, this folder contains slightly re-arranged presets for Synchron Elite Strings (mostly normalizing the treatment of Vibrato, which in the defaults was sometimes a Type but more often its own dimension), as well as an articulation map file for Digital Performer 11 and up. The same articulation map works for all the sections, enabling copy/paste between tracks keeping articulations.

This map has entries only for every combination of Articulation and Type, both of which are driven by keyswitches at the low end of the range. The rest of the dimensions (vib/attack/release etc) are controlled by CCs, velocity or speed.

This yields a manageable list of 42 entries, which works great in the articulation picker menus and UI. By default velocity controls attack type, CC1 controls vibrato type, CC3 controls release type, CC20 controls slot XF and CC2 controls velocity XF. You can easily change which controllers are used in the Control tab of Synchron Player.

Originally Posted by: Dewdman42

Originally Posted by: richhickey

We're definitely crossing our signals here.

apparently still....  sorry but you are just incorrect about cubase.  But I'm tired of this discussion.  Try the things I suggested earlier if you like and my emz program may help you set up Cubase expression maps without combinatorial explosion

But both DP and S1 will suffer from the combinatorial explosion when using Sound Variations.

Sorry to hear that. I enjoy taking with you about these issues since we seem to share many of them. I'm a programmer and can and have written programs like your emz, but I think the need for it highlights the shortcomings of Cubase. When you say "the editor is lame and requires you to retype a lot of sound slot rows to account for all possible combinations in the actual sound slots" you are again highlighting the problem with the expression map architecture itself. Even if you use a program to help you generate it, the map is still one of combination->bunch-of-messages and has no sense of which messages correspond to which values in a particular dimension/group.

But the important thing here is not a "what if?" about Cubase or the Sound Variations API. The Sound Variations API exists, it works the way it does, and it raises the question as to how Synchron Player will interact with it.

I maintain the initial premise that Synchron Player, by naively exposing the multiplicity of all dimensions to the SV API, is creating a combinatorial explosion that does not exist in Synchron Player itself.

At least it seems obviously wrong to send combinations with dimensions assigned to Speed or None, since there are no messages in the SV API that can control them.

To be perfectly clear what I am talking about, here is the articulation picker menu generated by default from Synchron Player for Elite Strings. The image is just the first of 5 pages of menu!

Now here is the entire menu generated from just the Articulation and Type dimensions. Since I use CCs/Velocity/Speed for things like vib/attack/release/agile I don't want them in the sound variation system. That control is what I am asking for.

We're definitely crossing our signals here. What you have been talking about is the UI within the Cubase MIDI editors for indicating which articulation is to be used, where you can orthogonally talk about the directions vs the per note attributes.

I am talking about the expression maps themselves, because that is what gets transferred from VI to DAW via sound variations.

So let's take a single case of something in Synchron Player and how to talk about it in Cubase vs Dorico. Dorico in their 3.5+ maps offers more of what I am talking about.

Let's take a theoretical SP instrument with the artic and directions I described. In all cases there are 24 patches, I am talking about the definition of the control plane.

In SP it looks like this:

Artic (C-0)  Vib (CC1)   Mute (CC4) - note how the control per dimension is declared

===================================

stac (C0)    Senza       Norm

spic (C#0)   Vib         Con sord

det (D0)     Molto

long (D#0)

9 entries. Note that e.g. how Vib is controlled is explicit (CC1). To change vib you only need to send CC1 and it 'sticks' until you send something else. This is an independent idea from any DAW/Notation and its editing UI - it's the control plane for the VI.

In Dorico it looks like this

Artic

===========

stac (C0)

spic (C#0)

det (D0)

long (D#0)

Vib (add-on)

==========

Senza (CC1 - 0)

Vib (CC1 - 64)

Molto (CC1 - 127)

Mute (add-on)

=============

Norm (CC4 - 0)

Con sord (CC4 - 127)

again, 9 entries. The add-ons correspond directly to the dimensions. Dorico knows that if Vib changes in the score it needs to send CC1. Whether or not it sends this with every note is its problem, not yours.

In Cubase it looks like this:

Artic   Vib       Mute      - Messages

========================    =======================

stac    Senza     Norm      C0+(CC1 - 0)+(CC4 - 0)

stac    Senza     Con sord  C0+(CC1 - 0)+(CC4 - 127)

stac    Vib       Norm      C0+(CC1 - 64)+(CC4 - 0)

:

20 other entries...

:

long    Molto    Con sord   D#0+(CC1 - 127)+(CC4 - 127)

24 entries. Tons of redundancy. Worst though is that e.g. Vib is not an independent first class idea - there's no indication which of the messages represent Vib. Vib is just something that can participate in a combination, and only then, to generate a ball-of-mud set of messages. But vib was an independent idea in SP, so this is lossy. Dorico add-ons are strictly better.

Cubase's maps are not good because they are only combinatoric. The Cubase MIDI editing UI (I'm not talking about the emap editor) could just as easily be used to control maps that had first-class directions, because that is exactly what Dorico does via notation and add-ons.

Originally Posted by: Dewdman42

Quote:

Synchron Player similarly needs to let us specify which dimensions are for per-note articulations and which we want to control independently of the sound variations system.

I don't understand this suggestion either, maybe you can try writing it another way, I am genuinely interested.

What I'm advocating for SP is that it let me tell it to only use, in this case, the Artic dimension for sound variation sync, meaning it will send a map with 4 entries, because I am going to use CCs or automation lanes to control Vib and Muting.

There is no need to have a shared "group" idea in the sound variations API because that will just lead to more copying of Cubase in its current limited state (which Dorico did and then backed away from), and dictates too much to implementations. Sound variations are ok for per-note stuff.

In practice, for most Synchron libs I'd only want the Articulation and Type dimensions to generate a sound variation map. I just did this by hand for Elite Strings and the map has 42 entries (instead of the 400+ it generates automatically) - perfectly great for DPs artic selection menus and editors. I control Vib, Attack, Release etc with CCs - they chase, and fewer messages are sent per note. In Logic it's trivial to make a Scripter UI which gives CC values names.

Still WIP, but I'm happy to share if you have Elite Strings

Originally Posted by: Dewdman42

I think you might be conflating several things here.  Cubase expression map grouping works regardless of whether you are using ATTRIBUTE or DIRECTION.

DIRECTION and ATTRIBUTE both have their separate pros and cons, but grouping is not reserved only for DIRECTION.

I do understand Cubase expression maps well, and did not say all groups have to be directions. I'm saying you do not get out of combinatorial explosion of articulation entries until you have an independent notion of directions. Consider: you have staccato, spiccato, detache and long, 4 artics. Then you add a mute group with 2 entries normal and con sordino. You now have 8 (4x2) entries in a Cubase-style map. You add a vibrato group with norm, senza and molto. Now you have 24 entries (4x2x3). Direction or not, there's a multiplication going on. 

Now consider having proper notation-style independent directions. You still have 4 artics, but could add 2 independent mute direction states and 3 independent vibrato direction states for a total of 9 things you have to say (4+2+3)

Dorico had the same problem as Cubase, whose expression maps they copied at first. I documented the problems here:

Subsequently they added Add-on Techniques in Dorico 3.5, moving away from the Cubase model:

"and improved handling for techniques that can be combined with other sounds, without needing to define every possible combination in the expression map"

What Cubase groups are missing is an association between the group and the output messages associated with that group. All output messages for an entry are just an undifferentiated set. This is not like Synchron Player, where dimensions not only group a characteristic together, but also independently specify how to select the choices within the group, without regard to combinations.

tl;dr - Cubase groups do not solve the combination problem. When I described that to the Dorico devs they improved Dorico by making some groups/dimensions independent. Synchron Player similarly needs to let us specify which dimensions are for per-note articulations and which we want to control independently of the sound variations system.

Originally Posted by: Dewdman42

The Sound Variation API comes up short for a number of reasons.

The point you make is, I think, related to the fact that different dimensions are quite often best handled by a multi-group articulation manager such as provided only by Cubase expression maps.

having every possible combination of keyswitches listed as seperate articulations is indeed very unwieldy in many cases.  

For the case of Synchron, the total number of "rows" in the articulation lane should be DIM1 + DIM2 + DIM3..etc..  rather then DIM1 x DIM2 x DIM3, etc...  Even the Synchron Player itself presents things in this kind of fashion...but unfortunately StudioOne, LogicPro and DP do not have have multi-group functionality in their articulation managers as of now so the only way they can handle all the possibilities of multiple dimensions is DIM1xDIM2xDIM3, etc..resulting in combinational explosion. Only Cubase expression maps can handle up to 4 dimensions that way.

I have been able to code around this limitation in LogicPro using scripter and automation lanes to provide the other groups..  But I am switching to DP now...so...won't be any help much longer.

At least in the case of DP, one good news is that DP saves the results received via Sound Variation, into a json file, which you can edit after that if you like...and then basically just ignore Sound Variation after that.  So maybe you can write a script that can manipulate the json as you wish to reduce all the dimension multiplication...

Cubase groups still have combinatorial problems (consider using a group for per-note accents, it's still a multiplier). What matters most is the idea of directions, which, like directions of notation, are not specified per note and stick until superseded by another in the same category. It's only when a group is specified as a direction that the combinations decrease.

Getting VIs and DAWs to agree on a system for directions too, when so many don't have any representation of the concept, seems like a dream never to be realized. However, if VIs could let you control what gets expressed as sound variations (articulations), you could limit that to proper per-note articulations. The number of other directions (controlled via e.g. CCs or automation) is usually small - bowing style, vibrato, muting etc, and most DAWs have reasonable ways to set and chase CCs.

Originally Posted by: PaoloT

Hi,

I would like to consolidate into an individual preset separate, but related libraries, like Regular, Sordino, Tasto and Ponticello libraries.

My idea is to create a top level dimension, into which to copy the individual libraries. For example, a dimension with the Regular, Sordino, Tasto and Ponticello cells.

These would be selected by their set of keyswitches (or CC values). In Dorico, for example, a technique like "ord." would select the Regular branch, "pont." the Ponticello branch, and so on.

But the structure of the individual branches should be the same, or I fear it would not work

I do this and it works fine. It looks like this

I described this and more Synchronized Dimension Strings tips in this thread.

While a promising development, the Sound Variations synchronization feature of Synchron Player (which now works with Digital Performer 11 as well as Studio One) needs some work before it is practical.

Consider Synchron Elite Strings. A synched sound variation set contains over 400 articulation entries, one for every valid combination of every dimension. For Synchronized Dimension Strings, there are over 3000 articulation entries! This is undesirable and impractical. It yields unwieldy picklists, menus, and other DAW UI elements, with an overwhelming number of choices. It even creates redundant multiples of variations for dimensions whose slot controller is set to "None".

Many of us use CCs, velocity, speed etc to control minor variant dimensions (attack, vibrato, normal/agile legato etc), and would continue to do so when using articulation maps. What we'd want is just a subset of dimensions, e.g. Articulation and Type, to generate Sound Variations. This would yield fewer than 50 core articulation types for Elite Strings, a much more manageable number.

To achieve this, I suggest that Synchron Player let us specify on a per dimension basis whether or not that dimension should contribute to the Sound Variation combinations (and outputs).

Thanks,

Rich

In VI Pro there's this "tip"/feature:

To assign "random" tuning curves quickly when you're changing the tuning of many patches, hold down Ctrl-Alt-Shift and click the "Humanize:" label, just to the left of the Humanize Preset box itself. You will then be asked to press a key to assign an "in tune random" variation number without going through the sub-menus.

How can we similarly setup humanize for a set of patches in bulk in Synchron Player? It is quite tedious to setup dozens of patches one at a time.

Originally Posted by: NG33

Hello,

I'm a very happy user of Strings Pro, and I would like to know what do think about buying at a great price the Synchron strings I ?

I know there is no portamento, but a lot of velocity layers...

About the tone, do they have the same tone?

SSI is one of the best string libraries available. I personally greatly prefer it to SSPro, not only for the much increased dynamics, but yes, also the tone and the greater legato and vibrato options.

For consistent and deep dynamics, realistic not-overblown legatos and vibrato, articulate onsets etc, Synchron Strings I is still the best game in town IMO. I prefer it over SyS Pro everywhere they overlap (which is a lot).

SyS Pro is a lot harder to use, with the dynamics split up, inconsistent levels between patches, sluggish long onsets etc.

I sincerely hope there's a SyS II that follows the groundbreaking approach and stunning depth, consistency and quality of SyS I. SyS Pro is not it.

I use DP 10.11 with VEP 7 server.

I start VEP 7 server first. Then all those instruments can 'connect'.

I use the MAS instrument and it works well.

+1. There are several of us who ask for this regularly over the years, but to no avail.

VSL instruments frequently need scripting and VSL does not provide it - neither in the players nor VEP.

Kontakt instruments get KSP scripting (for MIDI input transformation) right in the player. It would be a great feature for VEP.

Originally Posted by: Bill

Just remember that as the VST2 spec slowly fades away, program change will go with it...

That's FUD. MIDI is the spec and program change is still part of the spec.

Steinberg is not in charge of the industry. Are we consumers or sheep? Complain about their shoddy implementation of MIDI in VST3!

It's much more than PC as others have said. Get rid of MIDI and you lose:

• MIDI scripting
• Interapplication MIDI
• MIDI files
• etc

This nonsense about VST3 expression being the center of the universe is just that, nonsense from Steinberg.

Originally Posted by: Dewdman42

I don't particularly think VSL instruments are any more cumbersome then others, in fact quite the opposite, they are quite flexible.  There is nothing stopping you, for example, from putting all of your articulations in Synchron Player under one super tall column (dimension), and only need a single keyswitch for each articulation.  You can reassign keyswitches and CC's to various aspects of sample playback better then just about any other sample player I can think of.  

Yes, the factory defaults happen to be setup in a way with 4-5 dimensions, which means you need to send perhaps 4-5 keyswitches using those arrangements, but you can rearrange your own presets however you want and can avoid multiple keyswitches..  ViPro also you can arrange presets using only a single row of X-based keyswitches if you want.

You are making a theoretical argument but have you actually tried these things? Synchron player does not offer scrollbars on dimensions and shrinks everything down to an unreadable and unusable size as a single dimension grows.

And VI Pro only offers 12 slots per X/Y dimension, even if the controller is a CC. Sure you could make dozens of single-cell matrices and drive VI Pro via program change but that is clearly antithetical to the design. VSL's intended design takes more control messages than any other. A single-dimensional control method can be offered orthogonally - e.g. Spitfire's UACC system (although the universality of that was an overreach). XSamples libs have a 2-D keyswitch system but also offer access to all 88 patches via a single CC, right out of the box. Don't get me wrong, I appreciate VSL's flexibility otherwise and I think a lot of the challenges come from their increased depth of sampling, which I also value.

As far as the initial ask (MIDI scripting in VEP). Sure, we can talk about the shortcomings of DAWs etc and make arguments for this (we agree) but there is already an example of this feature on the market and it is available with the vast majority of VSL's competitors - the Kontakt ecosystem.

Kontakt player, like VEP, can host multiple VI instances, albeit only Kontakt ones. And right at the top of every multi there are slots for KSP scripts. People value this capability and it gets used. If you have a lib that only uses keyswitches and you want to use CCs, you can fix it. If you want to route across multiple instances you can do it, channelize, conditionally filter etc. Thus every Kontakt instrument supports MIDI input scripting but no VSL instrument does and no VSL product can add it.

So I'll change the argument - Kontakt multis offer both MIDI script slots and a built-in scripting language for them, why doesn't VEP?

Originally Posted by: Dewdman42

Another route VSL could go would be to identify the specific reasons people are asking for a midi plugin slot and instead just build that functionality into VePro somehow, especially as pertains to articulation management.

That's a fine idea. We don't need our answer, we need the problem solved.

Here's the problem - and I'm limiting it to just being a consumer of ($14,000+ worth of) VSL sample library products:

Whether it's VI Pro or Synchron player, VSL requires more keyswitches/commands to be sent per articulation/patch change than any other product. In VI Pro it was matrix/X/Y, and sometimes A/B switch (4). With Synchron player, the sky's the limit.

VSL has a reputation for being hard to use and this is exactly why. Solving this problem in a DAW or notation program is a lot of work, and every articulation system is different. So not many people do it, and not nearly as many people use VSL as could.

What do I want instead of 4-6 commands per articulation? I want to send a single PC/CC. There are rarely more than 128 patches in an instance, and I'd be happy to live with that limit. Within the instance I want to be able to say PC/CC 42 = this patch, PC/CC 27 = that patch. That's it. I'm not playing this live, I don't want my hands on 5 controllers, I don't want extra keyswitch notes on my tracks, I don't want to have to record keyswitch/CC dumps or anything else. Nothing about solving this need get in the way of also supporting multidimensional live control.

This is what I use MIDI scripting for - turning a single PC/CC into the pile of commands that VSL requires. Obviously this could be solved in the VI/Synchron players, or VEP.

The other thing I always use MIDI scripting for with VSL is making it so CC2 can be interpreted as velocity when VelXF is OFF. That is, I want to use the CC2 value for the dynamic without the crossfading. This also could be supported as a mode right in the players.

In any case, the biggest point is that this desire/need is driven by VSL's sample products themselves. It's not an abstract "wouldn't it be cool" thing. I really don't want to have to use BlueCat Plug'nScript or Logic's Scripter etc. But VSL sampling products are just too cumbersome to use without, IMO.

Originally Posted by: Paul

Hi Duggle, 

I'm afraid VE Pro is not ready for MIDI processing plug-ins. There has been very litlle interest for it so far, so it is unfortunately not high on our wishlist. 

Sorry to have no better news. 

Best, 
Paul

How do you measure such interest? Is there a place for making feature requests and voting on them? It seems like most feature requests here just get ignored and we get whatever is already on the roadmap VSL defines.

There were several people interested in this, many interested in more precise CC control in Synchron player, many interested in being able to play trills in Synchron player as we can in VI Pro etc.

Originally Posted by: Dewdman42

I'd actually rather have a mode, perhaps for both players, where when you add a row to ViPro (or a slot to a dimension in Synchron Player), the first row will always be cc value=0, the second row always cc value=1, etc..  instead of evenly dividing the range, just keep adding a new row to the end as the next available CC value.

As you put it, that would be much more explicit and consistent when working with expression maps and articulation sets, but not only that, existing tracks you may have recorded with key switches in place even without expression maps and articulation sets.  

I can see how the existing method of evenly dividing the range makes sense in certain situations where you are meaning to crossfade through a range of things.  However, when using it as a patch selector, then having it be more explicit, with exactly one matching cc value per row...starting at 0...would make a lot more sense.

Yup, I already requested that, here:

https://www.vsl.co.at/community/posts/t52871-FR---Bank-Select-as-discrete-dimension-selector#post286753

Originally Posted by: Dewdman42

I'm not really understanding the problem here.  Can you please elaborate?  You can use a Dimension Controller for slot selection..isn't that what you're asking about instead of X/Y?  

ViPro has 2 dimensional patch selection, actually 3 dimensional if you include the matrix...and maybe more if you use A/B.  But anyway, with Synchron, you have N dimensions due to the tree approach to arranging patches..you can actually do quite a bit more than under ViPro, unless I'm missing something?

In order to use something other then a keyswitch to choose which slot from a column, then you use one of the dimension controllers, which can be CC, PC, key, velocity, etc..  all just like ViPro.

I was missing this before and someone cleared it up for me a few weeks ago...  Ben probably...

Or what am I missing?

In VI Pro you can designate a CC for an X/Y dimension and then explicitly set (arbitrary) splitpoints for the mapping to cells, e.g. split at every 10 - 0/10/20/30 even if there are only 7 cells across. Or assign the absolute min and max values to certain cells and spread out the rest, 0=first cell, 1-126=second-sixth, 127 = seventh. Explicit splits also make it possible to add cells and not break mappings.

In synchron player the mapping of CCs to slots is a product of the number of slots in the dimension and the curve selected. E.g. a straight curve will place the splits at every 128/N and the non-straight curves are pretty difficult to predict. So the straight line split for 7 slots will be every 128/7 = every 18.2857149. Quick - where are those splits? And doing things like reserving min/max etc is almost impossible. Adding slots to dimensions always breaks mappings unless you already reserved them with empty slots. Pro tip - reserve them! Padding out to 8 slots = every 16, 12 slots = every 10, 16 slots = every 8 in the CC range.

Thus synchron's is a system for human fader/knob twiddling that poorly serves expression map and notation users.

Originally Posted by: assagai

Will Synchron player ever get user definable values for controllers like VIPRO has?

I understand the use of the curve, but it involves way more guesswork/tweaking and is more unpredictable than the way the x/y axis works in VIPRO which allows for far more precision, and is one of the reasons I sometimes use VIPRO over synchron.

Also will the Synchron Player ever get a sequencer function?

Thanks

+1 please allow for more precision in dimension control! The only precise controls are keyswitches (I'll never use them) and program change (which is only useful for about 16 values - would be much better if PC could control 2 dimensions, 10s/1s as I've described elsewhere).

The current system might be fine for playing around with faders or using MIDI dump, but it's an absolute bear to make expression maps or notation rulesets.

Originally Posted by: thomasoehler

I would have another question: I thought I would originally organise things "per desk", and therefore have (for example for violin I) 4 SP with only the corresponding players loaded/active in the mixer, which means 2 players per SP. I would then use a summing track in Logic to control the 4 SP at once when needing a tutti of the 8 players. It worked as intended, but it did not sound as good as the "all players" patches. Did I make another foolish mistake, or as I suspect, the "all players" patch is different (and nicer) than a mere combination of the 4 desks? Or maybe I need to "re-mix" the summing of the 4 tracks to re-balance things when using a tutti? This solution would be more elegant and optimise CPU and memory load even further; but I am not sure if it is achievable.

Again, I am so grateful for insights! I recently endeavoured to up my game with the quality of mockups, but my tiny composer's mind sometimes struggles with the complexity of the technical side of things...

Thanks a lot

You're quite welcome. I've used the same summing track techinique in Logic to target multiple instances of SynDS and it worked and sounded fine. Maybe something else is amiss? Make sure you are constructing the group with distinct players (1+2, 3+4, 5+6 etc) and not getting 1+2, 1+2, 1+2, else you could have phasing.

Also note, since you obviously have DS II and DS III as well, that once you use "all players" and no longer the desks you can reclaim the first dimension to select between modes of play in a single SP by copying and pasting the Sul Tasto and Sordino "all players" trees into a single preset.

It will look like this:

Syn DS combo preset

Originally Posted by: thomasoehler

I was wondering about the demands of the (by the way wonderful) synchroni-zed Dimension Strings on CPUs. I would like to experiment with them in the context of complex all-out divisi and possible layering, but I quickly ecounter limitations.

Any advice greatly appreciated! Thanks!

It matters quite a bit how you are organizing your use of synchron player(s) (SP) and dimension string players.

I presume when you say 9 'voices' you are talking about dimension instruments/players? VIs typically use the term voice for simultaneously playing sample, and if you look at the voice count at the bottom of SP you'll see dozens of voices used even for single note lines.

Presuming you are talking about dimension players, you have a number of choices re: e.g. which preset (e.g. all players vs desk etc). By far the easiest way to work with SynDS is with the 'all players' patch, even if you only want to use a subset. This is because you can quickly create dimension tree edits and mappings for all players rather than have to replicate your work as you had to do in VIPro, and quickly try different player combos.

But by far the hardest thing for a single SP to do is run all 8 DS players.  

I'll presume you have an SSD, and you are running SPs in VEP (from your tags), if not then the DAW performance is another factor.

What you want to do is:

a) (Continue to) use the 'all players' patch for convenience in editing, selecting players etc. It is, IMO, the single biggest value prop of synchronized DS.

b) Use more/many SPs - VEP is much better at multitasking than is a single synchron player.

c) In any particular SP, activate (see below) only a subset of the players, e.g. no more than 4. You can setup another SP listening to the same channel in VEP for the other 4. 

d) In any particular SP, make sure you are not using CPU for resources you don't need (i.e. when you only use a subset of the all players)

This last part is subtle and here are two tips:

1) If you are using MIR and not the built in synchron IRS, don't merely disable them - remove them. Removing IRs releases the CPU

2) Don't just mute any players you are not using (or the reverb), deactivate them by clicking on their name at the bottom of the channel in the mixer. The name will go grey and italic. Deactivating releases the CPU burden in a way that muting does not.

In this way you always have the convenience of having all players at hand (vs having only a subset in the tree/mixer).

I had a lot of dropouts with synchronized DS until I adopted these practices after which I've had no dropout problems (using VEP on the same box).

Good luck!