when is the next fix ?

Brian_Roland · October 19, 2016, 11:52pm

GIRO:

Brian Roland
I’ve been with HALon since it came out…
GA4 is also heavy on the CPU. There is no one here more supportive or loyal to Steinberg products than me, but the fact that HALion is not being serviced is a slap in the face to me personally. I don’t want alpha or beta updates… I want the issues fixed and user content handling as well. I have been inputting all this to them since H4 came out. Users (or programmers I should say) should be able to use the macro page and the programmer should be able to ad artwork and parameters there. Have you tried to play back a bunch of HALion tracks in high or extreme quality? Its pointless.

CPU overload with a simple stereo sample in grain synth mode. 4 or 5 standard fx added. PADSHOP is also CPU abusive. I never go below 512 samples buffer size to work in peace with a more than capable computer.

GA4 with all its bells and whistles of high end effects makes it difficult to use it along side HALion and Padshop pro. I remove all the plug-ins and send all the pads to their own output to mix later in audio stems. Also the fact of its last decade limitations of not being able to handle more that 8 layers per note is very disappointing to me. mmmh My snare drum has 28 layers of velocity. Tom Toms go over 8 layers as well… Don’t want work-arounds, I want capabilities for the $$$

HALion is also a pain to import multisamples per note. when you do more than 8 samples at once per note, it goes bananas. Makes a mess.

I’ve been at work some times for long periods of time and the sucker crashes and I lose all that work. All user content does not show up in the main loader. (since 4 up to now, user content has been a pain to manage)

My reason for using HALion has always been the quality of the engine and sample quality.
Even in “standard mode”
Its library when it came out and the quality of the recorded samples by WIZOO back then. was limited but was good and I was finally able to drop my Soundblaster with its Synth chip that let me create my own library in SF2 and I had a large library of Sonic Implants library now called SONIVOX. I had the Neundo-RME interface.

Led down content: I have never used the little drum b-box that they added nor the so called ethnic instruments, and world percussion… those are a joke to me.
I also see a lot of repeats with the synths… They all are the same synth with different GUI. (kind of like new patches with their own GUI) Auron is Padshop - Retrologue sounds like HALionsonic and so on! I know because I fiddle with them all the time and I make patches all the time. I don’t sound design for Steinberg just to be clear.

The reason I use HALion is for creative purposes and the fact that I can’t stand KONTAKT but Kontakt has so much library that it would be embarrassing if I was the brains at Steinberg HQ

I’m not having the same issues, with GA4 nor H5. They’re the most efficient sampler and synth engines I’ve ever tried on this old AMD system (Second only to ARIA/sforzando running decades old libraries that were optimized for low end machines), but it would seem we take very differen approaches to designing, loading, and playing the programs for the instrument. A poorly thought out patch/program that’s grabbing resources it doesn’t really need at the moment isn’t quite the same thing as an abusive ‘plugin’. To me, part of the irony is that people are demanding the ability to more easily make overkill ‘abusive patches/programs’ while claiming that the plugin is already too power hungry. You want 24 velocity layers on ‘MPC’ trigger pads…well…that’s going to need either more memory to cut down on communication between the CPU and the bus, or more D2D action that’s going to need more CPU cycles moving chunks of data in and out of disk buffer memory…

I’ve not yet found an equally featured Alternative that’s any more CPU or resource efficient than H5. Sonivoxx plugins are the WORST on my machine (I still buy some of them because I like they way they sound, the prices are fair…they’ve got some really nice samples that are well tuned/balanced, etc…but my PC can’t really use them LIVE in real time…the playback engine is so bad on my PC that I’ve even resampled a good bit of the Sonnivox Orchestral Companion series for personal use in Halion).

The similar or redundant synths in Halion have been really helpful for me…since it’ll run in all my Hosts…where as some of those ‘similar’ synth engines that ship with Cubase…only run in Cubase…not with my other hosts.

It’s pretty rare that I’d put more than 8 ‘velocity’ layers on a single MIDI trigger. Foremost because I can’t afford controllers with MPC pads or key beds sensitive enough to actually have control over more than 16 velocity layers, and even 8 is a serious stretch for any of my ‘MPC’ pads. The velocity resolution/sensitivity just isn’t good enough on the majority of inexpensive or moderately priced MIDI controllers on the market. While Cubase does offer some options to artificially ‘expand’ the curve a little in the track inspector, and H5 and GA4 also allow some adjustments to how the velocity curve is interpreted…it’s still not really good enough for 24 layers.

Essentially, 24 layers is a resolution or interval of only “5.333ee” (128/24) per layer trigger. I’ve never been able to afford/own a controller sensitive and precise enough to get control of resolutions that fine. I’m pretty sure Steinberg researched this in their labs by connecting many different makes and brands of Controllers and recording ‘averages’ of the velocity messages that are actually being sent. So…for all but the most extreme of patches, on the best of equipment…24 velocity layers on a single MIDI trigger/note is overkill. Trim the patches down some, or spread them out over multiple triggers/pads/keys in a way that is more useful/playable. If the content is intended to ever be sold or shared…you’ll DEFINATELY want to include ‘lighter’ variants of the patches. Most of us will never realize the potential of a 24 velocity sensitive layer drum or cymbal patch with a single MPC pad trying to trigger it Bad patch design for ‘most’ users needs and equipment…only good for people with finely tuned ‘MIDI Drum Pads’, who will be using real drum sticks/mallets to play them (and such users will probably want to host sound engines for that on a separate PC (or at least a dedicated core or two that is allowed to discretely run at maximum speed [I use Plogue’s Bidule for projects that need discrete processing…quite a few folks out there swear by VEP for similar purposes]…independent from the DAW).

If I were doing an intricate marching snare drum, or something with 16 layers or more velocity sensitive layers I"d much rather split it into left-stick and right-stick pads or keys, as well as different triggers/pads for general ‘dynamic ranges’ and ‘head striking positions’ than cram it all onto a single trigger. For me at least…it’d be a far more playable instrument spread across more triggers/notes. It’d also be easier to manage (for me at least) in things like key and score editors.

If I had a really nice stick/mallet-driven drum pad controller sensitive enough to actually trigger 24 layers with predictability and reliability, and if I were a good enough drummer to actually play such an instrument…I personally would NOT be using GA4 in that case. I’d be more inclined to use Halion 5 instead (or better yet, audio track real acoustic drum loops), and I’d split it into cross fading layers with a continuous voltage foot controller to cross-fade between playing at the center of the head vs near the edges, etc. (or if it was really fancy pad that has that cross fading capability built in…it’d still be spread across different crossfaded layers or MIDI trigger notes). Also, instruments that are sensitive and precise enough to play things like 32nd note drum rudiments at 24 velocity layers in 120 BPM and faster would need to be isolated enough to get a core of its own, and it’d be more of a ‘solo instrument’ that’s ultra exposed in the mix. It’s not the sort of patch I’d expect to load up in a multi-timbered set up on a ‘single PC’ rig where the ‘sounds’ AND the ‘DAW’ are being hosted on the same mid-range or consumer level computer (A higher end PC could easily do it with a discrete host rewired or loopMIDI on the same system…in short, don’t blame the Plugin if the host is managing the CPU cores, keeping things synced to a common and strict clock, and won’t let it run to peak speed and efficiency).

GA4 is more designed to trigger pre sampled rudiments or loops. I don’t think it was ever really intended to be driven by a MIDI controller capable of realistically using 24 velocity layers on a single note/pad. MPC machines require a different approach, and one can still make amazingly complex and ‘playable’ drum kits. Use the banks and pads…spread that stuff out. You’ve got 128 of them by four agent kits (512)…so spread that stuff out so it’s playable on el-cheapo mushy-yuck MPC pads and gooey rubbermaid capacitance based keyboard velocity sensors flooding the current market-place. This way the engine doesn’t have to work as hard to manage stuff that you might not need loaded or managed in and out of D2D streaming buffers at all times. The user can call up exactly what he needs on demand with less system overhead and bloat.

More on 24 velocity layer instruments:
I’ll use the Sonivoxx 88 Piano plugin as a reference point. It’s a latency and CPU beast on my system. This ONE plugin, for ‘just a piano sound’ is one of the most CPU/Disk intensive plugins I have. I suspect the issue with this plugin’s play back engine is simply that it won’t let me increase the amount of samples it keeps in memory…it wants to stream everything from the massive sample set D2D over and over again…and my particular system isn’t crazy about that. So…I must use the lighter 4 velocity layer versions of Sonnivoxx 88 patches when I’m ‘playing live’ while also playing back other VSTi tracks, and temporarily change to the 8 or 24 layer patches and instant render them later. Such patches can be really demanding on system resources! I can’t really tell the difference between the 8 and 24 layer versions unless the piano passage is playing the same note in a really small velocity range over and over again at a high tempo. So…for more than 90% of my compositions, 8, or even 4 layers is plenty…occasionally I need the 24 velocity layer version for really dynamic passages that pound on the same chord or notes a lot in a short time-span…but it’s pretty rare…so I just load it long enough to instant render those passages later in some of the mix-down processes.

In contrast to the single 88 Piano plugin…I can load up H5 and get some 40 tracks out of it before it chokes and requires extra attention such as rendering some things to audio tracks before moving on. I know for a fact Halion is asking for some 400 or more voices and still NOT choking…while the 88 Piano plugin chokes things with nothing but a single 24 velocity layer piano patch loaded (granted it’s a FINE piano, with damper samples, and so much more…but I doubt it’s asking for more than 400 voices at a time).