I've been racking my brain for days over this.
I'm planning on using PHP with SoX to produce audio pulses over a certain amount of time. In this case i'm using frequency as a way to describe how many pulses occur per second. So a frequency of 8 is 8 pulses per second.
Example of the pulse I'll be using (Isochronic tone)
I need to know the start time of each of these pulses so that I can plot them in time when producing the audio. This is easily done when the frequency remains constant. But when the frequency changes over time, I run into the problem that it takes too much or too little time to complete the average amount of pulses.
Here's an example in Javascript (I'm using JS for now to get the maths working)
var f0 = 8; //Start frequency
var f1 = 1; //End frequency
var interval = 30; //Total time
var average_freq = (f0 + f1) / 2; //Average frequency
var pulses = average_freq * interval; //Total number of pulses needed
var pulse_start_time = 0;
for(var i = 0; i < pulses; i++) {
var delta = i / pulses;
var this_freq = f0 + (f1 - f0) * delta;
/*
need exponential formula to find start time
*/
console.log( "pulse: "+ (i+1) + ", "+
"pulse frequency: "+ this_freq + ", "+
"start time: "+ pulse_start_time);
pulse_start_time += 1 / this_freq; //This method works fine providing
//both start and end frequency are
//the same.
}
I've done a lot of researching on this subject using topics like:
Drawing sine wave with increasing Amplitude and frequency over time
Plot Frequency Sweep In Python
sine wave that slowly ramps up frequency from f1 to f2 for a given time
sine wave that exponentialy changes between frequencies f1 and f2 at given time/amount of samples
But I'm still unable to figure out how to get the start time of each pulse using these techniques, or maybe I'm going about this all wrong.
Any help will be appreciated! :)
you need to use proper math equation y=f(t) for your signal instead. In that way you will obtain also the amplitude. I do not know the properties of your signal but it does not look like logarithmic. I would construct it like this:
y=( |sin(c0*t)| + sin(c0*t) )^c1 * sin(c2*t) * c3
where:
t is time
c0=frequency of gaps / 2*Pi
c1 is sharpness of gap/signal transition
c2=frequency of pulses / 2*Pi
c3 is amplitude of signal
The first part just modulate the base signal with gaps and shaped amplitude shape, the last therm is your base signal.
The average pulses per second is not your signal frequency !!! instead it is around half of it (depends on the signal to gap ratio). Now just increment t in some loop and compute y(t) for your data. To avoid floating point rounding problems limit the t to common period between the 2 sin waves.
Related
I have a three values.
let a = 10;
let b = 200;
let c = 140;
I want to make the line scale chart by which straight line starting point is 10 and end point is 140.
Now I have to make the calculation by which 140 value will be lie in between the line.
Its like 0, 50 & 100. ) is starting point, 100 is end point and 50 is the central point.
So I pass the 50 percent so that it will be on the center.
I have made the UI. I just need to pass the percent value by which UI will be made.
Any suggestion for this will highly appreciable
If I understand you right the formula you need is
(c-a)/(b-a)*100
or in javascript
((c-a)/(b-a)*100).toFixed(1)+'%`
Im using JS in max/Msp and want to slice the buffer into sections using the golden ratio. I know that this will be a recursive function using the formula a+b/a = a/b but im not sure how to express this in javascript and how to then divide the remaining sections into golden rectangles recursively.
The golden ratio of 1.6xx talks about spiraling out, expanding.
If you start with a buffer and want to mark inwards, you can expand it by the reciprocal to shrink.
golden_ratio = ( 1 / 1.61803398875 ) // 0.6180339887498547 of 1.00
//where 1.00 is the 'whole' of your buffer
//the following values are percentage points the slices are at in the buffer
slice_1 = 1.00 * golden_ratio // .618
slice_2 = slice_1 * golden_ratio // .618^2
slice_3 = slice_2 * golden ratio // .618^3
You could calculate a given-depth slice of from an arbitrary buffer in one explicit call:
slicepoint = Math.pow(golden_ratio, slice_depth) * buffer_size
Otherwise manually performing that recursively could be from providing the initial condition (buffer size) and multiplying the last slice you just calculated by the golden ratio again. Our "last slice" would be the first condition provided, whatever buffer you've got.
some pseudocode:
A[0] = buffer_size
while n++
A[n] = A[n-1] * golden_ratio
for actual javascript code:
Slicing 1sec. of audio into 10 buffers (9 slices needed for 10 buffers)
arbitrary_buffer = 44100 //buffer length 1 sec # 44.1kHz
slices = 10; //slice count
// get the reciprocal of golden ratio
// we can just shrink the whole and mark those points as slices
golden_ratio = ( 1 / 1.61803398875 )
// creepily enough
// the reciprocal of the golden ratio is
// its same value without the integer in front of it: .6180339887498547
// so its a 61.80339887498547% of the original size per-iteration
// This is a list of our slice point locations
slice_points = new Array();
// add an initial condition (arbitrary_buffer) for the recursion
// like knowing the end of a loaf of bread before cutting
slice_points[0] = arbitrary_buffer;
// the following recursion is in the [i-1] back-tracking
// that's why this for-loop condition has i at 1 instead of 0 per usual
// we provided the initial 44100 and start with index 1 instead
// slice_point[1] should be about 27255.29890386859
for(i=1;i<slices;i++)
slice_point[i] = slice_points[i-1] * golden_ratio;
The array is populated in descending order starting at its end: 44100
You can switch those values to forward-facing if you just take
arbitrary_buffer - slice_point[i];
or, outside of the js object and back in max use [- ] and subtract the js output value from the buffer ms length from bufferinfo~'s right-most outlet, converted to samples.
You might also try using this as a velocity-map for loudness
I have a formula that generates a random integer in a given range [x,y].
rand = Math.floor(x + Math.random()*(y-x+1));
And I would like the generated integer to have a higher chance of being close to the midrange.
Here is an interesting approach.
I am trying to adapt that solution to my problem (numbers skewed towards the midrange, not the extremities), but I am struggling with the formula.
beta = Math.sin(Math.random()*Math.PI)^2;
rand = Math.floor(x + beta*(y-x+1));
I do not understand how beta works. According to this graph wouldn't the numbers generated have a higher chance of being closer to 0.5? beta always returns the same number. Didn't I implement Math.random() properly? I swear javascript is messing with me right now.
You probably need a
beta = 4 * (rand - 0.5)^3 + 0.5
function or something with a similar shape
Graph
Distribution results: http://jsfiddle.net/4hBqz/
I am trying to measure the percentage of the amount of enemies in a javascript game I am developing.
Math.round(10000000 / V.S * 100) / 100
This code works fine when V.S is over 1 million, however returns observed values such as 3400% when V.S is around the thousands, but this should be about 0.01%.
V.S is the amount of enemies
10 million is the amount of enemies needed to make you lose the game
I want to show the percentage between the amount currently and the amount needed to lose the game.
How can I make it show that?
V.S is the amount of enemies
10 million is the amount of enemies needed to make you lose the game
Your current code yields how many times V.S goes into 10 million
I want to show the percentage between the amount currently and the
amount needed to lose the game.
If you want to know what percentage of the 10 million has shown up:
var pctShown = V.S/100000; //or Math.round(V.S/100000) if you want only whole pcts
(note: reduction of dividing by 10,000,000 then * 100 to get a pct representation)
If you want the percent remaining, simply find the inverse:
var pctRemaining = 100 - V.S/100000; //or again Math.round(100 - V.S/100000)
I am trying to create a custom linear congruential generator (LCQ) in JavaScript (the one used in glibc).
Its properties as it's stated on Wikipedia are: m=2^31 , a=1103515245 , c=12345.
Now I am getting next seed value with
x = (1103515245 * x + 12345) % 0x80000000 ; // (The same as &0x7fffffff)
Although the generator seems to work, but when the numbers are tested on canvas:
cx = (x & 0x3fffffff) % canvasWidth; // Coordinate x (the same for cy)
They seem to be horribly biased: http://jsfiddle.net/7VmR9/3/show/
Why does this happen? By choosing a different modulo, the result of a visual test looks much better.
The testing JSFiddle is here: http://jsfiddle.net/7VmR9/3/
Update
At last I fixed the transformation to canvas coordinates as in this formula:
var cx = ((x & 0x3fffffff)/0x3fffffff*canvasWidth)|0
Now the pixel coordinates are not so much malformed as when used the modulo operation.
Updated fiddle: http://jsfiddle.net/7VmR9/14/
For the generator the formula is (you forgot a modulus in the first part):
current = (multiplier * current * modul + addend) % modulus) / modulus
I realize that you try to optimize it so I updated the fiddle with this so you can use it as a basis for the optimizations:
http://jsfiddle.net/AbdiasSoftware/7VmR9/12/
Yes, it looks like you solved it. I've done the same thing.
A linear congruential generator is in the form:
seed = (seed * factor + offset) % range;
But, most importantly, when obtaining an actual random number from it, the following does not work:
random = seed % random_maximum;
This won't work because the second modulus seems to counteract the effect of the generator. Instead, you need to use:
random = floor (seed / range * random_maximum);
(This would be a random integer; remove the floor call to obtain a random float.)
Lastly, I will warn you: In JavaScript, when working with numbers that exceed the dword limit, there is a loss of precision. Thus, the random results of your LCG may be random, but they most likely won't match the results of the same LCG implemented in C++ or another low-level language that actually supports dword math.
Also due to imprecision, the cycle of the LCG is highly liable to be greatly reduced. So, for instance, the cycle of the glibc LCG you reference is probably 4 billion (that is, it will generate over 4 billion random numbers before starting over and re-generating the exact same set of numbers). This JavaScript implementation may only get 1 billion, or perhaps far less, due to the fact that when multiplying by the factor, the number surpasses 4 billion, and loses precision in doing so.