Please include the LFO Device->Reset parameter as a possible destination for the Velocity Device! This would open up a lot of interesting possibilities.
I guess this also includes adding the Reset parameter as a possible destination for the LFO Device itself, which would also be awesome.
btw I thought the velocity device would follow the amplitude of a signal, and spit out a continuous stream of values to control other parameters…but that doesn’t seem to be the case, or am I missing something?
When I first saw it I thought the exact same thing, and I was a little bit heart broken when I realised that wasn’t the case, but it’s still a pretty cool device. It actually responds to the velocity of notes being played in the track, so you could link filter cutoff to note velocity, for example. Pretty cool if you’re jamming live with a MIDI controller hooked up.
This is indeed a pure (midi)velocity device, not a signal amplify (vu) device.
Such a vu device has also been considered. But for the same reason there is no sidechain, this is not done (yet).
It was not as easy to code I guess. But if taktik now gonna do some sidechaining coding, then I see no reason why this could also not be done at the same time?
About the reset. I agree very much. Would be very cool to make the velocity device a relative device as well (optionally of course).
For instance, as long as there is a note playing (note with no note-off) in the track, then the device is ‘enabled’ and as soon as last note got a note-off then it will reset. (but also a manual reset button).
I even think an option to apply the velocity device to only note-offs could be useful. So when there is a note-off you will trigger this device with the velocity value of the corresponding note.
I have no idea if this is an easy task to do with the current note structure in renoise. But this could make instruments in renoise even more expressive.
btw, in a prefect world we had envelopes (like the one inside the instruments, as devices you can use anywhere to control/trigger parameters for external devices.
Next thing would also to have a note scaling device. It would be just the same as this velocity device, but instead this will scale/change parameters according to what note you trigger.
And finally, some time in the future, we can wrap these device inside the instrument it self, then do the routing inside the instrument, and output your stuff to a instrument device/fixed instrument commands etc.
But all this is for a future upgraded xrni structure.
“It actually responds to the velocity of notes being played in the track, so you could link filter cutoff to note velocity, for example. Pretty cool if you’re jamming live with a MIDI controller hooked up.”
I was hoping for something a bit more enveloped myself… sort of an ADSR type thing… but I guess I’ll have to wait for my envelope metadevice cough
… and what you thought jonas, is what I envisioned for my sidechain metadevice … but it would also have attack, decay, and threshold so that you could do smother things with it like ducking and keying
but yah… taktik is going to kill me if I keep mentioning my ideas
Then use the automation for the parameters… why looking for things that are already there?
The LFO now has a custom mode (rightclick and drag for handdraw) which allows you to perform ADSR as well.
I would love to see these (hopefully) small tweaks in Renoise…
To make it possible to trigger the “Reset” function of the LFO Device from a Velocity Device.
To make it possible to trigger the “Reset” function of the LFO Device from another LFO Device.
From a technical point of view, I suppose this relies on exposing the “Reset” function as a visible parameter to the rest of Renoise? Is this a simple flag which can be changed easily, or does it involve some headaches which I have not thought about?
dblue, I noticed on irc that you didn’t jive with my xml hack… but as it currently stands, the reset parameter on the lfo controls the LFO offset… which means that even if taktik did allow it to be seen as a parameter by the velocity device, it would still act as it currently does with my xml hack… the higher the velocity, the higher the offset… also, I’m pretty sure the velocity device constantly keeps the parameter it points to set at the most recent velocity value… which means that chances are the LFO will not play properly after that…
… that being said, I’m pretty what you want would take a bit more redesign than simply revealing that parameter to the velo device.
As I said, I do appreciate the tip, and in fact it does exactly what I need… but no, I’m not into manually editing some XML every time I need to do this
Incorrect. It resets the phase position of the LFO cycle, it does not touch the offset. While on the surface they can appear to be the same thing, in fact they behave quite differently, and it is not possible to do what I have in mind simply by manipulting the offset alone. It’s possible we are simply mixing up terminology here though, because as I’ve said, your hack does in fact do what I want… allowing me to reset the LFO phase via the Velocity Device.
Given the fact that your XML hack causes it to work exactly as I would expect it to, I believe there is nothing more to do than change a simple flag somewhere. Taktik appears to have confirmed this.
Oh goodie… I jumped to conclusions when you said it wasn’t what you were looking for. And by offset, I meant the phase… I just thought as it in the same way as a sample offset… mainly because of the custom LFO and such. But, if it’s working, then kickass… and yes, I’d love it if Taktik took off the protection from the parameter.
That being said, fun trick: to invert metadata, create a custom LFO with a backwards slope as such: \ … then point at its reset parameter instead of the intended parameter on whatever other effect you want to control… pointing the LFO at the parameter instead