Vienna Symphonic Library Forum
Forum Statistics

190,303 users have contributed to 42,730 threads and 257,098 posts.

In the past 24 hours, we have 4 new thread(s), 25 new post(s) and 42 new user(s).

  • Program change messages in the Synchron Player

    To not get unwanted key-switch notes in the score, ... I am trying to use Program Change messages to switch articulations in the Synchron Player. I can in principle see two ways to achieve this, but none of them really works:

    - In VI pro one can have 128 matrices and can control each with a dedicated program change message. In principle this seems to work as well in Synchron, but the vertical list of slots is not scrollable and so the individual slots just shrink and this simply does not work at all as soon as there are 20+ vertical slots, since they become too thin, look horrible and one cannot properly access them anymore.

    - The Synchron Player also offers the option to select slots with program change messages starting from a certain number. So in principle one could arrange the articulations in two dimensions, where the first dimension divides them up into "banks" of 10 articulations each that are stored in the slots of the second dimension. These can indeed be accessed by program change messages (e.g. articulations 10-19 by the corresponding program change messages), but this only works within a given "bank". I.e. if the first bank (1. slot in 1.dimension) is selected and I send PC15 it does not switch to the second bank and I would first have to select the second bank by hand. (For this to work automatically there would need to be a way to select the "bank" slots in the first dimension based on whether a program change message is within a range of values.)

    Am I missing something, or how are program change messages supposed to work in the Synchron Player?


  • Two problems weigh heavily against using Program MIDI messages to control slot selection in more than one dimension (column) in one Sy Player. It appears you've already noticed the first of these problems, but I'll lay out both here for the sake of other readers who may not yet have got as far as you.

     

    Problem 1.  First let's consider using MIDI Program to control 1 dimension only. Let's say this dimension has 8 slots, and you've specified Program 10 in the dimension controller box at the top. You send Prog 10, and the top slot selects.; then you send Prog 17, and the bottom slot selects. And each slot in between can be selected according to 1-to-1 mapping, as you'd expect. All fine so far.

    But then you send Prog 9, or 3, or 0, and the top slot selects. Then you send Prog 18, or 20, or 30, and the bottom slot selects.

    That's the first problem. Sy Player doesn't treat MIDI Program in the same way as MIDI Note keyswitches. Out-of-range keyswitch notes do not affect slot selection, but out-of-range Program numbers do.

    So it's not feasible to control more than one dimension with Program by assigning each dimension its own range of Program numbers, because there's no way to make a range of Program numbers exclusive to one dimension.

     

    Problem 2.  Even if VSL changed Sy Player's treatment of MIDI Program such that out-of-range Program numbers didn't affect slot selection in any one dimension, there's still another problem.

    Assuming VSL had already made this hypothetical change, and say you have a piece of music in which MIDI Program is carefully automated such that it's controlling 3 dimensions in one Sy Player (strictly in left-to-right order of course). Then say you want to review or edit some part in the middle of your piece of music, and so you start playback at that point. What will be read from your Program automation at that point probably won't be what you expect or want.

    This is because your Program automation sequence typically would have to deal with dimensions in left-to-right order, but if you then start playback from some point farther to the right, only the last Program automation value at that point will be read, which logically may not reproduce all the dimension slot selections appropriate to that point in the timeline.

    Sure, you can always set the play pointer farther back to some point where you know the dimension control automation sequence from that point onwards will select all the required slots (or you could even switch off that automation and select slots manually), but how inconvenient would that be every time you want to start playback somewhere else?

     

    "Solution".  It's best to use as many different classes of MIDI messages as there are dimensions we wish to control in any one Sy Player. (Each MIDI CC number counts as one class, Program is one class, Note is one class.)

    Even so, then comes another issue that several users have already flagged up: it can be a very complicated and onerous chore to set up or modify automation for dimension control in many differently-structured Sy Players in a template or a piece of music.

    This is because when using Dim.Ctrl (A up to H), setting the value of an automated MIDI CC message to select a particular slot means we must first know what range of MIDI message values will select that slot - Dim Ctrl always uses proportional mapping across the full scale 0-127, dividing the scale into equal(-ish) chunks according to how many slots there are in the dimension. That proportional mapping is great for X-fading in Parallel Mode; but for simple articulation switching, not so much.

     

    Sy Player really is a paradigm-shift in the world of sample-based virtual instruments. As a result, our so-called "horizons of expectation" (or what we intuitively treat as "normality") have of course been thrown into a somewhat confusing state of flux. But as history demonstrates, successful innovations become "naturalised" in time. Soon enough no doubt we'll be wondering how the world of virtual instruments could possibly have got along before Sy Player! Lol.


  • Hi Macker,

    thanks for the comprehensive explanation. That's a pity that there is indeed no workaround, yet.

    In principle the dimensions of the Synchron Player seem quite powerful for realtime control, but I likewise don't see the advantage of this "solution" to send two events instead of a single (program change) event to select articulations. In particular since the number of articulations in present Synchron libraries is smaller than in the old VI libraries, so that 128 program change messages would be more than enough.

    I did not even realize the problem with unassigned program change messages you mention. This sounds like a bug that they should be able to fix without too much effort. However, the fancy auto-rescaling they implemented in the Synchron Player seems to be intentionally designed for not more than 20 vertical slots, and therefore I don't expect them to introduce a scrollable list as in VI pro.

    This would leave the second potential solution. I am not sure if I made myself clear, but the idea is that the same Midi message switches several dimensions simultaneously. E.g. in case of program change events the first ("bank") dimension would switch depending on whether the program change message is in a certain range of values (e.g. 0-9 -> slot 1, 10-19 -> slot 2, ...) and the second dimension depending on the exact program change number. 

    For this it would merely be necessary to implement the selection of slots depending on ranges of Midi events (notes, controllers, program change messages, ... ) of a specifiable length. This would be very flexible, and, as an extreme example, with 128 values one could switch up to 7 dimensions (with 2 slots each) simultaneously - or anything in between. In case of key switch notes, choosing the ranges to have length 12, one dimension could then likewise be switched by the octave of the note and the second one by the particular key (in case someone wants to dedicate an entire keyboard to key-switching).

    This does not sound too hard to implement and I hope this will be done in the future.


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


    Dorico, Notion, Sibelius, StudioOne, Cubase, Staffpad VE Pro, Synchon, VI, Kontakt Win11 x64, 64GB RAM, Focusrite Scarlett 18i20, August Forster 190
  • Hi Bill,

    I am on Mac OS, so I don't know much about VST. But why would a newer audio plug-in standard not provide a full Midi implementation anymore?


  • last edited
    last edited

    @Kai said:

    [...] why would a newer audio plug-in standard not provide a full Midi implementation anymore?

    Long story short: The company who is defining the standard (Steinberg, in this case) decided to drop this MIDI command, for one reason or the other. Much like Apple/Logic decided to cut corners in their Audio Units format here and there.

    ... not much a 3rd-party manufacturer like VSL can do about it.


    /Dietz - Vienna Symphonic Library
  • last edited
    last edited

    Kai,

    If you use REAPER as your DAW, you can use this: www.reaticulate.com

    Makes it unbelievably easy!

    - Sam


  • Thanks so much for the info, Dietz! I wasn't aware fo this. Funny decision by Steinberg, taking into account that any cheap keyboard/software managed to implement standard Midi functions for 40 years and there is lot of hardware (master keyboards, ...) out there that sends program change messages.

    Sam, thanks for pointing me to this. This looks awesome! But my main DAW is Logic.


  • last edited
    last edited

    @Kai said:

    [...] standard Midi functions for 40 years [...]

    ... uh! ... make that 35 years, please - otherwise I'm feeling even older than I am. 8-)

    https://en.wikipedia.org/wiki/MIDI: "The MIDI 1.0 Detailed Specification was published at the MMA's second meeting at the 1985 Summer NAMM show."


    /Dietz - Vienna Symphonic Library
  • Its a complicated topic, but Steinberg no longer passes raw midi messages into VST3 plugins.  Not only PC message, but no other raw midi either.  

    Supposedly a plugin can publish a so called "program list" to the host DAW and then the host DAW can choose to have something like PC messages within midi tracks, which it will know for VST3 to use the program api to select from the published program list.  


  • last edited
    last edited

    Oops, Dietz you are right as always 😊. It just somehow feels like it has been there forever.

    I vaguely remembered this: "The specification originates in a paper published by Dave Smith and Chet Wood then of Sequential Circuits at the October 1981 Audio Engineering Society conference", but surely it took time for it to reach the market.

    Dewdman, thanks for the info! This sounds like they want to establish an improved program change standard within VST3. Yet, it would surely be handy if it would be downward compatible.


  • The jist of it is that Steinberg does not consider midi to be part of VST.  period.  According to Arne @ Steinberg, VST is an audio api, not midi.

    Now it happens that audio includes instruments, which historically have received midi in order to produce sound.  but with VST3 they are trying to remove midi completely from VST3.  Instead VST3 has its own way of specifying things like notes and what sound to use...which has nothing to do with midi at all, though in some cases it may seem similar.  but programmatically, raw midi is not passed to a VST3 plugin, rather these other VST3 abstractions are.

    There are a few things that Steinberg didn't think through all the way in terms of how it would effect people practically speaking, that have been using midi messaging to accomplish certain kinds of things...such as sending key switches...or PC messages....or using CC messages as keyswitches, etc..  These uses of the raw midi protocol have been useful in the past under VST2 and other standards, but in some cases they have become problematic under VST3 if the VST3 way of programming these things didn't also capture those use cases.

    In any case, originally people freaked out about no PC message, but Steinberg replied repeatedly that it can all be done with Program lists, but that plugin makers would need to modify their plugins to use those instead of looking for raw PC messages.

    CC switches are also not a good idea to use with VST3 plugins.  They will work, but can be problematic if you have a chord of notes on the same timestamp with different articulations per note, using CC switches instead of noteOn keyswitches...  That scenario breaks down with the VST3 approach and unable to directly send raw CC messages in to the plugin.  The VST3 way to handle that sort of thing is with NoteExpressions (programmatically), but about the only DAW that uses NoteExpressions is Cubase and even their own ExpressionMaps are not using NoteExpressions to handle cc articulation switches, even though they should be...which means the chord problem I mentioned can happen.

    This can be a deep topic.

    In any case, its basically on plugin makers to adhere to VST3 program list in order to fully support using PC messages in the track to signal articulation changes.


  • 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?


  • Synchron Player and Vienna Ensemble are both  available as VST3.

    VST3 has been around for a number of years, and adoption has been slow to non-existent. Why? Because neither plugin developers nor DAW/Notation developers think it's of any value. Only Steinberg thinks it's of value. But they own it, so can do what they want.


    Dorico, Notion, Sibelius, StudioOne, Cubase, Staffpad VE Pro, Synchon, VI, Kontakt Win11 x64, 64GB RAM, Focusrite Scarlett 18i20, August Forster 190
  • last edited
    last edited

    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 😃 ...


  • last edited
    last edited

    @Bill said:

    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.