Tank you Nigel for you advices. The problem of overlapping the minBLEP at higher freqs is not only the increased CPU cost, but the fact that subsequents overlaps do not add to a constant, and at the beginning of the tone generation you will see a staircase function (depending on the period in samples < 32) added with the real requested waveform. With periods >32 samples steps add only when the average signal is zero, whilst with periods lets say 16 samples, starting from silence, you will have a minBLEP reaching ~1.0 value at around 16 samples distance and there another one starting/adding to ~2.0 value for the remaining 16 samples. Hope you got what I mean. That's why I think the solution is to use smaller table size.
Marco PS: yes if you have to upload some videos I would be interested. :) -----Messaggio originale----- Da: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Nigel Redmon Inviato: sabato 18 maggio 2013 03:25 A: A discussion list for music-related DSP Oggetto: Re: [music-dsp] Sweeping tones via alias-free BLIT synthesis and TRI gain adjust formula Thanks for the detailed explanation, Marco. For minBLEPs, I did generate my own tables, though that was lost and I'd have to recreate that but at the moment I'm not in search of a "classic synth waveforms only" solution. (And if I were, I might well go the BLIT route instead.) For periods less than the minBLEP size, I'm pretty sure you need to overlap multiple minBLEPS, making the solution less attractive at higher frequencies Nigel On May 17, 2013, at 2:29 AM, Marco Lo Monaco <marco.lomon...@teletu.it> wrote: > Thank you Nigel. > Well my synth has strict specs, and of course wavetable is a solution. > My mem usage computation was related to have perfectly NO alias for > all midi notes. I well understand that accepting small (inaudible) > alias tables can be shrinked (and I will consider your suggestion > since a diadic approach is of course needed as you go up with frequency). > > The 300 Mb requirement was done considering that the specs are to have > 1 sample rise time at lowest midinote. That means that oversampling > there should use around 5000 pts for full harmonic content to Nyquist. > Then, keeping that resolution as minimum, scaling to Nyquist for all > other frequencies requiring absolutely no foldover, means that we need > 2756 harmonics for midi note 0 and thus 2756 wavetables as harmonics > disappear with increasing midi notes. 2756 (max harms) * (5001 * 4 > floats) 3 > (TRI/SAW/SQR) = 165Mb (maybe I said 300Mb considering 64 bit floats, duh!). > As a starting point I tried that approach on Scilab and I found 2 problems: > 1) the PWL interpolation spectrum is not comparable with BLIT which > has the lowest roundoff noise > 2) how to deal with added/cut harmonic (wavetable switch) without > glitching audio (xfades solutions are likely, meaning that we need > twice read access when pitchbending).. > Yes PWM is usally done via SAW subtraction, and of course I could use > the same tables to make a SQR, at the cost of double memory read > access (a good suggestion though, ;) ) > > If you didnt try BLIT, I think it is the best pure tone solution for > steady signals. No memory usage, simple quadrature oscillator to be > used, few add/mul to generate an aliasfree tone. I think that with > 64bit precision even leakage is not a very big issue. My synth specs > request a lot of voices, crystal quality tones and less memory as possible (ha!). > > I also of tried minBLEP (because I need hardysnc). Very strangely on > Scilab I implemented rceps() with the same functions that the Matlab > help gives, but I get a different shaped minBLEP. Then I used Eli's > original 64x OS > Nz=32 .mat file (imported to Scilab) that I found on the music-dsp > archive by lo...@rpgfan.demon.co.uk and by using it I still get > aliasing on the saw, which hasnt even the time domain shape of a text > book alias free saw (the sinc-like oscillations are only on the > falling front and not at the end of the ramp). So all the expectations > that I had on such method has been deflated quite a bit! :( > > Moreover how to use that minBLEP for periods of less than 32 samples > is still an open question. Maybe just use different minBLEP tables, > but their resolution would be always less in terms of Nz, and I dont > understand cleary how it would affect the aliasing (Eli is not so > clear about it or at least I dont geti it :) ). > > My idea is that I will have to use different techniques depending on > the > contest: BLIT is working very well, the sincM formula is so pretty. I > am also trying to use the SWS method (truncated sinc in an OLA > fashion) to see if frequency modulation can be reliable in the integration stages. > If this fail, I will consider wavetables only for pitchbending and LFO > vibrato, accepting that in those context there could be a bit of > alias. An issue will be how to transit from the BLIT/sincM to wave > tables in a glitchless way. > > Thank you for time > If you want I can post a different email to the NG and talk about > minBLEP, cause I am also really interested in it. > > Have a good day > Marco > > > -----Messaggio originale----- > Da: music-dsp-boun...@music.columbia.edu > [mailto:music-dsp-boun...@music.columbia.edu] Per conto di Nigel > Redmon > Inviato: giovedì 16 maggio 2013 19:09 > A: A discussion list for music-related DSP > Oggetto: Re: [music-dsp] Sweeping tones via alias-free BLIT synthesis > and TRI gain adjust formula > > Hi Marco, > > I don't have experience implementing BLIT; I have done minBLEPit's > been a decade probably, I could comment, but it doesn't seem to be the > focus anyway. > > On wavetables I agree with Robert that your memory guess is a bit inflated: > > First, I'd start with ~20 Hz, not 8 Hz, for full bandwidth. If you > really need 8 Hz and lower with every harmonic, you can easily > special-case the lower wavetablefor instance, in the case of a > sawtooth, a naive sawtooth will not have any noticeable aliasing down > there. If you make the lowest table 20 Hz, you can run it down to your > 8 Hz, of course, at the loss of the top octave+ of harmonics (most of > which you can't hear). And don't forget that in almost any musical > use, the waveform either won't have significant energy up there, or > you'll have a lowpass filter on it that gets rid of the energy up there. > > So, 1x sampling is plenty in the lowest (longest wavetable > requirement) octave. That means a table size of 2048 samples, 8k of memory with floats. > Eleven wavetable cover audio range, so with constant table size, 88k > of memory. Now, it's not at all difficult to cut your memory by a > large factor by using wavetable lengths more critically sampled > (second table 1024, etc., although I'd add a little back by making the > top tables oversampled). So, something like a factor of four22k for > the set instead of 88k. Also, you can cut either method (variable or > fixed table sizes) in half if you decide > 40 Hz is low enough and you can give up a little in the bottom octave > (again, you won't hear it on most things, because you'll either use a > wave with little energy up there, or a lowpass filter). > > Still, if it's running on a host computer, memory is cheap. Even the > 88k per table is no big deal, but you can drop that to a fourth or > eighth if you want. > > For a square/rectangle wave, just use two phases of sawno new wavetables. > > For sine, you already have it in the top octave of the sawor any > other waveformno new table. > > For triangle, the harmonics drop off quickly (inverse square) that you > don't need as many tables, if you want to optimize; it would be a > bigger savings with variable tables (about half, just by losing the lowest wavetable). > > For arbitrary waveforms, you build only as many tables in a set as the > harmonic content requires. It's easy enough to have your > table-generation algorithm be smart about the strength of upper harmonics too, to optimize. > > And of course, even if you support 1000 wave types, it's unlikely > you'll have more than a few loaded into memory at one time. > > Check out my tutorial, with code (start for the bottom up): > > http://www.earlevel.com/main/category/digital-audio/oscillators/waveta > ble-os > cillators/ > > I'm trying to finish a short video with examples, to upload soon. > > Nigel > > > > On May 16, 2013, at 9:05 AM, Marco Lo Monaco > <marco.lomon...@teletu.it> > wrote: > >> Hi guys, here is a repost of a conversation between me and RBJ under >> his permission, since he couldnt send to the NG via plain text from >> his > browser. >> Pls if some of you guys have some suggestion, it would be very much >> appreciated. >> Marco >> >> ---------------------------- Original Message >> ---------------------------- >> Subject: [music-dsp] Sweeping tones via alias-free BLIT synthesis and >> TRI gain adjust formula >> From: "Marco Lo Monaco" <marco.lomon...@teletu.it> >> Date: Tue, May 14, 2013 6:34 am >> To: music-dsp@music.columbia.edu >> --------------------------------------------------------------------- >> - >> ---- >>>> I am here asking what is the best practice to deal with frequency >> modulation via BLIT generation. >> >> hi Marco, >> >> i've fiddled with BLIT longer ago. as i recall i generated a string >> of >> sinc() functions instead of a string of impulses and i integrated >> them along with a little DC bias to get a saw. for squareit were two >> little BLITs, alternating in sign, per cycle, and integrated. and >> triangle was an integrated square. i found generating the BLITs to be >> difficult, i eventually just used wavetables for the BLITs at >> different ranges. and then i thought why not just use wavetable to > generate the waveforms directly. >> i know with the sawtooth, the bias going into the integrator had to >> change as the pitch changes. i dunno what to do about leftover >> "charge" left in the integrator other than maybe make the integrator >> a little bit leaky. so that is my only suggestion, if you have the >> rest of the BLIT already licked. >> >> the net advice i can give you is to consider some other method than >> BLIT (like wavetable) and if you're using BLIT with a digital >> integrator, you might have to make the integrator a little "leaky" so >> that an DC component inside can "leak" out. >> >> bestest, >> >> r b-j >> >> ---------------------------- Original Message >> ---------------------------- >> Subject: R: [music-dsp] Sweeping tones via alias-free BLIT synthesis >> and TRI gain adjust formula >> From: "Marco Lo Monaco" <marco.lomon...@teletu.it> >> Date: Wed, May 15, 2013 4:46 am >> To: r...@audioimagination.com >> --------------------------------------------------------------------- >> - >> ---- >> >> Hi Robert, >> I tried with leaky: the thing is that it seems you need to compensate >> for amplitudes if you are using a fixed cutoff leaky integrator (if >> you filter a 12kHz blit, its amplitude with an LPF 5Hz will be much >> lower than a 100Hz blit and compensating the amplitude could generate >> roundoff noise at high freqs). As a hack one could use a varying >> cutoff depending on the f0 tone to be synthesized, but that could >> have problem again in sweeping tones (an LPF changing cutoff at audio >> rate is not generally artifact free). In both cases transient and not >> steady textbook waveforms are the result, which could be a problem if >> there is a distortion stage following (like a moog ladder with its >> non > linearities). >> >> I tried also with wavetables, and the clean solution is a memory >> eager, starting to midi note 0 (8Hz) you need thousands of harmonics >> until Nyquist, with PWL interpolation with at list 2001pts you can >> easily reach 300 MB for SQR/TRI/SAW!!! Probably a tradeoff and >> accepting aliasing a bit is the only solution. The open problem there >> is the click (also happening with sincM) that you get when you simply > add/cut an harmonic in a sweeping context. >> Maybe the SWS BLIT method is the only solution to avoid this and I >> must investigate. >> >> I also tried HardSync ala Eli Brandt and its consequent method of >> generating aliasfree waveforms, but I get too much aliasing with his >> implementation for minBLEP and with a 32 zerocrossing impulse seems >> that you cant treat waveforms that has a lower 32 samples period >> (because the OLA method would add up creating subsequent DC steps). >> >> I thought it was much simpler to do an alias free synth, honestly!!! >> >> Thank you for time >> >> Marco >> >> ---------------------------- Original Message >> ---------------------------- >> From: r...@audioimagination.com [mailto:r...@audioimagination.com] >> Date: mercoledì 15 maggio 2013 17:08 >> To: Marco Lo Monaco >> Subject: Re: [music-dsp] Sweeping tones via alias-free BLIT synthesis >> and TRI gain adjust formula >> --------------------------------------------------------------------- >> - >> ---- >> >> i don't quite see the memory issues of wavetable as bad as you do, >> with back-of-envelope calculation. how many ranges do you need? >> maybe 2 per octave? there are 10 octaves of MIDI notes. maybe 4K >> per wavetable (unless you do some tricky stuff so that the high-pitch >> wavetables may have fewer >> points) so that's 80K for a single waveform going up and down the >> whole MIDI range. HardSync will have a large collection of waveforms >> given the different values of oscillator ratios (the main mod control >> for > hardsync). >> is it hardsync saw or hardsync square? >> >> i gotta reacquaint myself with Eli Brandt's hardsync. i don't know it. >> >> L8r, >> >> r b-j >> >> >> -- >> 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 -- 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
