It’s perfect, especially since you mentioned me on those places I won’t complain of course! Some great additions again.
There’s one thing I don’t understand about your code though (or maybe your song workflow!)
In add_a_new_send_device, a send device is inserted, then immediately calculate which sendtrack it will be sending to (always #one/“zero”, by default), and if that send track is muted you unmute all send tracks. I don’t get the workflow of that perfectly, although I think the idea unmuting the sendtrack you send to is a smart addition.
How about a add_send_device function, or a modified route_to_new_send_track function with a small (keyboard operable) gui window allowing you to choose first where to send to / make a new sendtrack?
Glad all is good with the tidy up! 
Yes the calculation is unecessary, thanks for hilighting, I`ll strip it out. The unmuting all send tracks is because I may want to cycle through the sends - mainly different reverbs on a couple of sends. So it covers this situation:
-I have soloed the track I want to add reverb to
-I add a send with the shortcut, which automatically unmutes all sends
-I cycle through the sends with the arrows for receiver on the send DSP to see what fits.
If I all sends were not unmuted, I`d have to do it manually .
There is also a bit of potential for happy accidents when cycling through more creative send-chains with this method.
For the next alpha there will also be shortcuts for cycling through the send targets (receiver parameter) which will unmute sends as it points to them. Similarly useful for starting-soloed scenarios.
I think the addition of the new receiver shortcuts in combination with “Add New Send Track” / " Add New Send Device (Keep Source)" will cover all of this?
So I’ve been so free to create version 0.61
one shortcut has been added, namely "GTS Route To Send Track…"
it gives again a type of keyboard operable GUI with some very simple, but very handy options:
- As usual, you can type a number, or a-z, A-Z if you have a lot of send tracks, to select where to send to
- You can select it with keys up/down too
- You can pre-set the Amount value with left/right (Shift to be more precise)
- Space toggles the amount off and on
- Enter to send to existing track, but also:
- Insert to create a new sendtrack before the indicated one aisti
- Delete to create a new sendtrack after the indicated one aisti
- Home to create a new sendtrack at spot #1 aisti
- End to create a new sendtrack at the end aisti
(legend for the above list; aisti means “and immediately send to it”)
Looks good! is there a link or is it work in progress?
Sorry, meant to link it indeed
4177 ledger.scripts.GoToSendTrack_V0.61.xrnx
I’m only in doubt a little over whether the 0 should represent a send track in this case or not. 9+26+26 is probably more sendtracks than you’ll ever use, and with the autonaming scheme pressing 1 for S01 makes 10x more sense 
.
Thanks, taking a look!
Yes starting at 1 makes more sense I think.
Let me change it quickly so you don’t have to, because, a lot of hard coded numbers will have to change with it.
Fixed
4178 ledger.scripts.GoToSendTrack_V0.62.xrnx
Found one bug in my stuff namely, if you launch this new window it fires an error if you have 1 or less send tracks. I’m still thinking what should be in the dialog in that case. So, this is kind of alpha status.
Maybe just catch it and have a status bar update saying something like “Go To Send Tool: (At least 1 Send track is required before launching Jump list)” ?
Nice, I just implemented that, then came here, to read your post. Ha!
4179 ledger.scripts.GoToSendTrack_V0.63.xrnx
First post for v0.64
http://forum.renoise…post__p__297776
edit: forgot to mention these have been added aswell:
Forwards and backwards:
GTS Cycle Selected Send Devices Target -> GTS Cycle Selected Send Devices Target ←
Great minds and all that!
Might be a slight aside, but what do folks think about adding a gainer at the top and bottom of a send chain with an adjustment to negate the ‘track headroom’ offset?
Basically I want to ensure I’m driving any DSP applied in Send tracks properly. If the Track Headroom function is used then Sends gain gets out of whack. ie; If I have a Track Headroom value of -12 then the DSP inside the Send track also has a -12 gain applied at the first input. This, to me, is not so useful. I need to apply a +12 Gainer in this case to bring the signal up to the correct level. Then, post DSP, I have to apply a -12 Gainer to revert the signal to the general gain regime.
Track Headroom is a welcome gain stage and can be aligned with the K system or whatever regime you are working with to keep your values rational, but receiving DSP in Send tracks are likely to be under-driven at lower Track Headroom settings and likewise over-driven with amplified values.
I think it ought to be an option to have Send tracks attenuate their inputs to negate Track Headroom settings as default.
Do you think this ought to be a feature request?
I`ve just had a look at this with the sonalksis meter and it seems that the reduction is applied at the beginning of all the instrument tracks, but nothing on the sends:
The meters are shown in the same order as the tracks they are measuring. In that picture the send device on track 01 has the source muted. The signal on the send trackS01 matches the signal on track 01, which matches the master so the send has lowered it no further.
If I disable the send and just feed track 01 to the master, the master and track 01 reading stays the same, showing that the gain reduction must be at the start of the track otherwise the first output would read higher than the master.
edit: headroom at -6 db
4184 send gain stage.PNG
For you would the reduction being applied at the end of instrument and send tracks be better? Surely track inserts are being equally under/ overdriven with the current set up or is that desirable? (my knowledge of gain staging being fairly limited)
My apologies, I think my comment ‘gets out of whack’ has given the wrong impression.
Agree with your findings. I’m not intentionally suggesting that any additional gain reduction is being applied at the Send, or indeed that there is anything wrong in principle with the way this Track Headroom gain stage is being handled. It’s largely fine.
The problem for me is that I want any DSP in my sends to be getting a healthy signal, not a -12 or whatever I’ve been using across the board to keep my tracks rational volume-wise. The first DSP on a send track is going to be seeing the Track Headroom attenuated signal, that’s what is not particularly useful in my case.
It is completely solved by adding a Gainer at the top of the Send track with a +12 value, followed by the DSP which then feeds a final Gainer with a -12 value.
This way I get to maintain a good headroom across tracks, but also to be hitting characterful DSP with healthy signal levels in order to get the characteristics you would expect from a normal dynamic signal level.
This makes perfect sense, it’s what I’d expect to do on a console but I reckon some way of having this top and bottom offset done for you relative to the Track Headroom value would be very handy.
Maybe this will speed things up at least? Was nice to find the offset value sitting there in the API already!
4186 ledger.scripts.TrackHeadroomCompensate_Rns280_V1.xrnx
Keybinding:
“Add Headroom Compensating Gainers”
-works on any selected track, not just sends
That is very kind of you - thanks a lot for doing that!
No probs, it got me thinking along the lines for future tools which is always good!
Do you reckon it would be possible to keep these Gainers values constantly relative to the Track Headroom values?
That is, if the Track Headroom value was changed after a Gainer pair was created with this tool, those gainers would update with new values.
I really must learn Lua as there’s all kinds of rather niche things I do with renoise in an attempt to make it more like my old hardware studio setup… Things folks might find generally useful.
Is there a way I could examine the code in this tool in an attempt to learn?
I just saw the Renoise Lua threads in these fora - will get reading!
If you spam the ‘monitor sends’ command MON is added multiple times. Bug?