i’m trying to make odd & new values in my LFOs. like 3/1 9/1 or 6/1 12/1 etc. and something like 1/2T 1/4T etc. T=triplets.
the problem is the divider of 1024 that report comma values and i’ve not completly understand how work the sync but i’ve make some try just testing it hearing and counting. not so pro.
some other mathematic info would be cool.
i’ve look at
SIDSE_M_Sync
SIDSE_M_LFO_Restart
SID_LFO_TABLE_MCLK
tonight i will post some other info, i’m @ wrk now.
Yeh, floating point won’t work The best way to do this if the values will be static (like yours), is with a table of the results of the division, rounded to the nearest integer.
However you won’t need to do that for the standard measures like 1/3,1/12,4/3,3/8, etc, that’s why midi clock is 24ppqn, its the lowest common multiple of all of the common figures. MMA were thinking about us heheheh
yes i’ve thought about the nearest value. in ex 3/1 it’s 341.33333333333333333333.
so i can use 341 instead, the difference it’s minimal. so the wave come out of the point after a lot of loops.
but i think to a function (to now it’s just an idea, no code wrote down), that restart the lfo after a given time/loop where the wave would be start in sync with the seq. so i can pseudo preserve the loop point of LFO start.
yes if 1/1 was 1536 in the sync table there was no problem. since midiclock it’s 24ppqn, we must wrote a parallel counter that for each clock use 1536 in sync, and the lfo table it’s referred to this.
yes i’ve thought about the nearest value. in ex 3/1 it’s 341.33333333333333333333.
so i can use 341 instead, the difference it’s minimal. so the wave come out of the point after a lot of loops.
Yeh, that would suck… That’s why that’s not what I mean
I find the best way to avoid floating point is to avoid floating point hehehe… Just stay with good old fashioned fractions
1024/3=341 and 1/3
or you could say
1024/3=341 with a modulus (remainder) of 1
So can use 341, but if you want it to stay in sync, you’ve gotta spread the modulus around. You can use calculations to do it, but that could be a bit too much for the PIC to handle at such high frequency.
However if you know what values you want to have available (like how you have 3/1), a nice quick way to do it is a lookup table, which has the pre-calculated period of each tick in it like so:
341
342
341
Tada, synced clocks. You just look up the value according to how many times it’s ticked, and roll that counter over every 3 ticks. But when it comes to fast stuff like LFO’s… You want to be careful how you time it… Try to look up the value pre-emptively.
Notice that I put the remainder in the middle… That’s where it really goes, because you want to just round to the nearest integer to be really accurate…it’s like
0
341 1/3 = 341 1/3 ~ 341 difference from the last is 341
341 1/3 = 682 2/3 ~ 683 difference from the last is 342 there’s our modulus
341 1/3 = 1024 ~ 1024 difference from the last is 341
Dunno how much of that you’ll be able to roll into the app though…
HTH!
Edit: I just saw your mention of the SID LFOs… if you’re thinking about doing this in the MBSID, I’m not sure it’ll work… I need to build one and figure out how the LFO’s work
In MBSEQ, triplets are generated by selecting a different predivider.
The internal 96 ppqn are divided by 6 (-> 16 ppqn) and 4 (-> 24 ppqn) to avoid fractions or expensive math
There are two reasons why I haven’t done this for MBSID yet. One reason is, that SID_SE_STATE (which propagates the predivided clock events… and more flags) is fully allocated, another reason is, that SID_BASE section 0x100..0x1ff is completely allocated as well, so that I need to find some ways to free memory before introducing such special features.
It’s still in my focus to get the firmware bugfree before starting with optimisations, a proper solution for triplets will be provided by default in a pre 2.0 release.
Of course, meanwhile you are free to tinker on your own solution, or to remove features you don’t need (variables in SID_BASE section) to get some free memory…
However you won’t need to do that for the standard measures like 1/3,1/12,4/3,3/8, etc, that’s why midi clock is 24ppqn, its the lowest common multiple of all of the common figures. MMA were thinking about us heheheh
no stryd i’ve not miss! i’ve just take a look at the MBSEQ code to improve my skill and learn about clock dividers. i’m not able at now to do that, i’m still on the way, just studying and tinkering with the support of my brother (informatic engineer), and your obviously.
well, no good news about my code, i’ve make some try nothing working for now :p, so here i’ve attached a file that can show a little (not so good for real) what can do odd lfo long periods.
2 BassLine Seq. lines, 2 notes each, other notes are glided.