Helix Native : insert ir's plugin between path 1 and path 2. Possible?

[MrViv]

Hello guys,

 

I recently bought Cubase Elements 9.5 and Helix Native but I'm quite a noob with DAWs. I'd like to insert MixIR between path 1 and path 2 to allow me to easily try and mix ir's and keeping my pre and post amp effects.

 

Is it possible with native?

 

Thanks.

[bsd512]

Just guessing here - maybe someone else can answer more definitely. Even if it appears that pathing might not work, it still might be possible. I don't use Cubase, but I'm pretty sure in Logic you can add multiple Helix Native instances to a single track - one following the other. So the output of one would feed the input of the other. If you can do that in Cubase, you could do that and put a MixIR instance in between them. Then set up your path 1 on the first Native instance, and you path 2 on the second Native instance.

 

Maybe?

[MrViv]

Thanks for your reply.

For sure I could do that, good idea.

 

In fact I'd like using 1 instance to have all effects in 1 patch but if it's not possible, at least I have your solution.

[soundog]

@MrViv: FYI, there is a separate Helix Native forum. But since you asked here, @bsd512 is correct that you could use 2 instances. It could be done with a single instance if Helix Native supported digital Send and Return blocks (similar to the hardware units, but for allowing signal routing in and out of Helix Native to external effects plug-ins, without requiring two instances of the plugin). There are plenty of free IR-hosting plug-ins that you could route your Helix Native signal to. If you like, you can vote for the Send/Return feature in IdeaScale:

 

Here's the link https://line6.ideasc.../idea-v2/915257

and here's the Idea Scale submission:

It would be useful to have a "send" block to route the digital signal out of Helix, where the user could then route through external DAW plugins, and then back into a Helix "return" block. This would be similar to using Sends and Returns in the hardware unit to use external pedals.

Example: Track 1 Helix Native (amp + cabinet) ---> virtual Out Port 1 ---> Track 2 other plug-ins ---> virtual Out Port 2 ---> back into Track 1 Helix Native (after the amp + cabinet blocks) --> final Out

User could, for example, use a third-party IR loader that access a larger library of IR files, without having to load them into Helix Native. Or, user could use favorite high end compressor EQ, or effects plug-ins within the Native Helix chain (rather than being restricted to before or after Helix Native).

[MrViv]

Oops my bad!

 

Anyway, thanks for your replies guys!

[bsd512]

Good IdeaScale, soundog. Upvoted.

[Lachdanan0121]

The only thing about that IdeaScale that I see would be a problem is the latency increase by going virtual out into the DAW, process audio, then back into the Helix. It would make playing feel unnatural. OR it could cause massive phasing issues. I don't see how this could be implemented without a noticeable increase of one, or the other, or both. 

[soundog]

@lachdan0121 - would cause no more latency than the plug-ins used already cause. And phasing would not be an issue whatsoever. I've tested using 2 instances.

[Lachdanan0121]

@soundog:

I was speaking from the point of either performing, or wet-monitoring just with Helix as the comparison. If you are already playing that way with added plugins in a DAW, then I guess it wouldn't bother you that much. However, for me it would be unacceptable. Though I will admit I am just a slightly above average guitarist to be fair, probably no where near the skill of some of the guys on this forum, perhaps including you. 

 

I mainly just wet monitor with Helix only (with basically the same patch I use in Native when I ReAmp) no perceivable latency. Then when I ReAmp with Native I use other plugins which add latency, however I am not playing it, and the DAW uses an automatic plugin delay compensation.  

 

I don't mean to belittle your idea, I just don't see its usefulness myself. I won't campaign against it, or anything. If it would truly benefit you then I see no problem in adding it. Won't hurt me to treat the feature like it isn't even there. That is if it won't take some crazy dev time, then again I got most of what I am wanting out of Helix, and with its trajectory of updates I will more than likely have the rest of what I want anyway given another year, or two. So I really shouldn't care even if extra dev time is put to things I may not need in this unit. Though I am sure you know other members of this community may take a different stance on that, event though most of what they could want out of the unit is already covered... just like me. So more power to you, as long as it doesn't change functionality in a way that impedes me.  ;)

[soundog]

LOL. You won't be harmed in any way. :) This is more for recording purposes within a DAW, not live performance — as Helix Native was originally intended.

[Lachdanan0121]

LOL. You won't be harmed in any way. :) This is more for recording purposes within a DAW, not live performance — as Helix Native was originally intended.

lol I don't do live, I only really record in my DAW. That is what I mean't when I said wet monitoring above, I should have clarified that to be while recording. 

 

For me once the guitar is recorded in the DAW the latency doesn't matter anymore then I send it through more elaborate signal chains with Helix Native usually with split instances like mentioned above. (with 3rd party plugins in between them)

 

I think you want your plugins in your Helix (hardware) signal chain while you wet monitor/record via virtual usb FX loops.  Which I would love too, if it wouldn't be for the added latency. Helix alone gets me about 80-85% of the way there though with none, so I am happy with that for a wet monitor. (I always dry record, and ReAmp afterwards)

 

 

EDIT: I am sorry! You are talking about Helix Native lol, I thought you were talking about doing this with Helix Hardware via USB. I might need to go ahead, and get some sleep, I am not sure how I confused that as now that I re-read it you clearly stated Native several times.  :lol: Well then forget most of what I stated above, I thought we were talking about implementing this in Hardware.  :P

 

The only problem I can see doing it in Native is if Native, or the other plugin, don't report latency correctly, and that might mess up some DAW's Plugin Delay Compensation. But yeah, I would be for that. It could reduce instances of Native used, and reduce cpu load in larger projects.