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

2016-07-18 Thread Johannes Kroll 
Hi,

On Fri, 15 Jul 2016 10:20:28 +0200
Tito Latini  wrote:

> 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);

I have used something similar to implement per-sample RMS. Here is an
implementation in Extempore/xtlang:

; calculates RMS for each input sample
; operations per sample are roughly: one sqrt, 2 mul, 4 add/sub.
(bind-func rms_c
  (lambda (length)  ; in seconds
(let* ((bufsize:i64 (convert (* length SAMPLERATE)))
   (buf:SAMPLE* (zalloc bufsize))
   (bufidx:i64 0)
   (accum:SAMPLE 0.)
   (accumul:double (/ 1.0 (convert bufsize
  (lambda (s:SAMPLE)
(let ((previdx:i64 (modulo (+ bufidx 1) bufsize))
  (prevval:SAMPLE (pref buf previdx))
  (val:SAMPLE (* s s)))
  (set! accum (- (+ accum val) prevval))
  (pset! buf (modulo bufidx bufsize) val)
  (++ bufidx)
  (convert (sqrt (* accum accumul)) SAMPLE))

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

Re: [music-dsp] Real-time DSP Experience with Python

2016-05-25 Thread Johannes Kroll 
On Wed, 25 May 2016 09:29:30 -0300
Eder Souza  wrote:

> Python is known as a friendly language, rapid developments, but with poor
> performance, I've never seen anyone here saying that tried something in
> real time using python, so I decided to test using some lib's (numpy, scipy
> and pyaudio), so here one pitch shift running in real-time with input
> keyboard control, for me can be a great choice to test and prove concepts
> without writing thousands of lines using C, I wonder, has anyone ever tried
> something similar and achieve good results?

It probably depends on what you mean by "real time". I've seen python
bindings for JACK. I don't see how it would be possible to write
realtime-safe code in Python, as there doesn't seem to be a way to
control realtime-unsafe operations, i.e. memory allocations and
deallocations. Such things are handled under the hood by the
interpreter, with no way to know about them or control them (that I
know of).

Performance may be another issue, or not, but the realtime-safeness is
the bigger problem I think.

It may seem to "work" in practice, on your machine, with huge buffer
sizes, with the right weather... So it's probably OK to sketch things
before implementing them in C or something else. But distributing a
JACK program implemented in Python, making people believe they can use
it in a realtime studio setup without causing hard-to-debug underruns
at some point, is probably a bad idea.

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

Re: [music-dsp] filter smoothly changeable from LP-BP-HP?

2013-02-11 Thread Johannes Kroll 
On Mon, 11 Feb 2013 10:28:17 -0500
robert bristow-johnson r...@audioimagination.com wrote:

 On 2/10/13 12:13 PM, Johannes Kroll wrote:
  On Sun, 10 Feb 2013 03:23:54 -0800
  Bram de Jongbram.dej...@gmail.com  wrote:
  does anyone know of a filter design that can smoothly be changed from
  LP to BP to HP with a parameter? IIRC LP/AP/HP could be done simply by
  perfect reconstruction LP/HP filter pairs, but never seen something
  similar for BP in the middle...
 
  The filter doesn't need to be perfect, it's for something
  musical/creative rather than a purely scientific goal...
  This may sound naive, but would it not be possible to chain an LP and a
  HP filter in series and adjust their dry/wet rates according to
  parameter?
 
 
 it's not naive (but it's parallel, not chained in series) and at one 
 time in the distant past, we called that the Tone control.

I was serious :) It's not a single filter design, but it should do,
right?

And to get a BP you would have to chain LP+BP in series, not in
parallel, no? ... Perhaps I misunderstood what Bram wants to do.

--
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] filter smoothly changeable from LP-BP-HP?

2013-02-11 Thread Johannes Kroll 
On Mon, 11 Feb 2013 17:43:05 +0100
Johannes Kroll jkr...@lavabit.com wrote:


 And to get a BP you would have to chain LP+BP in series, not in
 s/BP/HP
 parallel, no? ... Perhaps I misunderstood what Bram wants to do.
 

--
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] filter smoothly changeable from LP-BP-HP?

2013-02-11 Thread Johannes Kroll 
On Mon, 11 Feb 2013 12:52:00 -0500
robert bristow-johnson r...@audioimagination.com wrote:

 On 2/11/13 11:43 AM, Johannes Kroll wrote:
  On Mon, 11 Feb 2013 10:28:17 -0500
  robert bristow-johnsonr...@audioimagination.com  wrote:
 
  On 2/10/13 12:13 PM, Johannes Kroll wrote:
  On Sun, 10 Feb 2013 03:23:54 -0800
  Bram de Jongbram.dej...@gmail.com   wrote:
  does anyone know of a filter design that can smoothly be changed from
  LP to BP to HP with a parameter? IIRC LP/AP/HP could be done simply by
  perfect reconstruction LP/HP filter pairs, but never seen something
  similar for BP in the middle...
 
  The filter doesn't need to be perfect, it's for something
  musical/creative rather than a purely scientific goal...
  This may sound naive, but would it not be possible to chain an LP and a
  HP filter in series and adjust their dry/wet rates according to
  parameter?
 
  it's not naive (but it's parallel, not chained in series) and at one
  time in the distant past, we called that the Tone control.
  I was serious :) It's not a single filter design, but it should do,
  right?
 
  And to get a BP you would have to chain LP+BP in series, not in
  parallel, no? ... Perhaps I misunderstood what Bram wants to do.
 
 
 well, if they're in series, changing the gain on any component in the 
 chain merely changes the gain on the whole thing.  it does not change 
 the shape.  so i am not completely understanding what you're suggesting.

Not the gain, the dry/wet ratio, i.e. the amount of signal which
gets passed through the filter untouched vs the filtered signal. 

If you pass the signal through an LP first, and the result through a
HP, you get a BP. If you then adjust the dry/wet ratio of both filters,
you should get something that smoothly fades between LP, BP and HP.

So you would use an input parameter P (0..1), and the wet ratio of the
LP and HP. 

At P=0.0, set LPwet to 1.0 and HPwet to 0.0 (pure lowpass)
At P=0.5, set LPwet to 1.0 and HPwet to 1.0 (bandpass)
At P=0.0, set LPwet to 0.0 and HPwet to 1.0 (pure highpass)

Where XPwet is the dry/wet ratio, 0 is completely filtered and 1 is
completely unfiltered (the original signal).

Put these three points in a table and do linear interpolation between
them for values of P. So with P=0.25, you get LPwet=1.0 and HPwet 0.5,
which is a 50/50 mix between LP and BP... And so on.

You would probably choose slightly different frequencies for the LP and
HP, depending on how steep the filters are and how large you want the
BP to be.

May not be the most elegant way but it should be easy to do if you
already have the LP and HP filters as building blocks. It could even be
done in something like puredata, without writing code.
I thought that was kind of what the OP wanted.


 i don't know how to get BP in the middle of an LP and HP without 
 introducing a sorta quadratic gain function.
 
 suppose you have three filters, LPF, BPF, and HPF (let's say you get 
 them outa the cookbook) all with the same resonant frequency and Q.  now 
 let's say you have a control parameter, u, that is -1 for LPF, 0 for 
 BPF, and +1 for HPF.  you can come up with a set of 2nd-order Lagrange 
 polynomials ( http://en.wikipedia.org/wiki/Lagrange_polynomial ) that 
 will go through 1 for the filter you want and takes on 0 for the two 
 filters you don't want.
 
 for LPF it is:gain_LP(u) =   (1/2)*u*(u-1)
 
 for BPF it is:gain_BP(u) =   (-1)*(u+1)*(u-1)
 
 for HPF it is:gain_HP(u) =   (1/2)*u*(u+1)
 
 attach those gains to the corresponding filters and add the results 
 (filters in parallel) of those weighted filters.  if you're using the 
 cookbook (or most other definitions), you will see that the denominator 
 coefficients are the same for all three filters, so these gain factors 
 apply only to the numerator coefs.  you can smoothly pass from purely 
 LPF, through purely BPF, up to a purely HPF as u moves from -1 through 0 
 up to +1.

So you would in effect subtract parts of the filter outputs from the
signal? Would that not give problems when the filters create phase
variances at different frequencies? (Disclaimer: I don't completely
understand the maths behind what you posted and I'm not a filter
expert :)


--
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] filter smoothly changeable from LP-BP-HP?

2013-02-10 Thread Johannes Kroll 
On Sun, 10 Feb 2013 03:23:54 -0800
Bram de Jong bram.dej...@gmail.com wrote:

 Hello everyone,
 
 does anyone know of a filter design that can smoothly be changed from
 LP to BP to HP with a parameter? IIRC LP/AP/HP could be done simply by
 perfect reconstruction LP/HP filter pairs, but never seen something
 similar for BP in the middle...
 
 The filter doesn't need to be perfect, it's for something
 musical/creative rather than a purely scientific goal...

This may sound naive, but would it not be possible to chain an LP and a
HP filter in series and adjust their dry/wet rates according to
parameter?

--
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] Starting From The Ground Up

2013-01-21 Thread Johannes Kroll 
On Mon, 21 Jan 2013 13:51:19 +0100
Marc Nostromo [M-.-n] marc.nostr...@gmail.com wrote:

 Note that Juce's licensing is slightly different from that. It is free
 for personal/open-source project. However you are not allowed to
 distribute a closed source Juce-Based app, even if it is free (which
 is verty sad IMHO).

JUCE is GPL. You can use it for open source apps (commercial or
non-commercial) without buying a license.

Only if you want to do closed-source apps (commercial or not) you have
to buy a license. 

Which is a nice business model IMHO. The only problem is: the VST SDK
is incompatible with the GPL, so distributing GPL'd JUCE VSTs is not
legally possible, if I'm correct.

--
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