P-locks could follow Drambo's sequencer step "Offset" timing
Drambo's sequencer step "Offset" value currently does not appear to be accounted for by P-Locks. In other words, the exact timing of P-Locks appears to be forced onto the grid (typically quantized 1/16th) even if steps aren't forced onto the grid unless the user chooses to by activating the SNAP function.
For this reason I'm making the suggestion to change this behaviour to enable Drambo to take step offsets into account for defining the exact timing of a P-Locked sequencer automation event.
As a Digitone/Digitakt user, for over 4 years I've made music exclusively with these machines and I'm extremely reliant on Elektron's sequencers parameter locking functionalities. I was extremely pleasantly surprised not only by Drambo's automation flexibility and ease of use, but also by the fact that Drambo includes P-Locking functionality.
For the kind of music I make, nudging notes off of the grid is absolutely vital to create a targeted swinging feel without the limiting implications of having to use a sequencer wide swing function. As a result, I want to be able to use P-Locking on these offset steps in a hassle-free manner as much as possible (I mean... who wouldn't lol).
It would be awesome if P-Locking parameters could respect step timing offsets so that the sound produced on a P-Locked step remains the same as much as possible regardless of the timing of the step in relation to the grid.
For what follows, I'm not sure if this is by design or a necessary behaviour due to technical limitations, (so I'm also asking if anybody knows):
In instances where I intend to P-Lock something like a filter cutoff on a step that is quantized to the grid where I intend to abruptly open the filter, I'm perceiving what I believed is referred to as "smoothing" in the transition between the 2 distinct cutoff values, instead of a relatively abrupt value switch. In the test I ran with Fabfilter Twin 3, this behaviour seems to create the impression of a sound affected by a filter envelope with a slower attack when the filter is opening, instead of a snappy change in the tone of the sound.
If this is "smoothing" behaviour is purely by design and not forced by a technical limitation, I have a second suggestion:
It would be awesome to have the option of controlling the smoothing value (with the intention of reducing the smoothing value as much as possible without unwanted side effects) for the behaviour of P-Lock automations. This would allow for much snappier, abrupt parameter value transition, which I find very useful.