Guys, Yesterday I have found the REAL reason of my problem.
Of course all the discussion here did in fact help to find other issues. But the reason I was hearing artifacts when modulating was because LFO value was being read from a 2048 size wavetable… I have generated a 441000 size wavetable to allow a 0.1 hertz of minimum frequency and it is working like charm. I still had a crackle and it was being somehow generated by the table normalisation. This is an issue that I still have to investigate. I also need to measure the differences between using interpolation or not (audio quality vs overall performance). Thanks for your help and comments they were really interesting. Regards, Nuno > On 21 Mar 2015, at 11:00, Marco Lo Monaco <marco.lomon...@teletu.it> wrote: > > That's exactly what I would also suggest! > The linear interpolation is used in commercial products more than one could > think. > >> -----Messaggio originale----- >> Da: music-dsp-boun...@music.columbia.edu [mailto:music-dsp- >> boun...@music.columbia.edu] Per conto di Nigel Redmon >> Inviato: sabato 21 marzo 2015 00:07 >> A: A discussion list for music-related DSP >> Oggetto: Re: [music-dsp] Glitch/Alias free modulated delay >> >> Suggestion: >> >> Make it work with linear interpolation first. >> >> The implementation is extremely simple—it won’t take much of your time to >> try it—and you’ll eliminate most of the problems (buffer wrap, etc.) without >> getting confused about whether your interpolation scheme is the fault. >> >> Plus, you’ll have a baseline to compare higher-order improvements with. >> Linear interpolation sounds better than most people would guess, with >> typical musical input (musical interments usually have weaker upper >> harmonics), so you’ll have a better idea of whether you’re getting your >> money’s worth with more elaborate methods. >> >> >> >>> On Mar 20, 2015, at 2:10 PM, Nuno Santos <nunosan...@imaginando.pt> >> wrote: >>> >>> >>>> On 20 Mar 2015, at 18:58, Alan Wolfe <alan.wo...@gmail.com> wrote: >>>> >>>> One thing to watch out for is to make sure you are not looking >>>> backwards AND forwards in time, but only looking BACK in time. >>> >>> This is how I calculate the read index: >>> >>> float t=_writeIndex-_time-_modulation*_modulationRange; >>> >>> if(t<0) >>> t+=_size; >>> >>>> >>>> When you say you have an LFO going from -1 to 1 that makes me think >>>> you might be going FORWARD in the buffer as well as backwards, which >>>> would definitely cause audible problems. >>> >>> I have tried to rescale the LFO to fit between 0 and 1 and it doing the same >> artefacts: >>> >>> >>> // this where delay gets updated with lfo float lfo = >>> (_lfo.step()-1.f)/2.f; >>> >>> delay.setModulation(lfo); >>> >>>> >>>> your LFO really should go between -1 and 0, you then multiply that >>>> value by the number of samples in your buffer (minus 1 if needed, >>>> depending on your design and timing in your code), and then subtract >>>> that value from your "write index" into the buffer, making sure to >>>> handle the case of going negative, where your subtracted offset is >>>> greater than your current write index. >>> >>> I even tried to change from >>> >>> _time+_modulation*_modulationRange >>> >>> to >>> >>> _time-_modulation*_modulationRange >>> >>> Exactly the same issues…. >>> >>> :/ >> >> -- >> 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 > > -- > 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 -- 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
