Probably, but it warps my head so I prefer to use -64 or 32 to get a hole value (OCD), even if 63.99 doesn’t change much. It drifts slowly.
Thinking of Octatrack’s rate : it shows +63, but it is actually 64 to stay in tune (32 being 1 octave lower).
Probably, but it warps my head so I prefer to use -64 or 32 to get a hole value (OCD), even if 63.99 doesn’t change much. It drifts slowly.
Thinking of Octatrack’s rate : it shows +63, but it is actually 64 to stay in tune (32 being 1 octave lower).
How does anyone have a problem with this? The lfo is locked to bpm and you can change the resolution in the mult box, then you can alter the number of lfo cycles within that resolution with the speed control and there are so many other options to reset the lfo on any given trig, TRIG, ONE, HOLD etc. Experiment, use your ears. Why does everything need to be locked to grid and why the hell would anybody need a chart ? I don’t see what the problem is, but then I’m not the sharpest Stanley in the arsenal so maybe I’m missing something. Rant over.
addendum, 1k in the mult box is actually 1024 and 2k is 2048.
It seems (to me!) as though the DT2 maybe has the spare CPU power/DSP to display some of the LFO movement on the UI. This would really help those of us who sometimes get lost in LFO land and for whom maths hurts our heads! Be great if this could come to pass at some point…
Yeah they missed my request that the lfo speed should be shown in steps somewhere on the lfo screen.
so with analog four mk1, and rytm mk1, since their lfo speed can’t be in decimals (only in integer), they can’t do, for example, dotted notes?
superficially, on initial examination - some of the tempo related ‘magic’ numbers won’t align ultra-precisely, depending on your tempo and subdivision etc - it’s the same with some delay times too, but you have to ask yourself if there’s enough ‘drift’ to worry about … if there is, then (as i haven’t tried, never that bothered) you could try using a free modulation source to target the parameter LFO Speed or e.g. Delay Time with a static offset whereby you can use the finer resolution of the modulation depth to tweak the speeds/rates towards the ideal off-beat subdivision you are after
just fwiw - i reiterate this all the time - the actual values of higher resolution parameters (i.e. in between the 7bit ‘integers’) are also a further 7 bits in most parameters, not all and not all depths btw - but elektron use two decimal digits to render 127 variations across 99 discernible values - so whilst you may think a decimal value does not snap ‘close enough’ there is a one in four chance that a ‘decimal’ value is rendering the same for two different ‘actual’ 7bit values - i.e. the ‘decimals’ are obscuring/masking real resolution … an academic qualification for your example … it’s just that you referenced the dreaded “decimals”
to counter the annoyance, i’d like to see a Octatrack-style pixel on the display which flickered for every transmitted step, so you would have a visual cue that there were two values hiding behind a seemingly static decimal value
Interesting, that might be why I can sometimes hear a slight change in the space between values, I wonder how it recalls after saving if you exploited it?.
it’s all there in the saved data - it works the values as 14bit (same resolution you get in many pitchbend wheels) - you know when you use a coarse pitchbend wheel, those are likely 7bit 0-127
elektron show the coarse values with full resolution, it needs 3 spaces, but they only give the fine values 2 spaces, so they render those decimally, rounding down from 127 to 99 values on-screen, but the true values are fine 7-bit - so saving a patch where there is a subtle difference (but no discernible on screen evidence), maybe in some FM tweaking will be saved properly
if you hook one up to a midi monitor you will see activity as it sends the true resolution between ‘integer’ steps, it just doesn’t present the whole truth on the display
they see it as an acceptable compromise, i can’t disagree, but i do wish there was a setting to illustrate teh actual values instead of sniffing midi data - because if you share visual numbers from a screen the person may transcribe the patch with tiny differences that can on occasion nudge a patch one way or another, especially out there patches
nobody would accept showing the values hexadecimally, but that is teh truest way to show the fine resolution with two places - that requires 0-7 for 1st space then 0-9,A-F for 2nd space - of course it’s not intuitive, it’s like a clock with 16 hours and 16 minutes(i wrote this wrong initially doh!) - if only a pixel flickered when you were adjusting when it looked like teh value wasn’t changing it would inform of a ‘hidden’ value
tldr - the tweaks are saved accurately, they are not displayed accurately
Except those who also own an M8.