Send FX, pre and post

Super Mega Dude: No, it’s currently not possible, it’s a suggestion. You are completely right, the post fader has no usage in lot of scenarios currently.

It’s funny these things you take for granted and then when they’re gone you realise how essential they are.

Anyway, no software is perfect and sometimes workarounds encourage you to think in different ways. Maybe it’ll trigger ideas I wouldn’t normally come up with.

It’s 2 maybe 3 times longer than this that will already work, and hey if you could implement VCAs that would be cool too, apparently that’s another cool thing for mixing.

local trk = renoise.song().selected_track
local postfx_vol = trk.postfx_volume
local function sync_last_send_with_postfx()
trk.devices[#trk.devices]:parameter(1).value = postfx_vol.value
end
postfx_vol.value_observable:add_notifier(sync_last_send_with_postfx)

There is another way without using a gainer, but it has its own downside. Put your track in a track group, put the send on the group fx, and now you can use the track fader. The downside is you quickly make the pattern matrix very difficult to use with way too many squares.

:stuck_out_tongue:
Anyone wants to make that tool? Anyone? If I think about it you can automate this directly via indirect means. I swear it’s just 50 lines of code, no more. I kind of want to try VCAs, i think those could be worth the pseudo realtime automation implementation.

gova, you already did half the job :stuck_out_tongue: Why not finishing? Feature request:

In order of priority: If a gain device named “track gain” is available, sync post fader with it’s gain control and leave the original post fader value at 0. If it’s not available and there is a muted send device available anywhere in the track, sync with it’s send amount. And on mouse-over post-fader, show the currently connected device, with some border, too.

Thanks Carbonthief. Works but as you said is still far from ideal.

Jurek +1 :stuck_out_tongue:

I checked and I’m out my depth with the scripting. I did multimedia at Uni which covered a bit of coding - html, javascript, object pascal (borland delphi). If you know anything about these courses though, you’ll know you come out a “Jack of all trades, master of none”.

Also that was 8 years ago and I’m in a completely different industry now.

Yup so if any kind soul *cough, gova, *cough would be up for having a crack at this I would be forever indebted!

There’s no mouse over function in the API you can only launch a function every time the fader’s value changes, moreover you can’t control the gui outside of your own tool window. This is all of the free time I could muster till next week. Lua is simple guys, and the api is very comfortable. You should really learn it jurek, especially since so many things you want can be easily implemented…

ok but there arises some problems:

  • in super mega dude’s scenario, the post fader needs to display another volume but needs to stay itself at 0 all the time - I think that’s not possible currently.

  • Are there events / observers if one is focussing on a track or changing the dsp devices in it (adding/removing)? Then it could be looked after a possible device one time and a pointer to it saved…

Well I guess, this is only really possible if the devs do it natively.

1 youcan compensate anything the post fader is doing with a gainer, also with the api

2 selected track observable

selectedtrack’sdevices tableobservable

don’t forget to remove those

once again, GUI elements outside of your own tool’s window can not be changed (only some exceptions with hide/show)

you can also just have a timer run a function that would do all the checks all the time, lets say, every 200ms when it’s on, would be easier as you don’t have to manage any observables, and a tick based solution like this might actually be more efficient, because you’d probably still need to have to collect those notifications observables not to get too many of them when quickly moving the fader

that would simplify this to something of this sort:

--have an auto rename function, to greatly reduce the amount of work in the processing function
local function sync_pstfxsnd()
local trk = renoise.song().selected_track
local dev_amount = #trk.devices
local snd = trk:device(dev_amount-1)
if snd.name = 'pstfxsnd' and snd.is_active then
--<math that would remove the effect of the post send via a gainer, gainer is: trk:device(dev_amount)>
--<post fader value = send device amount>
--don't forget to have the same ranges in the fader as it is in the send
end
end
local function tick_on_off()
--this will be on-off switch
--if already on
--remove_timer
--else
--add timer
end

Yeah pal appreciate you’ll be busy, I was just chancing my luck in case it was a quick code for you. Thanks for your input :slight_smile:

I’m not completely writing off having a crack at coding something but it would be a bit down the line since I’m already having to take a lot in trying out this new type of DAW.

Gova, man what you are talking about? That is NOT. A practical solution you’re approaching here, it’s a patch-workaround-hack fix, quite complicated and annoying. And a timer to check a one time thing - common that’s a quite bad concept.

Today I woke up and suddenly had the most simple and maybe clever solution for this problem as an inspiration for taktik and dblue:

The post fader box should be able to be moved! To any place in the dsp line, just like another dsp! The output of course still will be taken at the end, but internally it would be just like another invisible gainer!

That approach would be so maximum easy to handle! So intuitive! imagine this. And no ugly meta hack connection.

Like Christmas with korg, Roland and Yamaha.

An additional gainer is annoying? rly now :stuck_out_tongue:

I would kill my self every time I wanted to automate anything in renoise if I found something so smallannoying. A timer with an on off switch would be just far simpler for newbies to write than to work with the observable pattern.

But hey, enjoy your post fx send fader in2 years :stuck_out_tongue:

A practical solution is rewire or redux, always was.

Hehe we will see, maybe those two geniuses will read this and think: "Hey what a good and simple idea. And so easy to implement for us! And so simple for our customers and fans! Also backwards compatible ". Such feature already justifies a major version jump in the Steinberg’s world.

BTW. I never thought about this before, but I always wondered why it seems quite a bit more easy to setup volume balances in the mixer in Logic, Ableton or Cubase. This seems to be one reason. Another is that the post fader almost always is useless in my projects.

YES.

YES YES YES. This topic comes up again! I posted about it a while back here basically describing exactly the same conundrum.

There are times when Renoise’s architecture is handy, and being able to drop in a #Send at any point in the signal chain certainly does allow for versatile and creative routing.

However, I would also argue that this is highly confusing for new users or users coming over from other DAWs.

To illustrate: A typical user from another DAW might want a compressor at the top of the signal chain, and a send out to a reverb. With the current pre/post-FX system, they’re basically limited to either messing up their gain-staging with the Pre-FX mode faders, or messing up their reverb send with the Post-FX mode. There are of course workarounds, but seeing as a compressor and FX send is such a basic and common configuration for a signal chain, new users would just find it confusing and would wonder why Renoise can’t do this without workarounds.

I guess the hard part for the Renoise team now is how this problem should be approached without breaking backwards-compatibility, because it is obviously not as simple as just putting a “Post-Fader” button on the #Send device, or making a new #FX-Send device which is post-fader.

Regardless though, I also would really really like to see this addressed. Until then Super Mega Dude, get friendly with the Gainer device! B)

PS. Welcome!

Thanks for the welcome atype808. I’ve been using the gainers and actually the fact you have the fx above the faders means you can still adjust levels on the mixer tab. But it’s more fiddly and still writes off the faders. Not the end of the world but still reckon it could be improved.

One thing that just came to my mind, which would be ultrauseful for other stuff, too…and could address the problem described here with send levels (if I got that right)…and I’ve seen other software allowing such actions:

Allow meta-device like “inverse feedback” from sliders. I.e. from any slider, if it’s moved, it will move other sliders with selected ranges. If a slider is moved by automation, gui, midi, whatever…it could move other sliders like a macro dial, or a doofer thing, a hydra or whatever.

I was wishing for this many times, but for other workflow simplifying reasons. But it would be a logical step, if you have sends that mute, and sends that won’t mute, you could even present a simple option that would couple such send devices automatically to the main mixer sliders with one click or even by default. Or config it further, and make it effect gainers or other main mixer options in other tracks (i.e. the send tracks you’re routing to) - to let the main mixer stuff control more complex setups with refined actions for track volume changes more easily.

The post fader box should be able to be moved! To any place in the dsp line, just like another dsp! The output of course still will be taken at the end, but internally it would be just like another invisible gainer!

THIS

OopsIFly: sounds a lot like, but not exactly as VCAs, which are also possible to implement via a formula device and scripting.

The post fader box should be able to be moved! To any place in the dsp line, just like another dsp! The output of course still will be taken at the end, but internally it would be just like another invisible gainer!

This is a really good idea.

It still might be a bit confusing for new users coming from other DAWs expecting just a plain old mixer config (i.e. post-fader sends), but as far as a “Renoise-esque” solution goes, it would be a simple solution that solves the problem of gain-staging vs. FX send levels without breaking compatibility with existing renoise song’s and their routing.