Hey
Was wondering what input values you would use for the lfo/saw lin? The inlet says frequency, but I tried setting 19 on a dial/p for 19hz speed but that was way faster than 19hz. Should I use 0.19 to get 19 hz instead?
Thanks
Hey
Was wondering what input values you would use for the lfo/saw lin? The inlet says frequency, but I tried setting 19 on a dial/p for 19hz speed but that was way faster than 19hz. Should I use 0.19 to get 19 hz instead?
Thanks
I can't really help you, because the frequency is only shown on the LFO object, and if you put something into it, it doesn't show the result, so I tried just comparing the output using a display object, and found that around 19Hz it produced a strange result in the display, it may be something to do with a stroboscopic effect or something, I really don't know, look at the the screen capture I made :
@mtyas you're seeing stroboscopic effects indeed. Use disp/kscope for faster wave visualizations.
@jaffasplaffa please let me focus my efforts on bugfixing 1.0.8, ok?
Hey @mtyas
The pitch inlet on those lfo/the regular ones) are scaled to octaves. If you connect a dial with a value of -12 you will half the frequenzy set on the lfo itself.
But yeah, looks like some artifacts are being produced in that scope
But it is not those lfos I am refering to. It is these ones. They are different and doesnt have any knob on itself. It is the ones with "lin" in the name. The lfo speed can only be set by adding a dial to the frequenzy input. THough I played around wiht it last night I stil havent figured it out. I tried with 0.19 for 19hz.... Bu that didnt work. But when I set it to 0.21 it seems like to play the file back at the right rate, which is 19hz. It is a bit unclear to me what is going on. Need to play around with it a bit more
Sorry Johannes. Didnt mean to take your attention away from bugfixing. It was a general request. Maybe other users had found out the scaling for the frequency input.
the problem is its tricky to explain , or at least for me , since the explanation is partly down to the representation in binary of floats and how they are used to drive the phase of oscillators/lfo.
the key is , its not frequency, if you hover over the inlet it says 'phase increment'
i.e. its the amount the phase (think of as time t) is increased each cycle (k-rate or a-rate as appropriate)
so, the next part of the puzzle is knowing the range of the phase, well, its the number of bits... including the signed bit,
so I think from memory this is 9, so its 2^9 = 512. then you using k-rate, so thats at 3khz (k-rate)
using that you can calculate the frequency.... when I finally figured this out (with some help from johannes) I worked out an equation that relates it to Hz, but now Ive lost the piece of paper (I've moved recently!)
sorry i dont really have time to go find/work out the definitive answer, but with the above you should be able to work it out
Thanks for the input. Have been shooting in dark with these objects for a while. Will try to understand this, hehe
@Jaffasplaffa
With the input of the rockafella thread I've come to this.
These are the scaling values you have to set the math/gain:
1Hz 10.922664
0,1Hz 1.0922664
0,01 Hz 0.10922664
As Johannes pointed out you can copy paste these values when you hit the button you want to set it to.
Lfo Scaling in Hz.axp (2.8 KB)
ok, so I had to go look at this for my own interest again
so a float (non audio) is represented as 11 bits (including sign, and usually we only show the bottom 6 bits, = 64, so allowing some headroom for calculations)
so 2^11 = 2048, so that should be the cycle length, which has to be completed at 3000hz
BUT , and this I dont understand and would like @johannes to clarify
for some reason, the inlet is divided by 4 , (inlet_freq >> 2)
we actually need 4 times the above in one cycle , or 2^13 = 8192
8192 / 3000 ( hz. k-rate) = 2.730666666666667 , hence the number above.
so my question for @johannes, is why divide by 4, is this just to bring into a more 'reasonable range' ?
(it confused me )
Nice. Just tested the scaling and it is pretty close.
But if you compare it to the lfo saw r set to 1hz you will notice a drift. It is not precise.
Need to do some more finetuning
over what time period? how much?
seems to me, that the saw r when read on the UI may not be exact... (its only shown to 2 dec places) and the above also is an 'in-exact' number (0.0006666 recurring), both these 'errors' may build up over time (at 3000 times/sec)
also, out of interest... why does this matter in a 'musical context' ?
(or is this academic/for understanding?)
in sound design, Id say a small error is not going to make a difference, and if you wanted something to be in sync, you would share the same source (i.e. not run from 2 different lfos)
similarly if your using for timing, again one source , that is potentially divided, is probably better than multiple lfos.
though I grant, if your syncing to something external things are different, but setting in Hz is not probably going to 'cut the mustard', you'd probably need sync'ing and possibly to use PLL to avoid jumps.
10 seconds I would say. If I put a saw r connected to a scope and then a saw lin underneath with a scope AND a rest button connected to both lfos, you will notice that they drift a part pretty fast after resetting them.
I guess a little bit of both. If you want to sync the lfo to a BPM it would be necessary to be able to set a precise frequency. I can do with 2 decimals but it has to be pretty precise.
But also for understanding. Been making a lot of stuff, just for the fun of it, but now I wanna try and make things a little more precise
But sometimes a sound uses more that one synced lfo. For example one of them has a cycle of 4 bars and one has a cycle of 1 bar.
Yeah I think this needs more time to figure out how to use this object right. I am pretty sure it has got a lot of potential, just need to understand it better.
Anyway, thank you for getting back on the subject was getting a bit stuck , but this helped.
Can you do this in Axoloti now? Sync to midi clock? Or the PLL idea ?