Yes, by far 😊. Aside from the fact that the Expression Map editor and the implementation of score symbols is a nightmare in Cubase, Dorico has several big advantages:

- in Cubase one can assign at most four different specifiers (like staccato, ...), simultaneously to get a particular playing technique, while in Dorico there is no restriction. I.e. one can e.g. specify no vibrato, legato, on the G string, played by four players and with an accent 😊.

- In Cubase these even have to be in a particular order for things to work, while in Dorico there are no restrictions 

- and finally Dorico Expression Maps offer criteria for an automatic playback of a score. Unfortunately, so far only the note length is supported, but nonetheless this way long or various short notes can automatically be played with the appropriate playing technique, and this works really well. As soon as Dorico offers more such criteria the playback will be mostly automatic and one will only have to tweak here and there.

update: 

On Rosetta using VST3 (not VST2) it indeed works. It would be useful if VSL would add this info somewhere in the small print on the S1 page, since I am sure I am not the only one on an Apple-silicon Mac and I did not even know before how to (deliberately) run an App in Rosetta 😊 (which is surely also much slower).

Hello John,

thanks so much for your very helpful feedback, this explains it! I am ion a M1 Mac and in the Plug-In Manager S1 only shows the AU version. It is a pity that so many useful features don't work anymore with VST3. Let's hope for a native AU version that works then.

All the best

Kai

Hello Gabriel,

ok, maybe in this case the 5.5.0 update broke something there.

Thanks for the confirmation regarding the score. Good to hear that the combination of Studio One and Notion works well. I am hoping to finally be able to use a single Music Application for everything (so far I am going back and forth between Logic and Dorico ... which is rather inconvenient)., but in this case Studio One won't be the solution either.

Maybe the new Dorico 4 with its enhanced Midi-editing features, will do the trick (as far as there are no audio files involved in the project), because its notation and score playback features are unmatched.

Thanks again and all the best

Kai

Hello Gabriel,

thanks for your quick feedback! That's really strange then, and I don't understand what is going on. Which Studio One version and system are you using?

Since you use Studio One, I have another question: I have been playing with the Sound Variations editor a bit myself (using VI libraries). This works fine, but it seems as far as score symbols are concerned, it is not possible to trigger Sound Variations based on several score symbols (e.g. staccato and con sordino symbols to obtain the con sordino staccato playing technique). Is this correct?

In Cubase Expression Maps there is no such restriction. Unfortunately, Cubase Expression Maps are otherwise pretty clumsy and limited compared to what e.g. Dorico offers by now.

Thanks and best regards

Kai

Hello,

to those who already use the VSL in Studio One: does the Synchron Player integration indeed work automatically for you without installing anything or any prior setup, as described in the videos? I have tried it with both Synchron Strings 1 and pro and the Synchron player works otherwise fine in Studio One (sequences are played back normally), but there are no Sound Variations listed anywhere (the Sound Variations editor remains empty when I load a preset in the Synchron Player, the Sound Variation menu item does not appear in the context menu when control-clicking on a note, ...). I tried this with the most recent version 5.5. 

Is there anything I am missing?

Thanks for any help!

Dewdman, I fully agree with what you wrote. In particular the implementation of "extended Midi functionality" like Articulation IDs and their relation to ordinary Midi data is just weird and completely incomprehensible in Logic. Even after nearly a decade it does not work at all to simply record Articulation IDs from a Midi keyboard the way they had intended it using Articulation Sets. There are commercial tools that do nothing else than to fix the mess that Apple left and somehow make this work. It took me years to accidentally figure out how to get this to work, and it was only possible with some odd transformations in the environment, so that all of a sudden Logic would recognize Midi events it would otherwise just filter out.

Dewdman, that's an interesting observation with the 8bit limitation. As you write, underneath the fancy surface everything in Logic is still built on the old environment code (even in the most recent version). They try to hide it as much as possible, but they simply need it. I guess this is (unfortunately) the only reason why the environment and all its nice Midi capabilities still exist. But it is indeed basically a miracle that all this still works (to some extent), taking into account what changes the architecture went through since the code was created (PPC, Intel, Apple silicon). The old artwork of some faders from the 90s alone is just incredible in a fancy Apple product in the 2020s . Anyway I really hope they give it a major overhaul at some point instead of removing the environment completely.

Macker, this sounds even worse than what I had feared. I know exactly how you feel, after having spent a lot of time to create a fancy environment that works and that your current workflow depends on, just to have to abandon it because of something like this. However, if the bug is so obvious, this should make it easier to communicate it in a bug report. The Apple team is incredibly slow (and one never gets any feedback), but hopefully they will eventually fix it this way.

Originally Posted by: Macker

In Big Sur, not only does Logic 10.7.1 not work on half the ports when used with my VEPro AU3 Template, but it also visibly corrupts my previously tested and working constructions in the Environment in Logic projects built with 10.4.8. Moreover, this Environment corruption occurs even after a previously tested and working Logic 10.4.8 project file has been opened in Logic 10.7.1 but never saved in 10.7.1, then subsequently opened in Logic 10.4.8. Even worse, if I'm not badly mistaken, the corruption also happens in 10.4.8 projects opened specifically in 10.4.8 but never having been opened in 10.7.1 - while 10.7.1 is merely there lurking in the Applications folder.

Hence I'm now treating Logic 10.7.1 as if it's malware.

Furthermore, if you use a VEPro AU2 multiport Logic template, I strongly suggest you treat it as potentially at risk from Logic 10.7.1.

I've done some radical "disinfecting" by deleting all versions of the Logic app later than 10.4.8 from my Big Sur boot volume, and by using Time Machine to restore all my Logic projects from backups done before I updated Logic 10.4.8 and created my Big Sur boot volume. And that means I've effectively lost many, many hours of work since mid-July on developing older projects and creating new ones.

I'll spare you my current thoughts and feelings about the 'developers' working on Logic at Apple Park in Cupertino.

This sounds just horrible, sorry to hear you are having such trouble.. Can you elaborate a bit what exactly got corrupted in the environment and does not work anymore. I am using the environment extensively and fortunately did not experience problems in 10.7.1./Big Sur so far. However, I had plenty of similar problems with previous versions of Logic where (for years) things just would not work anymore after an update.

It unfortunately seems the environment is some legacy part of their code that hasn't really been maintained for far more than a decade and that they just carry around. Yet, every once in a while they break parts of it when they port it to a new framework, since no-one really understands anymore how the code works in detail.

Originally Posted by: Seventh Sam

Originally Posted by: Kai

I had implemented this in Logic via some Midi pre-processing in the past and it worked just fine (either with aftertouch or the pitchbend wheel). It would be great if such a mode would be implemented in the VSL players in the future.

That sounds...amazing!  If I had a controller capable of aftertouch, I'd try it out right away.  The pitchbend wheel, on the other hand... 

If you don't mind, could you elaborate on the pre-processing you did?  I don't use Logic, but I'm betting there's a way to replicate it somehow...

In the past I did this in Logic's Environment, but any software that allows real time Midi processing should be able to do this. I just created a corresponding script for Logic's Scripter Midi Plug-In (which is based on Java script).

This is what it does:

- The velocity of every incoming note-on event first has to be stored in some variable vel, Then the note-on event has to be duplicated and the first instance has to be converted to a velocity x-fade controller event with value vel

- When controlling velocity x-fade with channel pressure (aftertouch) only an increase starting from the initial value is possible. For this the channel pressure event with value cp has to be transformed into a velocity x-fade controller event with value vel+cp/127*(127-vel)

- Alternatively when controlling velocity x-fade with the pitchbend wheel any relative change (increase or decrease) is possible. The pitchbend event with value pb (in the interval -8192<pb<8192) has to be transformed into a velocity x-fade controller event with a value depending on the sign (i.e. pitchbend up/down):

if pb>=0 then vel+pb/8192*(128-vel)

if pb<0 then vel+pb/8192*vel

Hi Sam, 

you are right. Aftertouch does not work for velocity x-fade directly, since velocity x-fade completely replaces velocity by a controller, and the aftertouch controller always start at zero when a note is played.

However, there would in principle be a way to make this work, if there would be a "hybrid velocity x-fade" mode in VSL players, where velocity still determines the initial value of the velocity x-fade controller and the physical controller then allows the player to control subsequent relative dynamic changes with it. This has the advantage that one can still standardly play with velocity, which should be much more natural for piano players (in particular for short notes). One would then only have to use the physical velocity x-fade controller when one actually wants to perform realtime dynamic changes (e.g. for more realistic playback of long notes).

I had implemented this in Logic via some Midi pre-processing in the past and it worked just fine (either with aftertouch or the pitchbend wheel). It would be great if such a mode would be implemented in the VSL players in the future.

Hello Macker, 

thanks so much for the detailed explanation!

This all looks very promising. After being hesitant to upgrade for some time (because certain hard- and software unfortunately does not work anymore afterwards), I am likewise moving to Big Sur and will give it a try ...

Hello Macker, 

thanks for pointing out this new feature in Logic! This sounds very interesting and I agree that this could indeed be very beneficial for orchestral composition if it is implemented the right way. I was moving towards Dorico but this feature could definitely make me come back to Logic (didn't upgrade to 10.5 so far). For me the biggest advantage of this would not just be the realtime triggering of patterns but the non-linearity you mention, which would be great for arranging and experimenting. As you point out, historically basically all orchestral music is built from small themes that are varied, repeated, played by different instruments, ... to create a larger arrangement out of them - in contrast to the "tape machine" paradigm Logic had so far.

As far as I understand this should imply that there is a separate repository/resource window for sequences that do not have to be assigned the Arrange window so far? This is something I have always been missing in Logic. To get such a pattern based working style one had to have dummy tracks in the arrange that stored the sequences that one would then arrange ...

To make this really useful for orchestral music would ideally require the following:

- the individual musical building blocks should have the capability to include tempo information instead of a rigid time frame used in the context of electronic music - and if one uses sequences with different timing information one should be able to decide which one is used

- it should be easily possible to transpose these patterns (in particular in octaves to move them between instruments with different ranges)

- the possibility to combine sequences on different tracks (e.g. the sequences of an entire string section) into a combined object that one can move around or trigger (while still having the freedom to edit the individual components)

Since you already checked it out, can it do (some of) this?

Oh, I see. Yes, this would be convenient (if there are no adverse latency or performance effects) . But it would be great if this could be implemented in a similar way to the current Auto-Voicing, so that it is flexible enough to still be able to control how many players are used, instead of a fully automatic algorithm that always keeps all players busy.

However, the present Auto Voicing in VI pro is already the big improvement, compared to e.g. the Synchron Player, since it allows the user to keep the entire section on a single track and conveniently realize arbitrary divisi. For me it is not such a big deal to send a single additional control event at the beginning of a divisi passage, that selects how many players are used per note, when otherwise everything is handled completely automatically.

Yes, we need more Dimension Strings libraries. As far as I am concerned volume IV should complete the range of sul ponticello articulations as well as espressivo patches and legato harmonics, which are not available, yet in any of the string libraries. But, it is not so important in which order the different playing techniques are released as long as they continue to extend these libraries.

Pixelpoet, what do you mean by "real auto divisi"? Selecting how many players shall play a note and VI pro automatically distributing all voices among the different players, works already perfectly in VI pro with the Dimension libraries. Yet, I second all your other suggestions.

Originally Posted by: William

... despite not having as many "dimensions" or layers of menu-driven pre-programmed automation, you can do anything with VI musically speaking. You have total control over ever possible MIDI parameter. And you can create your own setup which is very easy to use. That is ideal.

Actually VI pro does offer the "dimensions" if programmed appropriately ("3D-control"):

https://www.articulate-preset.com

VI libraries include the required broad variety of sampled versions, while VI pro is at the same time flexible enough to take all of them into account and efficient enough to indeed simultaneously control various musical parameters, like section size, vibrato, attack, legato, muting, bowing position, ... .

As you write, a big advantage of VI pro is its flexibility, which allows users to work in any way they like: they can use a full-featured preset, or start with an empty VI pro instance and add individual matrices (with all the continuous control already set up) as needed, and where necessary even build their own matrices from scratch out of individual patches while working on a project.

Hi William,

I agree with what you wrote about VI pro 😊. It has lots of advantages for Silent Stage libraries (just like the Synchron Player has for Synchron libraries). I likewise clearly prefer the former and that's why I basically don't use Synchron (although I have some libraries). 

But I don't see how you got the idea that VI is going to be "discarded". Just two months ago they released a Synchron Stage MIRx plug-in, which only runs in VI (pro) and makes VI libraries finally fully compatible with the Synchron line, in the sense that you can have all VSL instruments conveniently in the same venue. By far most of the present VSL instruments are VI-only and the release of the Synchron venue suggests to me that they do not plan to "synchronize" everything (why would they, given the many advantages the VI player has for these libraries).

Last year there was a major VI pro update (retina support) and just a few month ago there was new sample content released for the VI player (Dimension Ponticellos). So I am confident that they know what a great software they have with VI pro. 

That they market the Synchron Player to new users, is as far as I understand since they get a self-contained package this way (without purchasing VI pro and MIRx venues in addition), that is a bit simpler to use/get accustomed to (but at the same time, as you write, also more restricted).

So I agree with LAJ: relax 😊.

Cheers

Kai

this is very helpful - thanks so much Paul!

After playing these sounds for some time, I have to say that the samples are simply gorgeous. In the other libraries the ponticello is sometimes a bit on the harsh side, but the Dimension ponticello is smooth and silky (in particular the slow tremolo, which is among my favorite sounds in the entire VSL). 

Only the present programming does not yet entirely match the high quality of the samples. While things are fine when velocity X-fade is turned on, once turned off there are dramatic volume steps (~15dB) between the different velocity layers in several patches - even for staccato where I usually wouldn't use velocity X-fade. I am sure this can easily be fixed in an update to make these patches as playable as these samples deserve.

Thanks again for this nice surprise !

Thanks so much for the very nice ponticello freebie, VSL team ! It is great to see that the Dimension Series is further extended and these were the most missed articulations. I hope there will nevertheless still be a complete sul ponticello package in the future including the other articulations (legato, portamento, repetitions, ...) included in DS1-3. I am sure many users would pay for this.

Dietz, you are awesome  - thanks so much!

I was wondering as well how this works when I got the email, and find this "solution" likewise puzzling and inconvenient. It should not be too hard to write a little script that checks how long the current plan is still valid and determines the expiration date of the new plan based on that. In case VSL does not want people to purchase coverage for the next 20 years in advance, that script could likewise ensure this  ...

Originally Posted by: Paul

Hi David, 

"Synchron Strings Pro" because it really is more than just a second part for Synchron Strings I. 

Synchron Strings Pro is a fresh approach and also contains some articulations from Synchron Strings I, which makes it an independent product AND and upgrade/crossgrade from Synchron Strings I at the same time. 

You are correct about CC2, but that should be done with a click. Hope that's OK for you, we're trying to keep the preset list as lean as possible!

Best,
Paul

Hi Paul, 

congratulations on this release. This looks and sounds very promising!

I can understand that you packaged it this way to give new users a self-contained library without the problems of SYS I.

However, for owners of SYS I who already have a 300GB block on their disk (iwithout using it so far) it would be great if you could release an improved installer for SYS I, that would only install that content (e.g. additional velocity layers) that is not in SYS pro - or even better let the user choose which content of SYS I should be installed. This is particularly important since some of the best content of SYS I (9 velocity layer shorts or the lyrical vibrato that was previously released to improve it) is apparently not part of the "pro" package.. 

Is this planned?

Cheers

Kai

Oh I see, thanks so much for clarifying this, Bill! Now I get your previous remark - I had no idea that this is such a minefield.

Sounds like Steinberg re-invented the wheel, but for some reason people still prefer the old-fashioned, round version  ...

Hello Dewdman, 

thanks for this comprehensive explanation, really appreciated.

I had no idea that this is such a tricky issue and even controllers are no alternative.

I have a few more questions: 

I was searching the forum, and if I understand a previous thread correctly so far both VI pro and the Synchron Player are VST2 only. Is this still correct (somehow VI pro lists VST3 support on the VSL homepage)? So if Steinberg's statement is correct, once these are ported to VST3 there might be a way for VSL to implement "program change messages" Steinberg's new way, so that one can still e.g. send these Midi messages to Cubase and they will then somehow be transferred to VI pro or the Synchron Player as VST3 proprietary non-Midi events?