zolko60

1.0.5 was an optional driver for all Helix models, it started support for the Stomp. 1. May be a typo. 2. Still optional and not recommended unless you need multi sampling rate operation.

"Impedance converters" are simply reversed trasformer DI boxes. You can get 20dB of boost but this is not enough unless you capture a close gun shots with dynamic mike ;). Mic pres usually have about 20-60dB range.

Look for some AES/EBU 96kHz to ADAT SMUX converter maybe? :D

10 inputs in case the optical input is used as ADAT lightpipe protocol (@44,1 and 48kHz). 4 inputs if used as SPDIF. 2 inputs if not used.

I have Friedmann BE-OD clone. IMO this is the best "brown sound" I've heard. It does the trick whatever amp you will stick to it. There is a yt EVH fan who confirms my claim.

Clarett probably has Toslink input switchable between SPDIF and ADAT protocols. There are some SPDIF RCA to SPDIF optical converters on the market. In case of LT you would need AES/EBU to SPDIF optical. Multi Output or whatever is assigned to Digital Out. AES/EBU and SPDIF are two channell only protocols. I don't think Clarett could level the incoming digital signal. You can set Hx digital output level either in output block volume or global settings. As far as I remember Hx Volume knob affects what you set in Global Settings, likely only analog outputs. (2.71 firmware state). Yes. usual input representation. ;) Should work but I would check the manual or Focusrite forums.

And if this does not work replace with a compatible tactile switch eg. C&K PTS645SL43-2 LFS

You mean OSX? I have never seen independently set buffers for ASIO drivers on Windows. All my interfaces have common buffer setting for all ASIO clients. Is this specific for Apollo Core Audio OSX driver?

Are you sure? There indeed were some changes how Steinberg implemented PC# in VST3. https://www.steinberg.net/forums/viewtopic.php?t=74526

Why? The pilot's guide says it is also VST2 and it appears as VST and VST3 in Reaper plugin list (Windows). And the answer would be simple: Program Changes are either implemented or not. It does not matter what plug-in type it is.

In Reaper you can automate and make PC# control "FX presets" changes. This somehow changes the whole plugin state including the Helix preset. So the PC#s can be used at "higher" DAW instance. I guess it shoud work in other DAWs which have their own "FX presets".

Really? I have not notice any benefit latency wise by using standalone "plugins" vs DAW/Host hosted. Pro Tools may be the exception with its CPU heavy engine. Third party hosting is also beneficial. You can workaround all HxN limitations and integrate it with the best in their class plugins. So for me there are two possible reasons of making stand alone plugins. The first is a convienience for unexperienced users not using DAWs. The second is full controll meant by two way MIDI or whatever other communication protocol. It is easy to control HxN by the controller but it is not easy to control the controller. When you change preset or snapshot you may eg. expect the software to send at least CCs that illuminate controller switches. As far as I know there are no plans to make Native compete the hardware Hx versions in live usage.

The actual difference is 9ms only by changing the driver. Resampling in case of OSX multi sample rate Core Audio does not change much unless the right way is to compare 2 times bigger buffer at two times sampling rate. If so the difference is 3ms (12ms to CC). Class Complaint OSX 48KHz 128 buffer - In 5.917 Out 4.688 = 10.605ms Multi sample rate Core Audio 48kHz 128 buffer - In 8.667 Out 10.667 = 19.334ms Multi sample rate Core Audio 96kHz 128 buffer - In 10.333 Out 9.333 = 19.666ms Multi sample rate Core Audio 96kHz 256 buffer - In 11.667 Out 10.667 = 22.334ms Source:

That would require USB transfer of signals other than 48kHz. Is this the case? IDK We are told "Guitar In" is 123dB dynamic range. Is this true? IDK Is "Guitar in" set to 1Mohm something different from "Return In" set to instrument level? IDK Are there Hx Stomp inputs/outputs any different from Hx FL inputs/outputs? IDK You mean in some documents published by Line6? I have never seen any but if the device is claimed to be Class Complaint and works as Class Complaint under OSX and the only sampling rate it reports is 48kHz you can conclude it is 48kHz.

I have almost sorted out what is going on with Helix input and output levels by my and my friends research. The professional standard for line level audio signals is +4dBu. If we assume 15dB headroom to full scale digital level (0dBFS) is the standard Line 6 has adopted then Helix has three level settings: Line level: +19dBu full scale (+4dBu reference with 15dB of headroom) Instrument level: +11dBu full scale (-4dBu reference) Mic level: +8dBu (-7dBu reference) The pad on instrument input labeled "Guitar In" is 5dB so padded input is +16dBu full scale. Hx FL/RA "Aux In" is just another line level input. The Volume Kob is a digital attenuator assigned before chosen DA converter(s). Now let's see what is happening when we interface Helix with Yamaha MG06 mixer by XLR cable: Let's input -4dBu sinus signal to Guitar Input. It will appear at Hx XLR outputs set to mic level as -7dBu. MG06 mic preamp gain range is 20-64dB. At minimal gain position we get +13dBu. Getting unity gain is not possible without engaging mixer 26dB pad. Using DI box is better because they usually attenuate an amplitude by 18-20dB (plus some padding). -4dBu input signal appears at Helix XLR or TRS outputs set to line at +4dBu. After DI box -14dBu. At min mic pre gain we are near the unity. What I don't know is if Hx FL/RA mic input is set to the same mic level standard (0dB gain=-7dBu reference with 15dB of headroom=+8dB full scale). I would appeciate if somebody could confirm that. Thank you for your attention and research cooperation. :) Yamaha MG06 manual http://shopwl.com/content/MG06 Mixing Console - Manual.pdf

In what sense they are 192kHz while Hx has 48kHz clock? Do they make some on chip oversampling?

Well, this is not an "issue". You record 48kHz audio but you process and store it at 96kHz. What you monitor is 48kHz because your interface works with 48kHz sampling rate. On the fly resampling induces some additional latency and this is why 48kHz Class Complaint usage on OSX gives the smalest latency. The only reason to use other than 48kHz sampling rate with Helix as USB interface is compatibility with 96kHz sessions on some DAWs.

You have four phisical inputs hardwired to four USB inputs (5-8). 1-4 are processed signals connected to those phisical inputs (or taken from USB output). Helix works at 24/48. 96khz is done by driver resampling. You can expect problems with monitoring when Hx is used as your monitoring center. Round Trip latency is quite high so monitoring thru DAW is problematic. Conclusion: Using Stomp ar even Floor/Rack as an main audio interface may not be a good idea.

"(...) I have posted I can't remember on whose page recently that we are working our asses off (...) We gonna alter the calendar (...) move spring out, shorten the summer (...) I would say within the next two weeks (...) If I am wrong and I am wrong all the time (...) we will update my mistake to the team...) I think we are very close, you know measure twice cut once kind of thing (...)" 1:09:00

I would prefer to help you with "no but" solution but I can't. :(

Split Crossover goes down to 25Hz.

I suppose there may be more solutions of your puzzle (not easy one without snapshots). 1. If we define the task as "how to construct A/B, Y, Bp switch on parallel paths with constant dry level", we can use: - delays mix parameter automation as bypass (mix=0 bypass on, mix=100 dry kill) - single delay dry path as a dry path for both - multiple FS assigments Expected issues: - not intuitive FS illumination - trails mutes 2. So maybe A,B, Bp would have nicer solution? 3. Or maybe it's better to automate some multitap delay? While I am away of may hardware Hx LT and Native has no multiple assigments I leave it to somebody else ;)

Now I have realized my way is maybe the same as setting delay time to different division by FS, so maybe you could skip one delay. :) There is no volume compensation in splits. When you route signal by both paths you double it.

You set multiple assigment. Set both delays bypasses to the same FS.