Hi guys,
I’m struggling to find info on how to grab the current playing volume on a track, to forward to my control surface (I’m not using Duplex to implement it, because of reasons). It’s in there somewhere in Duplex at least but I couldn’t find it… Can anyone help?
RMS would be ideal, peak would already be something. 
It’s not really possible.
(But if you want to try some kind of hack, you could route a signal follower to any parameter, and then observe that parameter, converting it to midi on every change)
D’oh! I just ran again the MCU in Duplex and there’s no VU there either. I don’t know why I thought I remembered they were implemented.
I guess you’re right, a signal follower would be a solution but it’s very hacky to add a device on all tracks to that effect. 
I guess I’m going to make a doofer with a signal follower and a disabled gainer, the former modifying the gainer’s gain, and I can follow this. I’m testing it right now and it seems to work perfectly well.
Now I have to look for any hooks post- song loading and pre- songsaving. Dunno if this exists. Otherwise it’ll be filthy. Ish.
Pre-song saving can’t be detected - closest thing isapp_saved_document_observable, which is triggered after the song got saved.
If you’re doing some last second calculations, perhaps consider a manual trigger / alternative “save song” shortcut?
D’oh! I just ran again the MCU in Duplex and there’s no VU there either. I don’t know why I thought I remembered they were implemented.
I’ve been moaning about this too. the current solutions seem a bit … hackish.
I could totally see myself hooking app_saved_document_observable and RE-saving the song with my hacked devices deleted… /o\ That’s horrible style but might just work.
I’m starting to like the follower+disabled gainer combo. Except that it totally changes the song state just because I want to attach a meter on a track. The ballistics are totally configurable and it’s perfectly programmable. Since I seem to be the only user currently interested in the X-Touch support, I guess some dirty hacks won’t hurt too much.
Eventually, I’ll want to work on a way to perform live with Renoise, so I’ll have to have some abstractions beyond the one-and-only-currently-loaded-song (and use the control surface in unintended ways or it’s no fun…). Probably mostly instrument+phrases - based.
The VU hacks may seem inocuousat this point.
If I may benefit from your experience a bit more, would you recommend I add/remove the couple devices when I need them (for instance when I scroll the control surface window left or right, some tracks are detached and others attached), or add them on each track right when the song is loaded and simply add/remove notifiers when needed? (Short version: how expensive is it to add/remove an audio device on a track ?)
Ah, also, I read in an old post that Renoise is not good at accessing devices inside a doofer. Is that still true? I’d like to make the VU hack into a doofer if I can do everything programmatically.
You can’t observe device parameters within doofers (as of 3.1.1). But you probably have to add some dummy device inside the doofer before being able to route the doofer parameters to something.
Here is an example: https://forum.renoise.com/t/new-tool-3-1-track-color-device/47282 (you might have to restart renoise after installing the tool…)
Oh, that was where I read you can’t mess inside doofers
I just toyed around for a minute and realized a doofer’s macro control can’t follow the parameter it’s bound to. It only works in the other direction. I guess it makes sense for when you bind multiple parameters. So not a solution to my VU hack.
Right now I’m struggling to set up the signal follower’s destination programmatically. I first create a signal follower then a gainer as the last two devices in a track, then proceed to configure them, and, in the SF, every setting BUT Dest. Effect AND Dest. Parameter is set. I also tried the heavyweight “pass the preset as an XML to active_preset_data” method, but there again, Dest. (Track|Effect|Parameter) don’t seem to belong in the preset. I’m kinda stuck again.
Is there something obvious I’ve missed again?
What’s worse is that I see the values I’ve set when I query the parameters (dest.effect and dest.parameter) from the terminal, but still have “None” in the GUI.
My guess is that it’s because of the dynamic dropdown lists somehow, but that smells more like a bug than a feature to me.
Aaaaaaaaaand it’s not a bug. If suddenly switching to C-style indexes is considered normal in Lua. Seems that Dest.Effect needs to receive device_index-1, and suddenly everything starts to work.
Aaaaaaaaaand it’s not a bug. If suddenly switching to C-style indexes is considered normal in Lua. Seems that Dest.Effect needs to receive device_index-1, and suddenly everything starts to work.
This has caught me out before aswell. Oddly enough I have just been working with scripting the Hydra device which accepts both -1 and the current track index as valid. Maybe there`s an inconsistency with the signal follower.
It’s not really possible.
(But if you want to try some kind of hack, you could route a signal follower to any parameter, and then observe that parameter, converting it to midi on every change)
Interesting. So the signal follower is sample accurate on fastest setting? I always presumed there was some averaging/ smoothing going on.
So the signal follower is sample accurate on fastest setting?
The internal audio analysis is of course sample accurate, but the output modulation rate is determined by the song’s TPL like all other meta devices.
The internal audio analysis is of course sample accurate, but the output modulation rate is determined by the song’s TPL like all other meta devices.
I see, so with Joule`s method you may not catch every peak in real time but over time you should catch the max peaks, if that makes sense.