..

…Or better two sliders: dry level and wet level, so you can pass thru the dry signal without volume change and add some wet signal.

…Or better two sliders: dry level and wet level, so you can pass thru the dry signal without volume change and add some wet signal.

I think I prefer this method. I`ve noticed that with the slate VBC compressors sort of emulate this but still using a mix knob. First you set your mix level then the make up gain controls only the compressed signal.

Actually thinking about this it wouldn`t matter too much as in a doofer you can always insert a gainer in the chain to exactly the same effect as the slate method.

…Or a dry/wet container, that is capable of containing another dry/wet container, and placable into doofers…

…Or an hidden, openable advanced options for any plugin / vst / doofer, containing:

  • dry/wet

  • gain

  • phase rotator

  • lp / hp / bp (linear phase + EXACT matching values, so a 2khz LP + a 2khz HP will result in perfect sum)

  • send target for wet output

Last variant would be my personal favorite… Seems to be the most logical variant for me.

I think I prefer this method. I`ve noticed that with the slate VBC compressors sort of emulate this but still using a mix knob. First you set your mix level then the make up gain controls only the compressed signal.

Actually thinking about this it wouldn`t matter too much as in a doofer you can always insert a gainer in the chain to exactly the same effect as the slate method.

Just to say that I had this a bit back to front. The workflow as I understand now from further reading.

  1. Compress the signal

  2. Match the 100% compressed signal in volume to the 100% dry, by ear.

  3. Now use the mix knob to find your level of effected signal vs dry.

This makes a lot more sense to me as a workflow now. Bit of a forehead slapping moment when I read it! :blink:

So having post-gain on the effected signal certainly goes hand in hand with a mix control, so that your last move is simply adjusting the mix value. The volume stays consistant while you are doing this.

Beats having separate dry and wet levels where you are juggling volume levels - The last thing you want to be doing while A/Bing

So my vote now is for Post fx Gain → Mix parameter on all effects. I`m all for being able to do more complex stuff with the doofer but this is commonly useful enough not to be dependent on the doofer IMO.

If expanding further, having a Pre-fx Gain inversely linkable to the Post fx Gain can be super useful too for driving fx that have an effect on dynamics, (or that benefit from being driven at different levels). I tried this already with two gainers in the doofer but as the sliders are exponential, so things start to get wonky with the ranges.

This is something that bluecat gainers can do (and Patchwork). It would be much less clunky to have natively.

http://www.bluecataudio.com/Products/Product_GainSuite/

Don’t forget that it would be nice to have real parallel processing, too! So multiple wet signals in parallel must be possible. So our post fx solutions will not work!

Instead, what about introducing a “parallel container device” which

  • provides two slots, let call them dry and wet slot, though both can be both

  • there is one mix mini slider

  • get gain by adding a gain device into the slot

  • the parallel device should work in a doofer, and in a doofer’s doofer

  • You could phase rotate, compensate whatever by using existing dsp

  • You could place a parallel device into one slot of a parallel device

  • The parallel device could provide 2-5 slots, to prevent parallel in parallel device

  • all slot devices are targetable from outside

ableton racks has it right in this regard. as many parallel chains as you want, and you can nest em. really cool.

This sounds like a sub-optimal solution imo. I think this would be better https://forum.renoise.com/t/more-dsp-control-audio-splitter/44617

There’s no possibility of feedback in your concept, right?

I’m not sure what you’re asking, but yes, ableton can do feedback

This sounds like a sub-optimal solution imo. I think this would be better https://forum.renoise.com/t/more-dsp-control-audio-splitter/44617

There’s no possibility of feedback in your concept, right?

I don’t see the possibility of real parallel processing in your suggestion…

Did I miss something? So the parallel container seems to be much more powerful…

EDIT: Ok, this one?https://forum.renoise.com/t/more-dsp-control-audio-splitter/44617

Looks very confusing to me,

just like GOTO statement in code :stuck_out_tongue: Would prefer a clean parallel container device, since it is also already a proofed-to-work concept.

A modular routing covers parallel processing by definition, no? Look at Studio One. They’ve done it properly like the way I’ve suggested, granted that another GUI would probably be better suited than the linear dsp chain of Renoise.

I perceived your concept as less flexible and kind of a dead-end. Consider expandability and future uses. (i e, pray for the devs not remake the pattern matrix story once again…)

EDIT: Yes, the example is confusing because it is an example of a very complex routing. This wouldn’t be possible with a simplistic “parallel device”.

This wouldn’t be possible with a simplistic “parallel device”.

Why not?

I must admit that I find the able ton’s solution “device chain device” very simple and useful:

Attachment 7008 not found.

Only missing here is dry/wet amount for each chain, since the devices itself have it.

EDIT: Or better that there is one, non pluggable “DRY CHAIN” always by default, including same controls.

  1. Can you output those devices anyplace, or are they all output after the “Audio effect rack”?

  2. Can it support some kind of feedback?

joule, I also would prefer such a flexible thing, though imho your concept still has some weak points:

  • the end of a chain appears to be like a workaround

  • it causes spaghetti chaining, so its hard to understand complex signal flow

  • I doubt the renoise team will like it, due above points

Why not change your concept into a container device with an output target? So your inter-send device will turn into a container and after the last inserted fx, you setup the target to send the sum? At least in this way, the end of a chain was obvious…

Feedback imo should be in an additional device, which also contains then a feedback protection, like a “backwards send device”…

As soon as you want to do anything “spaghetti”, which is one of the points to modular chaining, you would end up putting single devices into containers just to achieve the same thing. But sure, it might be a compromise to make the learning curve seem less steep by having a more simplistic interface. However, I suspect pretty soon you will find it bothersome containing all your devices (even single ones) just for the sake of being able to route them anywhere.

forget about feedback, guys. Feedback in analog is some unpredictable serious fun, but…in digital it is mayhem to code and each device inside a loop would need to cope with it in very special ways. Or you have delays in each backlink, no way around it. OK delays in backlink can be useful for mayhem delay with anything in feedback loop, much like the filters in the multitap delay, but nothing else.

For routing…I already do spaghetti with sends in the inst.fx. It is something to wrap the head around, but it works nicely for me now. I could well imagine having sidechaining aka multiple input/output effects in there. Sidechaining like vocoder or ringmod or sidechain comp, or also like the bandsplit with multi out - maybe with receive devices, or pointing to another multi in, but then there would need to be some visual feedback.

The limitation of left->right and top->down is kind of…ok for me. I know this is to prevent any glimpse of backlinks by usage interface limitations, but it already works for me.

I could at no point get around to having a single track which contains multiple threads of processing. C’mon, joule, anyone but the inventor is going to think its just plain artificial masochism! You’re automatically bound to loose any kind of overview at the point where your processing involves more than say 7 devices at 3 threads. And I do usually use a lot more of devices in my more complex inst.fx setups, and would also like to do more complex shit with them when splitting and combining devices would finally be available. And I’d HATE crawling my eyes to and fro inside that one…single…effect…lane…that works like…spaghetti…code? Instant despair guaranteed…

My take on this has for quite some while been to…make doofers work like the instrument fx, with multiple parallel lanes, and multiple inputs and outputs for the whole device… Somehow, but this way each thread would be at one line of visual execution. You could make sends (or general inputs) point to the additional channels of sidechain plugins, and make multi-out plugins point their channels somewhere like sends, have the whole multilane doofer have multiple outputs that work like the bandsplit plugin, all dandy, and no need to break the left->right top->down paradigm in all this. Just the sidechain extra channel sends would need some visual feedback to keep overview of the more complex routings.

Yeah, the GUI is not very suitable for this. Even doofers are bordering to being clutterish, frankly.

A simple parallel processor that might be suitable for the current GUI would just contain two slots, both having the ability to contain doofers. One of the slots being unused would be the equivalent of placing a default gainer in it. I think this is a clear and more realistic implementation.

the ableton parallel container just displays the current selected chain, so would be also a solution for limited width…

And with this in mind I find the overview the instrument fx can give around multiple effecs chains very useful, and I use it a lot. Working with send channels in the mixer view is rather painful compared to it, I don’t know why. But comes close, both ways have their appeal. Yes, both ways won’t fit into the bottom panel, so adding this additional dimension of depth would need some thoughts on how this dimension could be presented in the gui in the best possible way of not breaking or cluttering the staus quo of the rest of the program.

Maybe like splitting the middle view expanding and shrinking additional content, so you can keep patterns/mixer open as usual, but only at the top half of it, and at the lower side edit your parallel doofers, or multiple automation lanes at once, or have in sampler mode the instrument effects and a sample view open at the same time, whatever. But then again this will need much screen resolution in many cases, bad for low res laptops.

Haha, I sense an accordeon comeback, but super annoyingly auto opening when you click a pll doofer, or you accidently click an lfo and it will try your temper by zooming in the adv edit, stealing the note data from your view…

This is something I sorely miss from Aodix. Renoise is a lot more user friendly, but having to use multiple send channels to get any kind of parallel effect magic is a chore.

I was thinking, though–if it’s really important to avoid effect chain cluttering, couldn’t parallel chains be achieved by having a “Receive” meta device that lets you input the signal from an effect on one track to the chain of another track?

Thus:

7314 renoise--parallel_effect_track.png

Because this is open-ended, you could also use it to mix signals from several tracks. Granted, this could get very complex, but I would argue that’s up to the user to manage.

Alternatively, the effect track could be a special type of “local send track”, attached to the “main track” in question and visually collapsible in the same way as track display in a group. This would arguably be easier to keep track of, but I would personally much prefer the aforementioned open-ended variety. (After all, the purpose of a DAW is to provide smart tools. The complexity of the project is up to the user.)

The advantages of this, as I see it, would be a visual representation coherent with the precedent of send tracks, and minimised clutter.

Regardless of how it’s done, Renoise really, really needs a way of doing parallel effects.

  1. Can you output those devices anyplace, or are they all output after the “Audio effect rack”?

  2. Can it support some kind of feedback?

Ableton and reaper are the only daws which allow feedback between audio tracks .