adamqlw
Members-
Posts
8 -
Joined
-
Last visited
Everything posted by adamqlw
-
I managed to get this permanently sorted for myself, sharing the tips so everyone else can avoid the same user errors I did. I am running a Surface Book 2, FYI. Firstly, it does not like being made to run high performance in clamshell mode, as heat dissipation is not optimal. This causes the system the throttle the CPU, in my case down to 0.8 gHz… meaning there was no longer enough processing power for real-time processing. Cue the emergence of clicks and pops. This is exacerbated by moving the power slider to “best performance”, which you need to. When not in best performance mode, the CPU frequency is throttled dynamically to conserve power. As it throttles up and down to meet shifting demands, it hits the point where real-time output suffers, creating the odd click and pop. Also, my CPU has 4 physical cores and 8 logical ones. Cantabile and Reaper identified this as 8 cores, and defaulted to running multi-threaded with 8 cores. However, because real-time processing is critical for audio, this actually resulted in more clicks and pops. Manually setting this to the number of physical cores (in my case 4), solved the problem. In summary: Clicks and pops were related to CPU throttling down due to heat, CPU throttling down due to power conservation, and the DAW trying to make use of all logical cores instead of all physical cores. Making sure your mobile system is sufficiently ventilated, your power setting is on “best performance”, and your number of cores is the same as your physical number fixed this for me. Previously, I was unable to run a single heavy load patch (drive pedal, compression pedal, 2 amps, 2 2048 IRs, stereo delay, reverb, chorus) without clicks and pops. Once I had all that sorted out, I managed to get 8 instances of that heavy-duty patch running at a buffer of 96 with 2 ms latency… Now I’m satisfied (also, embarrassed of my user error and pleased with having resolved it). Hope this helps anyone else who’s run into problems.
-
So I have now unfortuantely run into this issue. I have a 13.5" Surface Book 2, which should be plenty powerful for Helix Native. I made a complex patch utilizing 2 chains, the top has amp+2048 IR+2 EQs+delay, and the second chain has amp +2048 IR+EQ+Mod+delay. This patch seems to be maxing out a single core, causing a bitcrush type effect and clicks/pops. Raising the buffer helps just a little bit... but if I split the patch into two seperate patches, each being just one chain, it works fine. Initially I had planned to use scenes to treat a single patch as a stereo rig... this has brought my system to its knees for the tones I'm going for. So I've gone back to use 4 seperate patches. It's good enough for now, but it does make me wonder whether more optimization needs to be done, or if there is some way to make the plug in multi-threaded... or if there's just something wrong with my config.
-
Hi guys, I spent some time putting together a workflow to edit Helix Native with my SoftStep foot controller, attempting to mimic some to hands-free editing functions of the Helix. The process was quite simple. Each preset on the SoftStep has 10 buttons. I created 7 presets, outputting 2’s complement MIDI CC messages in various increments (±1, ±2, ±5, ±10, ±20). This is the mapped onto the Helix VST’s knobs 1 to 7. I further map knobs 1 to 7 to drive, bass, mid, treble, presence, drive 2, and IR selection. This can be done in MainStage on the Mac, or Cantabile on Windows. It’s also doable within your DAW (I managed to get it working in Reaper) Now when I step on the SoftStep, it increments/decrements the value. I go through each parameter, starting with big jumps (±20) and then narrowing it down as I go along, until I have arrived at the sweet spot for the parameter (kind of like a Newton-Raphson optimization). For the IR block, this lets me step through my IRs. I do a quick pass through my IRs and note the few that I like for the amp, then I temporarily group them together in the IR library so I can step through them sequentially hands free, until I settle on the one I like. I note the IR slot it is stored in, and delete the temporary group. The SoftStep does this quite handily because it has 10 buttons, but this workflow would easily carry over to any MIDI controller. Even for control by hand, you could create a template to increment/decrement each variable in something like MIDI pad, so that you can just tap to goose/cut parameters a little, rather than having to input the data by hand or mouse control. Even simplifying this down to just one knob, and binding the knob to the parameters one at a time, I found to be quite useful. Hope you guys get some mileage out of this, happy to talk through the steps to get this working if anyone is interested. Looking forward to more Helix Native tips (and updatesJ)
-
While this is important to ensure that there is no harsh clipping at the input of the sound card, it does not solve the problem. To clarify, I am referring to pre-Helix native input *linear* gain, i.e. pure clean volume adjustment, absolutely no distortion/compression. This discussion can take place *entirely* in the digital domain, after any A/D conversion on the interface, which means the headroom before distortion is not relevant to the discussion. Consider the -12 dB peak INSIDE the Helix plugin. Does this represent the peak output of a high output pickup? If I am using single coils and I adjust the gain so that Helix Native sees -12dB, then when I utilize an amp model with a bright cap, the gain settings will be lower than they are in the “real worldâ€, which also means the tone will be brighter than expected. Cliff Chase describes it as such: “On a real amp this is implemented using a variable resistor called a potentiometer. Many amps include a "bright cap" on the drive control which is a small value capacitor placed across the terminals of the pot that bleeds treble frequencies through as the gain is reduced. Sometimes this bright cap is switchable via a switch on the amp. Sometimes it is fixed.†Cliff also provided some insights into levels one might need to pay attention to, although these are only relevant if there is a known constant at the input stage of the model to calibrate to… “… is 24 bits. This is 144.7 dB of dynamic range. Full-scale is about +20 dBu. So even if your guitar is -20 dBu (-40 dB re. FS) you still have over 100 dB of dynamic range. A typical single coil pickup can easily exceed -20 dBu. A humbucker can easily exceed 0 dBu. Full-scale of 20 dBu gives you a few bits of headroom in case of very hot pickups. The self noise of a guitar pickup and associated electronics limits its dynamic range to less than 100 dB typically.†One can of course ignore all of this and “use your earsâ€, as we have always done. But if modelling is truly that accurate, then it seems a waste to throw away decades of real-world experience that most guitarists brings to modelling units, instead of translating real-world paradigms to their digital equivalents.
-
Camping for replies. This is exactly the same issue being discussed here (http://line6.com/support/topic/29135-setting-input-levels/) i.e. how do we calibrate input levels so what's happening in the plugin version is the same as what's happening in the Helix Floor.
-
The most useful indicator would probably be peak levels for singlecoil/humbucker/high output humbucker. It's not a precise solution to the problem, but it would help narrow the range of error significantly. Someone with a helix could actually measure this by recording the DI signal for those categories and noting peak levels. Alas, I only have native...
-
This is really a problem of gain staging. If one completely ignores the signal to noise ratio, the question is: how much gain should be applied prior to the helix input stage so that the signal is calibrated to a known level. This matters because distortion is non-linear, so the order gain is applied is critical. Pre-distortion adjustments have dramatic impact on tone, while post distortion adjustments affect only volume. Even clean tones are affected if they rely on compression from the amp.
-
I have had exactly this problem since forever every VST that I have used. Not clipping is one thing, but having the input stage of the VST see something that is “calibrated†to a known real-world constant still remains elusive. The thing about gain staging is that it the order matters. The unity gain idea twpmeister mentioned would solve this. It’s been utilized in the Axe FX 2 (input gain only optimizes signal to noise levels, so the amp inputs react appropriate to pickups with different output levels), and in a way in the ElevenRack as well, which had a fixed input so you there was no question of how much gain to apply. I was quite excited when I first saw DigitalIgloo mention that the input gain settings would be discussed in the manual, but looking at the details, all this will do is make sure the guitar isn’t clipping the interface input. I’m still looking for a way to find out how much gain to use to bridge the gap between what my DAW receives and what the dry out of Helix (hardware) delivers. Ideally, we want a way to zero our DAW input to the Helix DI output. Some thoughts I had earlier on this, if anyone is interested. “ I don’t mean to generalize that single coils have output of 100 mv and humbuckers have output of 300 mv, but rather something less specific. For example, according to the DiMarzio DiMarzio’s “standard strat†single coils have an output range of 130 to 200 mV. Hum-cancelling Dimarzio strat pickups have an output range of 90 mV to 325 mV (the 90 mV being the unusual low-output Malmsteen pickups). DiMarzio vintage output humbuckers range 178 mV to 285 mV DiMarzio medium power humbuckers range 250 mV to 352 mV DiMarzio high power humbuckers range 325 mV to 510 mV If we take 90 mV to 510 mV to but the lower/upper bound of what the input should be receiving, and convert that into zones on the input meter, then we could reliably adjust input gain by aiming for those zones on the input metering (which can be done independent of setting input gain to optimize signal to noise ratio on the hardware), and not by ear, to match up accordingly with the pickup being used. This would take a large part of the guesswork/â€use your ears†out of the equation, and brings the modeler closer to a real-world plug-and-play solution. As I understand it, there is no standardized way to measure pickup output. How hard one hits, the type of pick, etc, all confound the process of measuring output. But even without that precision, the broad buckets could be effective in making modelers more accessible to the average guitarist. As you say, backing off the input trim can emulate the lower output guitar hitting an amp, but the question that has stumped me is just how much to back off. While I can use my ears, part of what I like about using different guitars is how simply changing guitar has a generally predictable impact on tone, which is a function of both the overall response of the pickup as well as the output level. Maintaining as much of that framework in the virtual world seems like a net benefit. Basically, it feels to me like modelling is pretty accurate but the question mark is how to calibrate input to mimic “real world†application. This seems to have been solved in hardware on the ElevenRack and Axe FX, because the input sensitivity is known and can be compensated for. Hopefully there can be a way to come close to mimicking this by indicating certain known values (i.e. pickup type) to calibrate the input to.â€