Vienna Symphonic Library Forum
Forum Statistics

194,472 users have contributed to 42,922 threads and 257,973 posts.

In the past 24 hours, we have 3 new thread(s), 13 new post(s) and 77 new user(s).

  • Guys,

    well, sorry if I have been hijacking this topic, but I think this might be interesting for some of you. Why I tried other softsamplers than EXS24 is, because EXS is not yet multi-mode-capable. As I want to be able to play perf.-leg's with velocity-switches dynamically, I searched for a way to be able to split MIDI-data by velocity to succeeding MIDI-channels (e.g. Ch.1: p, Ch.2: mf, Ch.3: f).

    1. Logic+HALion+VSL:
    First I solved the HALion-multi-channel-problem by deinstalling/reinstalling HALion (isn't life stupid sometimes?). Still no way to get multiple out's though, since Logic doesn't recognize and list HALion 2.0 under "Multi-Out".

    Now as I said, except some multi-layer-crossfade-patches all VSL-patches I tried play fine on HALion 2.0 and as intended (used CDXtract 4.1.2 for all conversions: it's a MUST for anyone willing to encounter a VSL-Giga-import). Unfortunately for the Perf.-legatos HALion behaves different from Gigastudio when keyswitches are being used:
    Obviously all non-mapped and non-keyswitching notes cause HAL to play NO MAP AT ALL. I realized, that the Perf.-Tool is rarely sending a C-2 (when does it do this and why - anyone?), and since keyswitches are starting with C#-2 this causes HAL to stop responding to incoming notes - very irritating. I set up a filter-object before the Perf.-Tool-data is getting sent to the Sequencer-Input (Logic-environment, of course [;)] ) and it worked fine then. Using my special Logic-environment to alter MIDI-channels by velocity, I was able to play the desired dynamic VSL-legatos.

    2. Logic+Kontakt+VSL
    CDXtract converted all VSL-performances I tried fine, but I guess some crossfading combinations will not import properly. Kontakt worked perfectly well using the perf.-legatos at least, either externally switched or not. Then I stumbled across the most interesting Kontakt-feature regarding dynamic legatos:
    There is no need to use complicated swichting/processing, Kontakt simply allows to set a velocity-range for any instrument WITHIN ANY HOST. So if you load e.g. the 3 separate Flute perf.-leg grace-dynamics (p, mf, f) and set the velocity ranges from 1-70, 71-100 and 101-127, you get a perfectly playable velocity-switching VSL-legato-instrument!!! WOW!!!! This is fairly impressing. Now that I still used my virtual channel-switching, I was able to get e.g. dynamic-legatos on channel 1, crescendo's on 2, diminuendos on 3 and staccati of that Flute on channel 4 - in real-time!

    CONCLUSION:
    If you are interested mainly in playing back VSL-perf.-legatos and standard articulations, Kontakt seems to be the far better choice. The velocity-range-thing is the killer-feature for dynamic legatos in seconds. Besides, on my system (Athlon 1700+, 1GB RAM, VIA KT266A-chipset, dedicated fast Sample-HD, Windows XP) I was able to make Kontakt use less than 2/3 of the smallest RAM-buffer applicable to HALion 2.0 - while streaming glitch-free. As I am able to get up to 4 dynamic legato-instruments+some basic articulations with that system and I plan to run the woodwinds from Kontakt, I don't need those high polyphonic counts, that make Kontakt use too much CPU-time. Kontakt did't need any more CPU-power than HALion - at least for that specific task and on my system.

    All the best

    Roman

  • yup I tried that velocity range thing too Roman, works nicely [:)]

    I still want to program it all into one patch tho, and make Xfade variations...etc. Quite easy to do tho if you ask me. I'm jsut on other stuff.

    I quite like Kontakt to be honest. Some of its features are goign to help me get some incredibly unique use out of all my libs.

    However I still find it has alot of bugs. While I generally dont worry abou tthem sinc eI find workarounds, it would be nice if it wasn't chock full of them (and some really bad ones too)

  • Hi King,
    yes, I was thinking of putting all this into one patch, but I am too lazy and I am not sure, if the Kontakt-strucure allows to set up vel-Xfaded keyswitch-patches. Besides, I don't worry about instrument-counts as Kontakt works well in multiple instances.

    As you are talking of Xfade-layering, this can be achieved in Kontakt very easily, too. E.g. a 3-layer MW-Xfade-ensemble can be set up like this:

    1. load all 3 dynamic layers
    2. assign all to the same channel
    3. set the p-layer to respond to velocity 1-64, the mf layer to vel. 1-127 and the f-layer to 65-127
    4. insert a mod-wheel>volume-modulator for each group of each instrument (isn't there a way to edit all groups globally??!)
    5. set the mod-wheel-curve of all groups of the
    a) p-layer to go from 0>127 to 64>0
    b) mf-layer to go from 0>0 to 64>127 and from 65>126 to 127>0
    a) f-layer to go from 65>0 to 127>127

    These values should be considered as a basic concept. Fine tuning the curves will be worth it to get smooth Xfades etc.

    Happy Kontakting!

    And:
    If you have some RAM left on a GS-machine, that GS is not able to allocate, then it might be possible to run Kontakt as stand-alone simultaneously and make it stream its samples from a separate HD to eat up the rest of RAM and provide more of these excellent VSL-instruments...

  • ITs quite easy to build Xfades into one instrument. Just make seprate groups for each dynamic, then assign a CC control to the Volume for each group (mod wheel is simple), then create the curve scaling you want for each group, jsut like you'd do in giga, except you can make it exponential if you'd like.

    This is all from thinking of the interface without looking. I'm by no means a Kontakt expert, jsut a Tweak head that tends to try and figure things out in his head before actually trying....its a bad habit of mine. Things tend to look alot easier this way....but then I realize it takes forever. Its how I come up with those weird script ideas, eh herb? [;)]

  • Maybe we could set up a database over here for well edited/converted .nki/.nkm- and .fxp/.fxb-files (without the wave-data), so that any registered VSL user was able to get/share cool mappings for the sounds he already is licensed to used??! Would you VSL guys support such an "exotic-format-exchange-user-database "?? Why should we all construct nifty programs, that others of us might have already being constructing?!

    Any thoughts about this??


    Roman

  • Great idea, Roman -
    this would make all the things a lot more easier (and faster [:D] )
    (Just imagine to translate the complete package to HAL / Kontakt - by your own - AAArrrgghhh). With sharing well translated nki's /fxp's everyone has to fight only a "part" of this nearly endless battle.

  • Roman,

    Great idea! I'm very much into Kontakt as well but use VSL in Giga for now since it just works... As soon as I get some more free time (after my next dead-line) I'll definitely start to explore some cool things that should be possible with the VSL sounds and the Kontakt engine!

    One thing though... The different conversion tools have their own way of naming the resulting wave files. Personally I have Translator and CDXtract in addition to the internal conversion within Kontakt so I guess I'm well equipped, but in order to have this working you/we/herb/cm need to set a common ground on issues like this since only the nki's/fxp's can be distributed.

    Herb and Christian, you have to agree Roman has a good idea here?! [[;)]]

    /Mattias

  • Very good idea,

    we'll install an art and x-file (whistling) sharing section in the user area.

    best wishes
    Herb

  • good to hear such considerations. a kind of file-exchange for .art- and .exs-files is already planned - if herb is fine with expanding it to .nki/.nkm- and .fxp/.fxb-files, no problem.
    regarding naming-issues: there is already a difference between the names of the waves within the .gig-files to the .wav-files within EXS (you know, this bad 31-letters-issue) - it should be possible to setup some database for synchronizing the different naming-conventions
    christian
    ps: please don't expect it to be up and running *tomorrow* - a lot of tasks is already in the queue

    and remember: only a CRAY can run an endless loop in just three seconds.
  • Hi,

    I had some days off until today and, well, I am very happy to see, that there seem to be quite some positive reactions and - best of all, Herb likes the idea as well. Thank you (and your team) for your cooperative and effective attitude once again. I have seen so many companys rejecting efficient ideas just because they feared to loose their "absolute power" and control over their products!

    Yes, I have been aware of the naming issue and I was just curious with what you guys come up with. I will bug Bernard of CDXtract to implement a conversion-option that would provide an intelligent function to re-reference and fix the wave-file-links within any .exs, .fxp or .nki-file without having to re-import the whole wave-data. I am thinking of

    1. A search-algorithm, that would find waves within any kind of (sub-)folder-strucure
    2. A renaming-algorithm, that would even be able to re-reference files that are named differently according to a pre-defined condition-set

    If anyone had a good wire to Garth of Chickensys, maybe he would be interested in such a very helpful option, too. This even seems to be no real "VSL-special", IMO it was very helpful for ANY user to be able to use exactly the same wave-pool-folder for a .nki, exs and/or .fxp-patch at the same time.

    Cm, how could such a database-thing look like in the real world? Sounds very interesting, but I have no idea how this could be done.

    All the best


    Roman