Vienna Symphonic Library Forum
Forum Statistics

201,679 users have contributed to 43,255 threads and 259,320 posts.

In the past 24 hours, we have 2 new thread(s), 12 new post(s) and 56 new user(s).

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries (legacy)
  4. Controller scales on VSL vr MIDI scales

  • Controller scales on VSL vr MIDI scales

    T
    T
    Does this just bug the hell out of me or is anyone else finding VSI controller scales that are 1-100 a pain in that midi data is all based on 1-127? The controllers should show a scale that is 1-127 since that's what we are using to send. It just doesn't make much sense to have two different scales. This never made any sense to me. I constantly finding myself having guess and poke around. For example If I want a controller to be at 95 on VSI I have send out a value of 121. I waste time constantly with this needless conversion. At the very least, I would hope that VSI would maybe offer a switchable scale, so users could decide which one they wanted to work with.
  • M
    M
    I agree... Must be 0-127... VSL must follow the MIDI Protocol about that??? I'll be pleased to here Mr Herb on that!
  • D
    D
    last edited
    last edited

    @Migot said:

    I agree... Must be 0-127... VSL must follow the MIDI Protocol about that??? I'll be pleased to here Mr Herb on that!

    Surely it can't be 0-127. AFAIK, it is either 0-126 0r 1-127. However, this has been mentioned before and there has been no change, so I doubt that it will change now.

    DG
  • C
    C

    Hi all, we had a discussion about this some time ago when the VI was re-designed and (if memory serves) the numbers in the H-SPAN and V-SPAN windows disappeared overnight. A few of us moaned about it and the numbers were reinstated. On the 0-127* vs. 1-100 issue, Herb (I think) explained that there's a conceptual conflict between showing the MIDI values 0-127* used by CC and Velocity or displaying percentage values 1-100, which VSL thought was a logical way of expressing playing speed. They opted for 1-100, wrongly in my opinion since CC's and Velocity numbers are real and playing speed is virtual.

    (* P.S. DG, it has to be either 0-127 or 1-128 because MIDI needs 128 values!)

  • D
    D
    last edited
    last edited

    @Conquer said:

    (* P.S. DG, it has to be either 0-127 or 1-128 because MIDI needs 128 values!)

    Ah thanks. For some reason I thought that MIDI needed 127 values.

    DG
  • M
    M
    Conquer, Our reality is that we are all working with scale of 0-127 or 1-128 AGAINST the VSL home philosophy system 0-100. The MIDI protocol was written exactly to avoid this...!!!???
  • S
    S

    I'm not particularly bothered by the VSL approach. However, it would be easier, in some ways to have the option of using the MIDI (0-127) scale. (e.g. ideally a switch letting you choose which way you wanted to see the data).

    If you set up complex matrices and use MIDI controller values rather than keyswitches to change articulations, you have to do some arithmetic to get the appropriate values. For example if you had 12 horizontal matrix cells and mapped articulaion changes to changes in value of CC#23, then you'd divide 128/12 to come up with a range of values for each articulation. If one works in Finale, one can assign these values to visible or hidden (non-printing) symbols or define them using the Human playback dictionary. In this situation, having a MIDI ((0-127) scale visible in the Control Edit page of VI might make checking things out slightly easier.

    In general, when notation software is the MIDI source, I prefer using CC values to keyswitches because CC vlaues can be assigned to the note on which an articulation changes, while a keyswitch must slightly precede the note on which the articulation changes.
  • L
    L
    I'd prefer it too, if the values in the VI would be the same as the MIDI-data, which flows in. Didn't really bothered me yet, but I really can't see a benefit in displaying it as 0-100 instead of 0-127.
  • C
    C
    last edited
    last edited

    Hi all. Alain, yes it's a bit of a conflict. I don't know why they used 128 values in MIDI in the first place (mathematically it is 2x2x2x2x2x2x2, which is probably irrelevant) but I've grown used to it now.

    @stevesong said:

    In general, when notation software is the MIDI source, I prefer using CC values to keyswitches because CC values can be assigned to the note on which an articulation changes, while a keyswitch must slightly precede the note on which the articulation changes.
    Good point - as has been often said, keyswitches mess up the score, and (as I discovered the other day) they cause Logic 7's 'piano roll' editor display to default to the extreme low range rather than the part of the window where the real action is. I'm going to 'switch' to CC's, despite having to work round the 128/100 issue!

  • F
    F
    last edited
    last edited

    @Conquer said:

    I don't know why they used 128 values in MIDI in the first place (mathematically it is 2x2x2x2x2x2x2, which is probably irrelevant)
     

    Actually, it is entirely relevant. Powers of two are all over the place in computer data formats and representations precisely because they map neatly onto how data is stored in computer memory without the need to scale or convert the values.

    So, in MIDI (which is a protocol that was devised when every bit of storage, and every cycle of computer execution, were precious), pretty much every parameter lies in a range that is the size of a power of two: 1-16 (channels), 1-128 (volume steps, scale notes, ...), etc..  Moreover, practically every bit in every instruction is meaningful -- the reason that the values aren't 0-255 (the range that naturally fits into an eight-bit byte) is that one bit in each MIDI protocol byte is reserved as a clue that a multi-byte sequence is over, so you only have seven bits available to store a value.  (And for when that's not enough, you can gang a pair of these seven-bit values together to get up to 16,384, which is two to the fourteenth power.)

    Having values that were, say,  0-99 or 1-10 or something else not related to a power of two would have been anathema for two reasons: some of the data-carrying capacity of the protocol would have been "wasted" (because some values would never have been used), and some of the processing power of the sending and receiving equipment would have been spent in making sure that non-valid values were discarded, rounded, or otherwise handled.  One side-effect of having a dense representation for the MIDI instruction set (that is, almost every bit pattern means something valid) is that the code that parses and evaluates the data stream becomes simpler; it doesn't have to test for, and handle specially, any out-of-range values that show up, because there can't be any.

    In these days of verbose data formats, such as XML, it's easy to miss the influence of the times when memory was expensive, and it was worth months of effort to reduce a program's size by a few thousand bytes.  But that influence is still with us, and shows up in the 4G limit of addressable memory, in ASCII and Unicode, in network byte order, in the resolution of samples, in DSL speeds, and on and on, all more-or-less related to powers of two.

    (Here is a subtle example of how misunderstanding data representation, and powers of two, can introduce a bug. For anyone who's really interested, I can explain what's going on.)
  • C
    C

    Thanks for that fcw, interesting stuff. As Huey Lewis and The News almost said, the power of two is a curious thing.[H]
  • T
    T
    I missed the old thread on the issue, but I'm not surprised that it's been brought up before. In MHO, it's the biggest flaw in the design of VSI. I waste more time dealing with converting than on any other process in my work flow - and I mean ANY. How could a long standing standard such as MIDI, just be ignored? It's just a bad judgement. Standards are there for a reason. The MIDI protocol has been around for over 20 years. I'm just dumbfounded how such a great product put out by a great company could drop the ball on such an obvious and important thing.
  • PaulP
    VSL Team
    PaulP

    Hello everybody,

    this is just to let you know that we are listening [:)]

    On a sidenote: Our idea was to get away from editing numbers to actually playing music with virtual instruments. The MIDI Data still stays the same, it is still 0-127, and if you close your eyes and simply play, I´m sure it is not numbers you see or hear. 

    But we get your point. 

    Best,

    Paul 

    Paul Kopf Head of Product Marketing, Social Media and Support
  • C
    C

    Thanks Paul. I agree with the philosophy, but I guess in the world of programmable instruments editing numbers is a bit like doing the washing-up - occasionally it just has to be done!
  • D
    D

    I guess that numbers being 1-100 doesn't really worry me. However, I would like the ability to type values in. Dragging virtual faders is not accurate. Maybe there's a way to drag in smaller increments, like in good sequencers?

    DG
  • M
    M

     Paul,

    Are you serious?
    ---close your eyes and simply play---

    Is this a new system for lonely musician?

    -Value Source Listner- (VSL)

    Take care!
    With eyes closed you'll miss the Conductor asking for Crescendo or Subbitto Piano!
    (Here Conductor means : Sequencer and user)

    Playing is more ludic of course...
    Writing and programing is more accurate!

    Especially when asking software to play...

    Best
    Sincerely yours

    Alain

     
  • T
    T

    Hello

    While defining matrices in Special Edition to work around the missing "Univeral Mode"-Presets I was running into the same troubles as my colleagues reported in this thread some months ago. I would highly appreciate if there could be an option under settings where % vs. MIDI - Controller values (0-127) could be choosen.

    As earlier reported in this thread using controller values instead of key switches has some advantages. It's possible this way to create one single MIDI-File which sounds quite well on a standard GM2 Player and serves at the same time for  better quality output on VSL using controller data which the GM2 player simply ignores. So I use V-Span (through unused CC#111 )  for explicit articulation selection on VSL and H-Span for automated speed releated selections. So I have to deal with entering MIDI-Values 0-127 into the sequencers event-editor. 

    However I can live with that at the moment - but I think that my "use case" will be more and more interesting as VSL has entered a market segment with the "Special Edition" where such requirements are important. 

    ... and thanks to the VSL team for their great product!

    Best regards, Thomas