# Lfodevice Pattern Commands Automation

I was trying to meddle with LFO parameters using pattern commands, and to get a 50% value when setting either xx7f or xx80 (I assume 7F should be 50%). I get 49.804% using 7F, and above 50% with 80. I wouldn’t be that fussed, but I’m using the percentages as time syncing values for another lfo

Easy to replicate:

1. Insert LFOdevice
2. Right-click & drag slider to 50% (or pattern command 147F)
3. play it back - turns to 49.8%

Same for velocity device - maybe all percentages?

100 / 256 = 0.39215…

0.39215… * 7F = 49.8039…
0.39215… * 80 = 50.1960…

I think this is where the problem arises

Think you might have made a typo or miscalculation here?

100 / 256 = 0.390625

0.390625 * 127 (7F hex) = 49.609375
0.390625 * 128 (80 hex) = 50
0.390625 * 255 (FF hex) = 99.609375 < the problem with this method

However…

100 / 255 = 0.3921568627450980392156862745098

When calculated this way (as Renoise currently seems to), it does allow for mapping the whole range 0x00 = 0% to 0xFF = 100%, but it also creates the problem of inaccuracy around the 50% mark, as you already highlighted.

I was relieved to notice it was a miscalculation, and it’s not just me being fussy!

Nah, I’ve ran into it myself a few times, but have learned to accept it as a necessary evil for the moment. A workaround I commonly use when I really want to work with pattern commands instead of automation (let’s face it, pattern commands are quicker and more fun), is to use another LFO with a custom envelope whose purpose is to remap the pattern commands into the precise values I need. By using this LFO’s reset command, I can then map x780 to be exactly 50%, for example (or anything else I want, really).

Example:
lfo-remapping.xrns

It is a pain in the ass to have this extra step, and manually creating these envelopes can be a bit time consuming (cough… another vote for my big-ass envelope editor view please!), but it is what it is!

Even if the hex limits were expanded from FF to FFFF, this problem of inaccuracy would still crop up (we’d just be able to get sliiiightly closer to 50%), so I think what we really need is the ability to program actual floating point parameter values directly into the pattern somehow. The main problem there is how the hell to actually have an arbitrary value editor in the pattern. Handling 4 pattern command digits is easy enough, but when it comes to weird floating point values with several decimal places… hmm

Yeah, I get what you mean and I guess it’s not really a bug, but just the way things work. The only thing I can think of is an option to allow rounding up or down of the percentages, but it’s not that desirable.

The reset envelope command is indeed a suitable workaround but like you say, fiddly with the tiny envelope editor.

Another thing I noticed was the similar behaviour when using pattern commands for LFO frquency - I understand that this could be a little different in respect to the way the values scale, but values like 1502, 1508 and 1510 translate to LPC values of 127.5, 31.87 and 15.94 - once again close to those round values I’m likely to use more.