[music-dsp] Pulsed laser, microwaves and infrasounds

[Tito Latini]

Hi,

I'm continuing to analyse the attack:

  https://github.com/titola/neuropa

Infrasound and signal received at 422.733 MHz:

  https://github.com/titola/neuropa/blob/master/media/infrasound.jpg

The output of the first differentiator can be obtained by integrating
the recorded sound:

sum = 0
k = 1 / 80.5
m = k / 10.35

"m" is the normalization constant to get an unitary gain.

For each sample "input":
sum = sum + input + k
output = m * sum

The integration of the previous result reveals the initial pulses:

sum = 0
k = -0.05
m = k / -164.11

For each sample "input":
sum = sum + input + k
output = m * sum

Source code for Snd editor:

  https://github.com/titola/neuropa/blob/master/src/infrasound.scm

A recent nightly recording with infrasounds:

  https://github.com/titola/neuropa/blob/master/media/night_20190516_a.wav

My window with a dry circle (May 16 2019 nigth):

  https://github.com/titola/neuropa/blob/master/media/circle_window.jpg

I'm investigate about the relation between the frequencies around
13 or 14 Hz and the signals synchronized with the voices at
frequencies 173.456 MHz, 173.880 MHz, 173.956 MHz (the signal at
460.557 MHz is near 422.733 MHz):

422.733 ---> 1 / 0.18 = 5.55 Hz
422.733 / 173.456 = 2.437   ---> 2.437 / 0.18 = 13.54 Hz
422.733 / 460.557 = 0.918   ---> 0.918 / 0.18 = 5.1 Hz

The document also contains informations about a radar with side effects.

Tito Latini
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] Radiation sampling with aliasing

[Tito Latini]

Hi,

I hold out to the last and continue the analysis of the attack:

  https://github.com/titola/neuropa

I have recorded pulses repeated with frequency 78250 Hz, sometimes
replaced with 31300 Hz. I have noticed that these pulses allow the
sampling of a signal hidden into the overall radiation (diffuse and
direct):

  https://github.com/titola/neuropa#radiation-sampling-and-aliasing

  https://github.com/titola/neuropa/blob/master/media/sampler.jpg

The section contains a table of the frequencies obtainable through the
aliasing of the pulses of the received fake GSM, with sampling
frequencies 31300 Hz and 78250 Hz.

A recipe to generate hidden signals is:

  - STFT (Short Time Fourier Transform) to divide the signal into
modulated sinusoids.

  - Transmit these oscillations in scattered or arbitrary order
(diffuse and/or direct radiation) with central frequencies
obtained through aliasing.

  - Send pulses through the electrical grid. The pulse frequency is
equal to the sampling rate used to compute the central frequencies.

I think it is also possible to use sampling radiation, the electrical
grid and/or the telephone system for TEMPEST techniques.

I have also analysed the beats between the impulsive radiation and the
military VLF 20760 Hz from Tavolara Island (Sardinia, Italy):

  
https://github.com/titola/neuropa#beat-between-impulsive-radiation-and-military-vlf

5/2 is the magic number of the whole attack.

There is a section with some audio recordings:

  https://github.com/titola/neuropa#audio-recordings

It includes the resonant toy of the idiots in the subsection
"Amplitude modulated oscillation of 100 Hz".

Another year without justice, thanks to the experts on playstation and
fantacalcio, the cowards and the corruption.

Tito Latini
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] Infrasounds and low frequencies from the electrical grid

[Tito Latini]

Hi,

I have updated the page at

https://github.com/titola/neuropa

with a simulation of the tinnitus plus the infrasounds generated from
the electrical grid. The antennas of the electric meters are multiple
of some signals.

I think the thugs monitor the peaks of the infrasounds repeated every
1.92 seconds also to take the variation of the nominal frequency to
tune the signals, for example the duration between 9/49 (0.183s) and
9/51 (0.176s).

Tito Latini
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] Analysis of an electromagnetic attack

[Tito Latini]

Hi,

I'm writing a document about my experience here:

  https://github.com/titola/neuropa

The following video shows a part of the signal directed to my head:

  https://github.com/titola/neuropa/blob/master/media/head_945mhz.mp4

Any time a RF pulse is absorbed by the cerebral tissue, the
temperature rises of 5e-6 °C [1]. The rapid thermal expansion produces
a thermoelastic wave that travels to the inner ear. Therefore the
criminals use that thermo-acoustic demodulator to send vocal messages
to me through ultrasounds.

If you hear a voice in the audio file

  https://github.com/titola/neuropa/blob/master/media/cuba_attack_decoded.ogg

also the US embassy in Cuba [2] unconsciously suffered a similar offensive
action. The steps to get that result from the recording [3] are:

  - FIR filter to select the content between 6 and 9 KHz.

  - Pitch 1 octave up (optional).
example: rubberband -f2 in.wav out.wav

  - Slope detector.
pseudo-code: env_follower(diff(input))

  - BP filter to select the content between 100Hz and 3.5KHz.

The document contains what I can unequivocally explain.


[1] J.A. Elder and C.K. Chou. Auditory Response to Pulsed Radiofrequency Energy.

[2] https://en.wikipedia.org/wiki/Embassy_attack_accusations_in_Cuba

[3] Josh Lederman and Michael Weissenstein. Dangerous sound? What
Americans heard in Cuba attacks. AP News, October 2017.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] a family of simple polynomial windows and waveforms

[Tito Latini]

On Mon, Aug 08, 2016 at 07:05:17PM -0700, James McCartney wrote:
> On Tue, Jul 5, 2016 at 2:42 PM, James McCartney  wrote:
> 
> > In the same vein: a family of smoothed sawtooth waves
> >
> > f(x) = x - x^a
> >
> 
> changing this to :
> 
> f(x) = x - sgn(x)*abs(x)^a
> 
> allows 'a' to be continuously variable, not just an odd integer.
> sgn(x) is the signum function.

ooh, what a surprise!

https://lists.columbia.edu/pipermail/music-dsp/2016-July/000881.html

tito lennon:
> It is also possible to modulate 'a', floating point >= 1.0:
>
> x = phasor between -1 and 1
> y = mirror(x, 0, 1) = triangular wave
> ...
> window = 1 - y^a
> output = x * window

where `y = mirror(x, 0, 1) = |x|' here and signum(x) is useless:

  x * (1 - |x|^a)


and nothing to get hung about
strawberry fields forever
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] idealized flat impact like sound

[Tito Latini]

> My problem was that a short segment of random isn't spectrally
> straigh-line flat.

My apologies, I've misunderstood the problem.

An idea is to create a kind of "ideal" residual: i.e. the transient is
a band-limited impulse and an enveloped (maybe expdec) noise is added
after two, three or a few samples. The parameters are:

- noise env
- delay of the noise in samples
- transient-to-noise ratio (% of transient, % of noise)

The transient (band-limited impulse) is spectrally flat and the noise
adds the reverberation (you could start with a very low level).
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] idealized flat impact like sound

[Tito Latini]

sorry, that's a decay, so out is "(1 - y) * rand()":

T = 1 / samplerate
p = exp(log(0.001) * T / t60)

y = 1 + p*(y1 - 1)
y1 = y
out = (1 - y) * rand(-1.0, 1.0) * gain
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] idealized flat impact like sound

[Tito Latini]

On Wed, Jul 27, 2016 at 10:33:40PM +0200, gm wrote:
> [...]
> So my question for now is: how can we synthesize completely flat 
> decaying noise?
> (is it even possible?)

I think the modulation between expdec and white noise is ok:

T = 1 / samplerate
p = exp(log(0.001) * T / t60)

y = (1 - p)*gain + p*y1
y1 = y
out = y * rand(-1.0, 1.0)
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] efficient running max algorithm (Evan Balster)

[Tito Latini]

> Hi, OP here.
>
>
> Unfortunately I don't understand all you are saying, due to my lack of C
> and Z-transform skills.
>
> This is what I understood, please correct me if I'm wrong:
> - My algo is called a binary max-tree.  (When used with max as an
>  operator)
> - The other algo discussed is faster on average, but has spikes that are
>  higher.
>
>
> Some questions:
>
> - IIUC, none the other algos mentioned can cheaply vary the window size
>  at run-time, right?

Your algo is not cheaper: the performance-time loop of your compiled
slidingsum.dsp contains two for-loops (from compute() in slidingsum.cpp):

for (int i=14; i>0; i--) fVec3[i] = fVec3[i-1];
for (int i=6; i>0; i--) fVec2[i] = fVec2[i-1];

and maxsize is 8 (maybe the loops are unrolled in this simple case but
it's not always Sunday).

A simple implementation of my suggested double buffering (the alternative
and better modulation for the initial posted code) uses two loops, one
"from i to oldsize-1" (max 7 in this case) and one "from 0 to i-1" to
update max 8 slots instead of 15+7=22 (the numbers are just emphasis
and the loops are possibly unrolled in this case). Besides, the two loops
are used only if the winsize changes and it is minor than the old size.
It is cheaper than your generated code, also by moving the two loops within
the performance-time loop.

> - None of them generalize for other binary operators instead of max,
>  right?  (mine works for any operator that is associative and
>  commutative)

Nope. I'll show "max" for simplicity but the next example should work in
similar contexts. We can use a circular buffer, a binary max heap and
new functions to work with the heap instead of add/subtract to/from
the accumulators:

[just a simple idea, not the state of the art]

a) remove the oldest from the heap
b) insert the new to the heap

---[alternative 1]---

a) on the heap: replace the oldest with the new (binary search and swap)
b) on the heap: update the position of the new (binary comp)

coda:

c) update the circular buffer and increment the index (modulo winsize)
d) max is heap[0], the root

Again, if winsize changes and it is minor than the old size, it is
necessary to remove the oldest "old_size - new_size" values from the heap.

---[alternative 2]---

We can avoid the binary search (a) by using a heap where the elements are
the indexes of the buffer values and an array (or a different structure
for the elements of the heap, i.e. index and position in uint32 if
maxsize is two bytes) to store the positions of the indexes on the heap.

For example, with two arrays of type int called "heap" and "pos":

heap[k] = buffer_index;
pos[buffer_index] = k;

binary-search-and-swap is unnecessary because we know the index of the
oldest value on the heap:

heap[pos[curr_buffer_index]]

and we use that heap position to start the binary comp with the new
value because the buffer index is the same (it is incremented after
the insertion).

The max value is:

buffer[heap[0]]

> - Can I further optimise this algo by doing a linear search for the
>  first log2(w) samples?  Why? How?

Where? :)
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] highly optimised variable rms and more

[Tito Latini]

I'll try the follow change:

curr_sum += input;   // add the new and
acc -= buffer[i];// subtract the oldest
buffer[i] = input;
if (i < last) {  // last is `size - 1'
i++;
sum = curr_sum + acc;
} else {
sum = acc = curr_sum;
i = curr_sum = 0;
}
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] highly optimised variable rms and more

[Tito Latini]

On Tue, Jul 19, 2016 at 11:40:06AM -0500, Evan Balster wrote:
> [...]
> *//Call this exactly once per cycle to prevent drift.*
> inline void cycle()  {_dn = _up;   _up =
> 0.0f;}
> };

Thanks Evan, that's really a good idea.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] highly optimised variable rms and more

[Tito Latini]

On Mon, Jul 18, 2016 at 02:11:13PM +0200, Johannes Kroll wrote:
> I have used something similar to implement per-sample RMS. Here is an
> implementation in Extempore/xtlang:
> [...]

nice -- if you add the modulation of the length, we have a similar painting.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] highly optimised variable rms and more

[Tito Latini]

On Mon, Jul 18, 2016 at 01:25:39PM +0200, Bart Brouns wrote:
> Thanks for looking into this.
>
> I can't read lisp much, [...]

The recipe is in C (three lines to show a circular buffer), but the
single-line comment is enough.

> [...] but it reminds me of another faust
> implementation where you add each new value and then substract the value
> of 'size' samples ago.
>
> Is it that one?

I don't know but I think it was used by some bearded hominids at
Neanderthal Valley, many many years ago (before '70).

> If so: I heard it needs special handling of floats to prevent drift, any
> thoughts?

I'm using double float (no tested single precision) without apparent
problems.  For the modulation of the size, my method is not precise
but I have a hint about double buffering in a recent post.

> Does this method generalize to other operators except plus?

dunno but if you use */ remember division-by-zero.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] highly optimised variable rms and more

[Tito Latini]

On Sun, Jul 17, 2016 at 03:35:52PM -0700, Phil Burk wrote:
> Hello Tito,
> 
> I may be misinterpreting your code. But it looks like there is a potential
> buffer overflow.
> 
> I assume your buffer indices can go from 0 to max_size-1
> If size == max_size then i should be between 0 and size-1
> 
> But in the code below, if i is size-1 then it can be incremented to size.
> That might be one past the end of the array.
> 
> Maybe this code:
> i = (i >= size ? 0 : i + 1);
> should be:
>i++;
>if (i >= size) i = 0;

ah ah you are a giant Phil!

Sorry, the c code was a pedestrian translation from lisp.
I have discovered and fixed the problem after my post some
days ago (notice the elegance: "Safe" instead of "Fix" :)

    commit 75789ce1decb69abd80af0e854bfd09df79558b5
Author: Tito Latini <tito.01b...@gmail.com>
Date:   Fri Jul 15 12:49:23 2016 +0200

Safe buffer size for MAF.

with:

-  (with ((data (make-frame max-size :zero-p t))
+  (with ((data (make-frame (1+ max-size) :zero-p t))


then I have changed the code (*)

neuron number 1: "probably you'll receive a correction from the list".
neuron number 2 (the last): "you can send a correction the next week".
neurons 1+2, an octave apart: "continue to see moto gp"

Note: if "size" changes and it is less than the old_size, I use one
loop for efficiency but it is not the perfect solution. It's better
to copy the last "new_size" values into a new buffer, decrement the
accumulator, update "i = new_size - 1" and switch the buffer.

[Thanks Ethan for the interesting introspection]

(*) new lisp code:

(define-vug maf (in (max-size positive-fixnum) (size positive-fixnum))
  "Moving Average Filter."
  (with ((data (make-frame max-size :zero-p t))
 (sum 0.0d0)
 (old-size 0)
 (index 0)
 (last (progn
 (when (< size old-size)
   ;; Update the sum
   (loop for i from size below old-size do
(decf sum (smp-ref data i))
(setf (smp-ref data i) +sample-zero+))
   (setf index 0))
 (1- (setf old-size (min size max-size))
(declare (type pointer data) (type sample sum)
 (type non-negative-fixnum index old-size last))
;; Subtract the old, add the new and update the index
(setf sum (+ (- sum (smp-ref data index)) in))
(setf (smp-ref data index) in)
(setf index (if (< index last) (1+ index) 0))
(/ sum size)))
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] highly optimised variable rms and more

[Tito Latini]

On Fri, Jul 15, 2016 at 12:23:55AM +0200, Bart Brouns wrote:
> Hi everybody,
> 
> Let me introduce myself:
> My name is Bart Brouns and I've been doing some form of dsp for almost
> 20 years.

Hi Bart

> Started with a Nord Micro Modular, then learned pure-data, and for the
> last 3 years moved to faust. http://faust.grame.fr/
> 
> I made an algorithm that applies a binary operator to the last N
> samples, where N is variable at runtime.
> 
> It's very cheap: it uses just two delay lines and two operators for each
> doubling of the number of samples you want to apply the operator to.
> So for calculating the sum of the last 65536 samples, you need just 32
> delay lines and 32 plus operators.
> You can still continuously vary the number of samples to compute at
> runtime.
> 
> It is written in faust, but I hope the comments make it clear what I'm
> doing:
> 
> https://github.com/magnetophon/faustCompressors/blob/master/slidingReduce.lib
> 
> If it helps, here is the cpp version as produced by the faust compiler,
> with + as the operator and maxN = 8:
> https://github.com/magnetophon/faustCompressors/blob/master/slidingsum.cpp
> 
> I would love to know if this is a known algorithm.
> I imagine it is, but have no idea how to find out.

Sorry, I don't know if your algorithm exists. However, I have used a
different technique written from scratch to implement a moving average
filter for my lisp tool.

There is a buffer with an index (if you prefer, a delay line with length
max_size). "size" represents the number of the values to sum and it is
less than or equal to max_size. The core of the algo is:

/* Subtract the oldest, add the new and update the index. */
sum = sum - buffer[i] + input;
buffer[i] = input;
i = (i >= size ? 0 : i + 1);

If "size" changes and it is less than the old size, it is necessary to
decrement the accumulated sum:

for (j = size; j < old_size; j++) {
sum -= buffer[j];
buffer[j] = 0;
}
old_size = size;

That's all. The original code of my MAF is

;;; Virtual UGen from incudine/src/vug/filter.lisp
(define-vug maf (in (max-size positive-fixnum) (size positive-fixnum))
  "Moving Average Filter."
  (with ((data (make-frame max-size :zero-p t))
 (sum 0.0d0)
 (old-size 0)
 (size (prog1 (min size max-size)
 (when (< 0 size old-size)
   ;; Update the sum
   (loop for i from size below old-size do
(decf sum (smp-ref data i))
(setf (smp-ref data i) +sample-zero+)))
 (setf old-size size)))
 (index 0))
(declare (type pointer data) (type sample sum)
 (type non-negative-fixnum index old-size)
 (type positive-fixnum size))
;; Subtract the old, add the new and update the index
(setf sum (+ (- sum (smp-ref data index)) in))
(setf (smp-ref data index) in)
(let ((new (1+ index)))
  (setf index (if (>= index size) 0 new)))
(/ sum size)))
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] a family of simple polynomial windows and waveforms

[Tito Latini]

On Tue, Jul 05, 2016 at 02:42:59PM -0700, James McCartney wrote:
> In the same vein: a family of smoothed sawtooth waves
> 
> f(x) = x - x^a
> 
> evaluated from x = -1 to +1
> 
> where 'a' is an odd integer >= 3.
> 
> the greater 'a', the greater number of harmonics.
> 
> plot:
> 
> http://i.imgur.com/dqQQItT.png

Thanks again.

I just noticed that if a-1 is a power of two:

a = 2^n + 1  where n = 1, 2, 3, ...

x - x^3  = - (x - 1) x (x + 1)

x - x^5  = - (x - 1) x (x + 1) (x^2 + 1)

x - x^9  = - (x - 1) x (x + 1) (x^2 + 1) (x^4 + 1)

x - x^17 = - (x - 1) x (x + 1) (x^2 + 1) (x^4 + 1) (x^8 + 1)

x - x^33 = - (x - 1) x (x + 1) (x^2 + 1) (x^4 + 1) (x^8 + 1) (x^16 + 1)

...

The window is:

b = a - 1
c = b / 2

1 - x^b = - (x - 1) (x + 1) (x^2 + 1) (x^4 + 1) ... (x^c + 1)

= - (x^2 - 1) (x^2 + 1) (x^4 + 1) ... (x^c + 1)


log2(b)-1
  /===\
   ! ! n
   ! !2
1 - x^b = (x - 1)  ! !  (x   + 1)
   ! !
  n = 0


The name of the game is the same with y = x^(2^n) where n = 1, 2, 3, ...

1 - x^b = - (y^2 - 1) (y^2 + 1) (y^4 + 1) ... (y^(b*2^(1-n)) + 1)
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Trouble Implementing Huggins Binaural Pitch

[Tito Latini]

I think the Ethan's suggestion about the difference between left and
right channel is the answer. We hear sum and difference thanks to the
Natural Binaural Technologies (unknown copyright).

Two seconds of the difference with a (artificial) post-gain of 20 dB
is recorded in the attached huggins-test-diff.ogg (21K).

The used tool is not important, sexprs show the parameters of my test
(from implementation_of_Huggins_binaural_pitch.pdf with freq 280Hz
and sample rate 48kHz):

(dsp! huggins-binaural-pitch (freq amp post-gain (diff-p boolean))
  (with-samples ((wt (* freq *twopi-div-sr*))
 (r (- 1 (* 0.03 0.5 wt)))
 (a1 (* -2 r (cos wt)))
 (a2 (* r r))
 (in (white-noise amp))
 (g (db->lin post-gain)))
(vuglet ((ap (x)
   (biquad x a2 a1 1 1 a1 a2)))
  (maybe-expand in)
  (if diff-p
  (out (* g (- in (ap in
  (out in (ap in))

(bounce-to-disk ("/tmp/huggins-test.wav" :duration 30)
  (huggins-binaural-pitch 280 .5 0 nil))

(bounce-to-disk ("/tmp/huggins-test-diff.ogg" :duration 2 :channels 1
 :header-type "ogg" :data-format "vorbis")
  (huggins-binaural-pitch 280 .5 20 t))


huggins-test-diff.ogg
Description: Binary data
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Tito Latini]

SoX Resampler Library (https://sourceforge.net/projects/soxr) also provides a
quick cubic interpolation with a header (soxr-lsr.h) compatible with 
libsamplerate.

(audacity uses soxr)
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] proper scaling of an FFT

[Tito Latini]

On Wed, Nov 04, 2015 at 08:56:05AM -0800, Phil Burk wrote:
> What is the "right" way to scale the inputs of an FFT.
> 
> I have implemented some FFT functions in JSyn. The goal is to support
> spectral analysis, processing and synthesis for music applications.
> 
> I would like to be able to measure the amplitude of various sinewave
> partials in the original signal. With my current scaling, if I do an FFT of
> a sine wave with amplitude 1.0 aligned with a bin then the magnitude comes
> out 1.0.
> 
> magnitude = sqrt(real*real + imag*imag);
> 
> Also my FFT and IFFT are inverse functions:   x==IFFT(FFT(x))
> 
> My current scale factors are 2.0/M for FFT and 0.5 for IFFT. I am happy
> with this. But I see many conflicting recommendations in the literature
> that suggest I am doing it wrong.
> 
> In this MatLab forum,
> http://www.mathworks.com/matlabcentral/answers/15770-scaling-the-fft-and-the-ifft
> they recommend  1/M and M, or 1/sqrt(M) and sqrt(M).  They say it is
> important that the product of the scale factors is 1.0. But then the IFFT
> is not the exact inverse of the FFT.
> 
> Is there a "right" way or a "wrong" way or is there just "my" way?

Generally I prefer to scale the values only one time, at the end of
the game.  I'm using FFTW library [1] with Incudine [2], and the
original transforms r2c and c2r (luckily) are unnormalized. Instead
of scaling the result of r2c, I update the scaling factor within the
structure used for the fft. For example, after

(defvar *fft* (make-fft 1024))
(describe *fft*)
...
SCALE-FACTOR = 9.765625d-4
...

If it is necessary to process the result of the analysis, I use
separated analysis buffers (inspired by ChucK's UAnaBlob [3]).
If a process further scales the data, for example by sqrt, only the
scaling factor of the analysis buffer is updated instead of
normalizing all the values, i.e.

scl = sqrt(scl) = 1/sqrt(N)

and the scaling factor of the original fft remains the same, so it is
possible to use other analysis buffers to do other parallel processing.

Finally, the ifft routine scales the unnormalized original c2r by the
(possibly updated) scaling factor of the analysis buffer.

Besides, if ifft is used without fft, the scaling factor is simply 1
(with an internal and fixed scaling factor, it is necessary to scale
the values of the input buffer of the ifft: x*m/m).

Tito


[1] http://fftw.org/

[2] http://incudine.sourceforge.net/

[3] http://chuck.cs.princeton.edu/doc/language/uana.html
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] magic formulae

[Tito Latini]

On Thu, Nov 27, 2014 at 01:54:15PM +, Victor Lazzarini wrote:
 Thanks everyone for the links. Apart from an article in arXiv written by 
 viznut, I had no
 further luck finding papers on the subject (the article was from 2011, so I 
 thought that by
 now there would have been something somewhere, beyond the code examples and
 overviews etc.).

It seems a cellular automata 1D with a loop of rules for any cell,
where a rule is determined by a bitwise operation. A generic example
with only one byte (mask could fix the number of the states with a int):

start   1 1 0 1 0 0 1 0
rule 1  x x x x x x x x
rule 2  x x x x x x x x
...
rule n  0 1 0 0 1 0 1 1
rule 1  x x x x x x x x
rule 2  x x x x x x x x
...
rule n  0 1 1 1 0 1 1 0
rule 1  x x x x x x x x
...

and I presume the possible effects follow the four Wolfram's classes
(limit points, cyclic pattern, chaotic and more complex behaviour).
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] Incudine support to forge Virtual UGens

[Tito Latini]

Hi all,

the last year I started to write Incudine, a heavy Music/DSP
programming environment for Common Lisp on which sounds can be hammered
and shaped. :-)

Incudine provides a mechanism for defining primitive unit generators
on-the-fly and scheduling sample accurate callbacks.

A work in progress but it is starting to be interesting.

The page of the project is

  http://incudine.sourceforge.net


Tito Latini
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Incudine support to forge Virtual UGens

[Tito Latini]

On Mon, Jun 24, 2013 at 09:30:15AM -0700, Phil Burk wrote:
 Hello Tito,
 
 I added a link to Incudine here:
 
 http://www.portaudio.com/apps.html
 
 Good luck with the project. Looks great.

Thank you so much
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Incudine support to forge Virtual UGens

[Tito Latini]

Theo Verelst wrote:
 Would you mind explaining somewhat about the motivation for the 
 scaffolds of YetAnotherAudioRenderingProgram ?

I started from scratch, a lot of ideas were born during the writing of
the code.

yet-another-audio-rendering-program is only the surface. When I use a
computer for music, I always think about the path from brain to the
speakers through the machine. Before the speakers and without a
soundfile there is not audio rendering but immense lands to explore.
I use a REPL in Common Lisp during the trip.

Tito Latini
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp 
links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp