Re: [music-dsp] Musicdsp.org finally updated

2019-02-26 Thread Spencer Jackson
that's really great. Thank you!

On Tue, Feb 26, 2019 at 12:09 PM Michael Gogins 
wrote:

> Thanks for doing this.
>
> Mike
>
> On Wed, Feb 27, 2019, 04:40 Robert Marsanyi  wrote:
>
>> That’s a phenomenal resource.  Thanks, Bram.
>>
>> --rbt
>>
>> On Feb 26, 2019, at 7:16 AM, Jacob Penn  wrote:
>>
>> Amazing!
>>
>> [image: insignia] 
>> JACOB PENN.MUMUKSHU
>> 612.388.5992
>>
>> On February 26, 2019 at 6:59:24 AM, Bram de Jong (bram.dej...@gmail.com)
>> wrote:
>>
>> Hi all,
>>
>> New and improved: https://www.musicdsp.org/en/latest/
>>
>> I'm still in the process of going through all the comments, cleaning it
>> all up. But... if you want to add or change anything:
>> https://github.com/bdejong/musicdsp
>>
>> grts,
>>
>> Bram
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

2018-10-03 Thread Spencer Jackson
I have only used libraries for resampling myself. I haven't looked at their
source, but it's available. The two libraries I'm aware of are at
http://www.mega-nerd.com/SRC/download.html
and
https://kokkinizita.linuxaudio.org/linuxaudio/zita-resampler/resampler.html

perhaps they can give you some insight.

On Wed, Oct 3, 2018 at 2:46 PM Alex Dashevski  wrote:

> I wrote on android ndk and there is fastpath concept. Thus, I think that
> resampling can help me.
> Can you recommend me code example ?
> Can you give me an example of resampling ? for example from 48Khz to 8Khz
> and 8Khz to 48Khz.
> I found this:
> https://dspguru.com/dsp/faqs/multirate/resampling/
> but it is not enough clear for me,
>
> Thanks,
> Alex
>
>
> ‫בתאריך יום ד׳, 3 באוק׳ 2018 ב-20:56 מאת ‪Spencer Jackson‬‏ <‪
> ssjackso...@gmail.com‬‏>:‬
>
>>
>>
>> On Wed, Oct 3, 2018 at 3:17 AM Alex Dashevski  wrote:
>>
>>>
>>> if I do resampling before and after processing. for example, 48Khz ->
>>> 8Khz and then 8Khz -> 48Khz then will it help ?
>>>
>>
>> Lowering sample rate can help achieve lower latencies by giving you fewer
>> samples to process in the same amount of time but just downsampling and
>> then upsampling back doesn't really have any effect.
>>
>>
>>
>>> I don't understand why I need filter, This is to prevent alias but I
>>> can't understand why ?
>>>
>>> Technically you only need a filter if your signal has information above
>> the nyquist frequency of the lowest rate but this is not usually the case.
>> I think wikipedia explains aliasing pretty well:
>> https://en.wikipedia.org/wiki/Aliasing#Sampling_sinusoidal_functions .
>> Once the high frequency information aliases it cannot be recovered by
>> resampling back to the higher rate and your lower band information is now
>> mixed in with the aliased information. The filter removes this high
>> freqency data so that the low band stays clean through the whole process.
>>
>>
>> Is there option to decrease latency or delay ?
>>>
>>
>> The only way to reduce latency in your algorithm (unless there is some
>> error in the implementation) is to reduce the block size, so you process
>> 128 samples rather than 240. 240 isn't a very large amount of latency for a
>> pitch shifter which is typically a CPU intensive process and therefore most
>> implementations have relatively high latencies.
>>
>> I'm not sure I understand what you mean by the pitch duration requiring a
>> buffer-resize or sample-rate decrease. WSOLA creates a signal with more
>> samples than the input, you must resample that (usually by a non-integer
>> amount) to make it the correct number of samples then output that, and
>> reload your buffer with the next block of input data. Please clarify if you
>> mean some other issue.
>>
>> _Spencer
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Resampling

2018-10-03 Thread Spencer Jackson
On Wed, Oct 3, 2018 at 3:17 AM Alex Dashevski  wrote:

>
> if I do resampling before and after processing. for example, 48Khz -> 8Khz
> and then 8Khz -> 48Khz then will it help ?
>

Lowering sample rate can help achieve lower latencies by giving you fewer
samples to process in the same amount of time but just downsampling and
then upsampling back doesn't really have any effect.



> I don't understand why I need filter, This is to prevent alias but I can't
> understand why ?
>
> Technically you only need a filter if your signal has information above
the nyquist frequency of the lowest rate but this is not usually the case.
I think wikipedia explains aliasing pretty well:
https://en.wikipedia.org/wiki/Aliasing#Sampling_sinusoidal_functions . Once
the high frequency information aliases it cannot be recovered by resampling
back to the higher rate and your lower band information is now mixed in
with the aliased information. The filter removes this high freqency data so
that the low band stays clean through the whole process.


Is there option to decrease latency or delay ?
>

The only way to reduce latency in your algorithm (unless there is some
error in the implementation) is to reduce the block size, so you process
128 samples rather than 240. 240 isn't a very large amount of latency for a
pitch shifter which is typically a CPU intensive process and therefore most
implementations have relatively high latencies.

I'm not sure I understand what you mean by the pitch duration requiring a
buffer-resize or sample-rate decrease. WSOLA creates a signal with more
samples than the input, you must resample that (usually by a non-integer
amount) to make it the correct number of samples then output that, and
reload your buffer with the next block of input data. Please clarify if you
mean some other issue.

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

Re: [music-dsp] WSOLA on RealTime

2018-09-27 Thread Spencer Jackson
Alex:

Any algorithm with a deterministic computation time can be applied in
real-time if latency is sufficient enough. Are you familiar with the idea
of copying the stream to a buffer then applying the algorithm and
outputting the older data which the algorithm has already been applied to?
Adding latency like this and processing in blocks is the standard method
that allows very cpu heavy processing to be applied to a real-time stream.
The only real requirement for real-time processes is to output the same
number of samples as the input (at the same sample rate).

Pitch shifting methods stretch or shrink the signal creating more or less
samples and you must figure out how to remove the extra or add samples to
be the correct number of samples in order for it to work on a real-time
audio stream. This is the resampling part and there are many ways to
address it.

I think we might be able to help more if you can ask more specific
questions about the implementation details you are struggling with.

_Spencer

On Thu, Sep 27, 2018 at 12:16 AM Alex Dashevski  wrote:

> Hi Robert,
>
> I don't understand your last sentence:
> "then, in real-time, you can use the time
> scaler  make the more or fewer samples per block to be the same as normal."
>
> In the beginning of your answer, you said that I need to use WSOLA with
> resampling.
>
> I have problem with implementation. Can you help ?
>
> Thanks,
> Alex
>
> 2018-09-27 0:25 GMT+03:00 Jacob Penn :
>
>> Ahh yeah I gotcha,
>>
>> Yes, in the case of slow down, there Is a finite amount you’re able to
>> slow down based on the size of the circular buffer of input data in use.
>>
>> In my personal applications I offer users the ability to restart the
>> stretch from the writehead at a musical value. Conveniently the slowest
>> rate for this control will stop the overflow ; )
>>
>> Can sound quite nice!
>>
>> Best,
>>
>> [image: insignia] 
>> JACOB PENN.MUMUKSHU
>> 612.388.5992
>>
>> On September 26, 2018 at 2:21:29 PM, robert bristow-johnson (
>> r...@audioimagination.com) wrote:
>>
>>
>>
>>  Original Message 
>> Subject: Re: [music-dsp] WSOLA on RealTime
>> From: "Jacob Penn" 
>> Date: Wed, September 26, 2018 5:00 pm
>> To: r...@audioimagination.com
>> music-dsp@music.columbia.edu
>> --
>>
>> > You can indeed do it on real time audio but the tricks is like the
>> previous
>> > email, you’ll need to devise strategies for pitching things up, as
>> you’ll
>> > be lacking the necessary information to move faster across the buffer
>> from
>> > the write head position.
>> >
>> > You’ll also obviously only be able to slow down a signal, and not speed
>> it
>> > up.
>>
>> no, even if you slow it down, any finite-sized buffer will eventually
>> overflow.  i presume you mean time-scaling (not pitch shifting) using WSOLA.
>>
>> by "real-time", i mean live samples going in and (assuming no sample rate
>> conversion) the same number of samples going out in a given period of
>> time.  with an upper bound of delay (and the lower bound is imposed by
>> causality) and the process can run indefinitely.  so if you're slowing down
>> audio in real-time and you're running this process for a day.  or for a
>> year.
>>
>>
>> --
>>
>> r b-j r...@audioimagination.com
>>
>> "Imagination is more important than knowledge."
>>
>>
>>
>>
>>
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] What is resonance?

2018-07-20 Thread Spencer Jackson
Resonance is the characteristic of some systems to store and release energy
at particular frequencies. It's not limited to filters, mechanical systems
like springs or pendulums have resonance (get on a swing at the park and
try to change your frequency and you'll feel the effects of resonance).

In an electrical system, a minimal passive resonant circuit would be one
with 2 capacitors and 2 resistors. Selecting the values of the components
determines the frequency, but what happens is that at a certain frequency
the energy gets stored and passed back and forth between the capacitors,
like the swing going back and forth. This storage and energy swapping
emphasizes that frequency. Depending on the "Quality factor" or amount of
resonance that frequency can become much more apparent than the other
frequencies in the signal even if the input is wide-band.

When you are talking about delay and feedback, you are creating a digital
filter, but I think it is worthwhile to spend some time understanding the
theoretical concept and think in terms of energy and frequency. Your
feedback delay becomes the storage and certain frequencies will resonate
with that system.

> But it is having the resonance in parralel to a dry sound that bothers
me; but may be that's the only way to do ?

I'm not sure what you mean but I think you need some study in filter
design, because a single feedback delay causes comb filtering but its not a
classical lowpass. Is that what you are trying to achieve? Digital filters
are almost universally combinations of short delays (typically 1 sample)
placed in different patterns and fed back in different amounts (e.g.
https://en.wikipedia.org/wiki/Digital_filter#Filter_realization).

Here are some resources that may help you:
http://www.dspguide.com/ch14.htm
https://www.native-instruments.com/fileadmin/ni_media/downloads/pdf/VAFilterDesign_2.0.0a.pdf

That first one is a book that can help you more with the fundamentals in
the early chapters as well. I hope this is somewhat helpful, if not perhaps
I need to understand better specifically what you are trying to achieve.
_Spencer


On Fri, Jul 20, 2018 at 10:13 AM, Mehdi Touzani 
wrote:

> Hi all,
> I follow the llist for a while, but I am not a DSP programmer, I do DSP
> audio apps for about 20 years now, for sonic core plateform "Scope" and
> Xite".   I begin with other things like juce or flowstone, but so far,
> scope is still far superior in terms of sound results. Too bad there is no
> scripting tool for it (well there is but it is not available to me).
>
> My question is probably weird for you  - like super noob - , because i am
> NOT looking for math or codes, but hints about a general
> design/architecture.
>
> So... how do you do a resonance in a lowpass circuit?   :-)   not the
> math, not the code, just the architecture.
>
> Personnally,  i came to the conslusion that  some kind of very short delay
> with feedback, mixed in parallel with the non resonance low pass sound,
> could do the trick. . The more feedback, the more resonance, and with
> feedback over -6dB, it would begin to self resonate.
>
> But it is having the resonance in parralel to a dry sound that bothers me;
> but may be that's the only way to do ?
>
> I have read about hardware filters and ok, there is math, but there is
> also the effect of the hardware components. Some articles even suggest that
> a bandpass in parralel could do the trick : or more exactly, a bandpass
> fonction is created after the resonance, to remove frequencies that would
> overlap with the cutoff.
>
>
> So, any hints that could help me improve the process etc would be very
> welcome.
>
> Thanks
>
> Mehdi
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Music software interface design

2017-04-18 Thread Spencer Jackson
I certainly found it interesting. Thanks for sharing!

I find it interesting though that (aside from the limiter threshold in the
first example) you are moving from a parametric interface to an empirical
one. It seems to me to be used more powerfully in realtime or with
automation, in a live situation or a DAW the effect will need some
parametric editing capabilities. The idea is certainly a departure from the
status quo and offers some great features of simplicity to describe some
arbitrary envelopes or delays (I especially like the idea of the delay),
but I couldn't help but think of my workflow and whether I could use such
things. Perhaps the modern DAW workflow is not the best way to do it, but
it did seem like none of the interfaces suggested fit very smoothly into
it.

Parametric designs came out of the circuit designs that placed a
potentiometer to change the cutoff of this analog filter, or the frequency
of an oscillator, but IMO they have held strong because of the
tweakability. There is a steeper learning curve for sure, but you typically
know exactly how the envelope will change as you move each knob of an ADSR.

I love the work and find this topic very interesting so I hope you continue
the work and continue to publish what you are finding and experimenting
with. If you are shopping around for next step ideas I would consider
trying to adapt the interface in a way that allows musical, realtime,
on-line, tweaking. Perhaps a second envelope could be sung and then blend
between the two, like an envelope-wavetable, or perhaps a few knobs with
parameters like stretch and skew. There are lots of possibilities. Or I
could just be wrong and you'll show me some totally different way to do it!

Just some thoughts...
_Spencer


On Fri, Apr 14, 2017 at 9:48 AM, Arthur Carabott  wrote:

> Hello all,
>
> I've been doing some work on re-designing the interactions / interfaces
> for music software. The focus isn't on the DSP, more on how we can better
> interact with it. That said, there are some engineering implications
> (particularly with the first prototype).
>
> Hope you enjoy! http://arthurcarabott.com/mui/
>
> If the work interests you feel free to mail me off list as well.
>
> Best,
>
> Arthur
>
> www.arthurcarabott.com
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Help with "Sound Retainer"/Sostenuto Effect

2016-09-16 Thread Spencer Jackson
Wow, thanks all for the replies!

If I used a reverb would it end up giving the sustained voice too much
character? I was thinking of taking freeverb and removing the comb
filters and just using the allpass filters with 100% feedback thinking
it would make it a "cleaner" sustain. I'm leaning this way because I'd
like to keep it lightweight and I think this will be less overhead
than a phase vocoder. Is that a naive approach?

Thanks again,
_Spencer



On Fri, Sep 16, 2016 at 1:59 PM, Emanuel Landeholm
 wrote:
> Simple OLA will produce warbles. I recommend a phase vocoder.
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp



Re: [music-dsp] Help with "Sound Retainer"/Sostenuto Effect

2016-09-16 Thread Spencer Jackson
On Fri, Sep 16, 2016 at 11:24 AM, gm  wrote:
> Did you consider a reverb or an FFT time stretch algorithm?
>

I haven't looked into an FFT algorithm. I'll have to read up on that,
but what do you mean with reverb? Would you feed the loop into a
reverb or apply some reverberant filter before looping?

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



[music-dsp] Help with "Sound Retainer"/Sostenuto Effect

2016-09-16 Thread Spencer Jackson
Hi all:

First post on the list. Quite some time ago I set out to create a lv2
plugin re-creation of the electroharmonix freeze guitar effect. The
idea is that when you click the button it takes a short sample and
loops it for a drone like effect, sort of a granular synthesis
sustainer thing. (e.g. https://youtu.be/bPeeJrv9wb0?t=58)

I use an autocorrelation-like function to identify the wave period but
on looping I always have artifacts rather than a smooth sound like the
original I'm trying to emulate. I've tried some compression to get a
constant rms through the sample, tried various forms of crossfading,
tried layering several periods, and many combinations of these. I
ended up releasing it using 2 layers, compression, and a 64 sample
linear crossfade, but I've never been satisfied with the results and
have been trying more combinations. It works well on simple signals
but on something not perfectly periodic like a guitar chord it always
has the rhythmic noise of a poor loop.

I'm hoping either someone can help me find a bug in the code that's
spoiling the effect or a better approach. I've considered applying
subsample loop lengths, but I don't think that will help. The next
thing I could think of is taking the loop into the frequency domain
and removing all phase data so that it becomes a pure even function
which should loop nicely and still contain the same frequencies. I
thought I'd ask here for suggestions though, before spending too much
more time on it.

The GPL C code is here for review if anyone is curious:
https://github.com/ssj71/infamousPlugins/blob/master/src/stuck/stuck.c
I'm happy to offer more explanations of the code.

Thanks for your time.
_Spencer
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp