Numbers

So hey uhmm…

I will now embark on an endeavor to map out the times for modulator values, that is, the length in milliseconds for stuff like envelope phases…

some of them (LFO speed… ) are tempo-synced, others like envelope shapes are not…

my idea is to generate test tones being effected by the modulators, record them and measure number of samples…

UNLESS

someone has already done this and is willing to share results, or has a better idea (?)

why? because computer must know analog four control structure.

1 Like

i’ll help with the easy stuff (already started with lfo trig units, delay, arp etc)

would be simplest if HQ told us all, in a thorough manual, gosh !

you should automate it in midi first then analyse the audio
it’s a thankless task, but thanks for initiating it, even if it only provides a few extra clues

good luck with the values approaching inf :imp: :wink:

cheers…

yea arp is the easiest imo, it’s just MIDI clock pulses, i.e. value 24 = quarter note.

I’m going to assume that all 3 time controls for the EGs have the same mapping, and that the time is the same for exp vs. linear shapes.
i’ll try & graph the env values, it’s likely just logarithmic, right…? so it should be sufficient to do a few of them and extrapolate the rest, hopefully.

okay mapped out a bunch of times, but instead of making a table it would be nice to get to the equation… anyone good with curve fitting?

indeed, the ADR components for regular envelopes do use time/param_val consistently, it’s just the profile which changes (lin/exp)

so a quick way to do it would be using pitch&level (or whatever you can detect best) as destinations with an AD only lin-lin envelope then divide the total passage of time by 2 - check that the release values are the same units - a quick look shows that a value of 80 on A or D is just short of 3.0secs

if the envs 8 9 10 & 11 use time in the same manner then use an attack only envelope and just measure the ‘gate’ length, it should look like a pulse of length A - that’d be simplest to do to get a few values between min and max to establish if there’s an overall relationship

i think quantifying frequency/pitch values in the filter section will be mighty handy :wink:

ah the measuring was the easy part! :slight_smile:

easy to see with exponential attack envelopes:

i first measured in increments of 8 param values, then loosened it up…
this is attack parameter 0-127 on X, and time 0-30000ms on Y:

now trying to find the equation for it, probably a cubic thing, about to roll a genetic algorithm joint for this…

if the data’s fairly reliable :wink: i’d be happy to give it a look over & check

“easy to see”, are you nuts !!!

0,0
8,32
16,76
24,144
32,236
40,378
48,582
56,882
64,1330
72,2020
80,3000
88,4444
96,6580
112,14400
127,30000

left of comma: a4 param value
right of comma: time in ms

the actual values are nowhere near sample accurate, just “by sight”, but imo should be close enough to determine the curve type/equation…

1 Like

i would assume that the curve is nothing esoteric, but this is one of those moments where i deeply regret having smoked too much pot during high school days…

i cannot believe you pulled that off - i just checked 40, as i went up in steps of 5 ! using a much more legible env i got 377.8ms LOL


been lucky, maybe :slight_smile:

i’ll have a further look soon, but here’s a quick curve to compare to


it’s exponential, i had to normalize a few things to make it easier to graph and adjust ! - i’ll have a look at explaining it soon, but the match is spot on ! One set of points is the data read from the wav and the other is theoretical


hth

nice one… :slight_smile:

that genetic optimization thingie does come kind of close, but doesn’t match up…


here’s what I came up with as a dirty mapping function:

float msFromTimeVal(int val)
{
  float scale = 6.2;
  float max = exp(scale);
  return map(exp(map(val, 0, 127, 0, scale)), 1, max, 0, 30000);
}

it produces values in the ballpark, gotta optimize later but no time now… :dizzy_face:

i’m no longer convinced that i can find an easily achievable solution that’s accurate enough at the sharp end having looked a bit closer at this - for my purposes a lookup table will be sufficient for now

Interesting project. Did you send a message to Elektron at all? Maybe they’d help you out with some of the numbers.

yeah…
I’d hoped HQ would be more supportive, but alas… seems the guys are very much encumbered with whatever they’re working on at the moment.

anyway, using a genetic algorithm & with the help of avantronica, I came up with values for a function which approximates the time/param relationship of the envelopes:

float envMilliseconds(char paramValue)
{
  return (exp(paramValue * 0.0485442) - 1) * 63.185616;
}

this gets pretty close, might get even closer with more accurate measurements… but definitely close enough for visualisation etc…

I’m now reverse-engineering the sequencer… which is more tricky than I thought, with microtiming, arp, quantization amounts etc… ooofff…