I have a problem with the Key Tracker sometimes: when I think I’m loading a really good sounding song I made the other day, I hit ctrl and it sounds very different from last time. I make lots of compositions nowadays (for learning, I know, using samples eventually is of course very handy too ) with the zero-sample technique… I’ll attach one song where I found this behaviour, tomorrow. Point is - I start off loading 2 .xrnt toolchains, “pitches” and “envelopes” in for example the kick track. So the Key tracker is the first device… Then the keytracker goes to a hydra, which resets some of dblue’s LFOs, of which one is labeled “*RingMod”. This one routes to the offset of the first ‘envelope’ LFO that of course controls the ringmods frequency. The problem with this technique and loading a song back from disk, is that
the Key tracker’s state which key was last pressed is remembered through song save/load but the LFO’s position is zero at ‘song loaded first time’
So that means, of course also because I’m too “lazy” to render the kickdrum to sample and the snare etc… that when I only use one note / pitch for a track, I have to pay attention to this behaviour when I load a song. I have to hit a note on every track with a Key Tracker first.
TLDR: When a Key Tracker routes through a Hydra device, it does not initialise as expected. (sample or no sample)
You’re quite right (although I believe it should be x8XY), but to show you what I mean I’ll still upload a demo song… My workaround should be, if it’s a kick anyway that will have the same pitch every hit, I’ll just throw all the keytracker stuff away and leave the pitch (an LFO’s offset) to automation.
Another workaround will be indeed having a 1 line pattern in a song’s beginning, with a different note than the first really sounding note. At -INF.
Here’s a demo ‘song’ so you can see what I mean. When you load the song, the kick is almost not hearable. Way too low frequencies… As soon as you press any key that’s not D-2 (I think), the Key Tracker will be back in the game.
Is this related to the fact the Hydra will only output a new value if the input value changes?
If so this is a very useful feature! Please don’t change it.
Why? One example is using One Shot LFOs on a parameter which you want hand programmed automation in parts. The LFO device does always output its value, so to do so you need to be turning it on and off as well and resetting position where you want it triggered. If you instead route it through a Hydra you don’t need to turn it off to do normal automation.
Same can come be useful at other times. You want parameters XYZ changed together, then you want XY to stay static and add some automation to Z. The Hydra not always giving an output again allows you to do this.
I figured that it indeed has something to do with the Hydra. Today I loaded a song with a ‘dubstep’ type filter wobble, where a XY controls the LFO speed and max height in the hydra. I have to figure out how to get around this, because I cannot render this song the way I want it, it’s weird but true.
edit just realized. probably one time ‘point’ reset in automation will do the trick
) with the zero-sample technique… I’ll attach one song where I found this behaviour, tomorrow. Point is - I start off loading 2 .xrnt toolchains, “pitches” and “envelopes” in for example the kick track. So the Key tracker is the first device… Then the keytracker goes to a hydra, which resets some of dblue’s LFOs, of which one is labeled “*RingMod”. This one routes to the offset of the first ‘envelope’ LFO that of course controls the ringmods frequency. The problem with this technique and loading a song back from disk, is that
