From: Stefan F. <st...@sf...> - 2010-08-29 17:40:43
Attachments:
TrippleOSC_vs_TrippleOSC.ogg
|
Hi, as a weekend-projekt I tweaked the osciallator-code of lmms a little bit... (implementing bandlimited wavetable oscillators ("BWOs")). Code is currently too limited and too rough to make it public (and it takes some seconds for first instance of the oscillator-code to come up)... but maybe you might listen to some results... first is lmms' current generators and second part is the same plugin but with BWOs ... (both is Tripple-Oscillator-Plugin in lmms)... The second part sounds the same ... but it is missing something (very big grin...)... CPU-Load is approximately the same... comments welcome! (Maybe someone getting me to polish it for a public release?) :D cu Stefan |
From: Kevin F. <kev...@ei...> - 2010-08-29 18:39:44
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-15" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 08/29/2010 01:39 PM, Stefan Fendt wrote <blockquote cite="mid:4C7...@sf..." type="cite"> <pre wrap="">first is lmms' current generators and second part is the same plugin but with BWOs ... (both is Tripple-Oscillator-Plugin in lmms)... The second part sounds the same ... but it is missing something (very big grin...)... CPU-Load is approximately the same... </pre> <br> </blockquote> The second half definitely sounds clearer with less pops/clicks. I'd say the result is good, even if the code may need a tune-up.<br> <br> <div class="moz-signature">-- <br> <table style="text-align: left; width: 200px; font-family: sans-serif;" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td><span style="font-weight: bold;">Kevin Fishburne</span><br> </td> </tr> </tbody> </table> <table style="text-align: left; width: 200px; font-family: sans-serif;" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td>Eight Virtues<br> </td> </tr> </tbody> </table> <table style="text-align: left; width: 200px; font-family: sans-serif;" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td><font size="-1">www:<br> e-mail:<br> phone:</font></td> <td><font size="-1"> <a href="http://www.eightvirtues.com">http://www.eightvirtues.com</a><br> <a href="mailto:sa...@ei...">sa...@ei...</a><br> (770) 853-6271</font></td> </tr> </tbody> </table> </div> </body> </html> |
From: Tobias D. <tob...@gm...> - 2010-08-29 21:54:28
|
Hi, Am Sonntag, 29. August 2010, um 19:39:48 schrieb Stefan Fendt: > as a weekend-projekt I tweaked the osciallator-code of lmms a little > bit... (implementing bandlimited wavetable oscillators ("BWOs")). Code > is currently too limited and too rough to make it public (and it takes > some seconds for first instance of the oscillator-code to come up)... How much additional RAM does it take? > but maybe you might listen to some results... Stunning differences which make me interested in your patch ;-) > first is lmms' current generators and second part is the same plugin but > with BWOs ... (both is Tripple-Oscillator-Plugin in lmms)... The second > part sounds the same ... but it is missing something (very big > grin...)... CPU-Load is approximately the same... Is it wavetable-based? If so, why is the load still the same? > comments welcome! (Maybe someone getting me to polish it for a public > release?) What I'd like to see to make it dynamically configurable so the "bandlimited oscillators" option in the export project dialog actually has a function. The user can still choose which generator to use - maybe even in live mode via a new switch in TripleOsc UI. Toby |
From: Stefan F. <st...@sf...> - 2010-08-30 11:13:03
|
Hi all, > How much additional RAM does it take? hmm,... got me... ;-) ;-) no, seriously... in it's current incarnation it eats up a lot additional RAM (but not that much, that I would say it's too much for a current machine...) Let me see: 6 Waveforms * 1024 Samples * 128 Steps * sizeof(float) = 3MiB That's not too much I guess, given the fact that even a smaller GUI-decoration could easily eat up more than that. However this calculation is valid for 44.1kHz. For allowing up to 96kHz (and higher) and the best possible tonal quality (I'm still tweaking these steppings inside the wavetable) I guess it will be twice or three times this value... > Stunning differences which make me interested in your patch ;-) > :) Thanks a lot! > Is it wavetable-based? If so, why is the load still the same? Yes, it is wavetable-based. "Roughly" it's the same load... I have not measured it in detail, yet. But, on the one hand side a table-lookup is just a little bit faster than a FPU-sinf(x) and on the other hand side it needs (at least) linear interpolation (between samples and steps)... Currently it seem's like it wages out each other... Maybe the wavetable-code is a little bit slower. But even then I would think it's worth it... (Despite that: the previous audio-sample only did linear interpotation between the wavetable-steps, so very little but measurable time-alias-noise was present. OK, this isn't as anoing as frequency-aliasing but... ;-)) > What I'd like to see to make it dynamically configurable so the > "bandlimited > oscillators" option in the export project dialog actually has a function. The > user can still choose which generator to use - maybe even in live mode via a > new switch in TripleOsc UI. > Well, currently I'm strictly aiming towards the live-mode. That's because of the many difficulties which arise with real high sample-rates, making the output not sounding better but very different from the live-"preview"-mode... That would allow to really have a "What you hear is what you get when rendering it"-System. If everything works like I want it — I suppose there will be no need of that switch between generators any more... all the best, Stefan |
From: Stefan F. <st...@sf...> - 2010-08-30 17:54:27
|
Am 30.08.2010 13:12, schrieb Stefan Fendt: > Yes, it is wavetable-based. "Roughly" it's the same load... I have not > measured it in detail, yet. > Ok, so now I have made (with the rough code) a measurement of how many oscillators I can run in parallel without getting hic-ups in the audio-output when moving some windows arround... BWOs: 162 simultanous generators legacy: 165 simultanous generators This tested on my older and slower dual-core (so I do not have to test even more generators --> hurts in the ears... ;-)): vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Pentium(R) Dual-Core CPU E5400 @ 2.70GHz stepping : 10 cpu MHz : 1203.000 cache size : 2048 KB ... cu Stefan PS: not an exact test... but... |
From: Stefan F. <st...@sf...> - 2010-08-30 20:58:07
|
Am 30.08.2010 13:12, schrieb Stefan Fendt: > Hi all, > > >> How much additional RAM does it take? >> How much additional RAM would be tolerable? I personally would even tolerate something like this: 6 Waveforms * 8192 Samples * 512 Steps * sizeof(float) = 96,0 MiB for the wavetable... which (after analysing some spectra) is only very little better (SNR wise) but nearly(? I can't hear a difference...) indistinguishable to this: 6 * 2048 * 256 * 4 = 12,0 MiB (sounds very good on 44.1, 88.2, 96 and 192 kHz) but even the 3MB version sounds good with 44.1 and OK with 88 or 96kHz but in the low bass end it misses something at 192kHz... So,... I personally would opt for the 12MB variant... (which btw could be perfectly precomputed, so it doesn't slow down the initialization of the first oscillator instance -- on a long run... currently I can live with that... ;-) until I have an otherwise (near) perfect scenario...) cu Stefan |
From: Nikos C. <re...@ar...> - 2010-08-30 03:27:04
|
On 08/29/2010 08:39 PM, Stefan Fendt wrote: > Hi, > > as a weekend-projekt I tweaked the osciallator-code of lmms a little > bit... (implementing bandlimited wavetable oscillators ("BWOs")). Code > is currently too limited and too rough to make it public (and it takes > some seconds for first instance of the oscillator-code to come up)... > but maybe you might listen to some results... > > first is lmms' current generators and second part is the same plugin but > with BWOs ... (both is Tripple-Oscillator-Plugin in lmms)... The second > part sounds the same ... but it is missing something (very big > grin...)... CPU-Load is approximately the same... No aliasing effects at all in the second part! This is quite awesome. |
From: Stefan F. <st...@sf...> - 2010-09-11 09:07:36
Attachments:
oversampled-oscillators.diff
|
Ok, here we go... This patch changes the oscillators in such a way that they can be oversampled up to 16x now. The only plugin currently using this feature is Tripple-Oscillator (in which for the time being an oversampling-factor of 8 is hardcoded currently). On my machine (slow Intel dual-core) I still can play 32+ Instances of Tripple-Oscillator with this patch applied, so it's not too slow anyways... But on the long run there could be a knob reflecting the oversampling-setting for a particular instance of a plugin, so you do not waste CPU-time with oversampling bass-sounds... The main benefit from this approach compared to my last attemt (using wavetables for alias-free waveform-generation) is, that it works with the higher-order modulations (AM, FM, Sync, PM). The main drawback is, that it isn't halfway that fast and while alias is suppressed reasonably it's not completely alias-free... But as said above: this shouldn't be a problem, as you only would use this feature adaptively for higher-pitched (and/or modulated) lead voices anyways... Please test and comment... Stefan |
From: Stefan F. <st...@sf...> - 2010-09-11 09:12:18
|
Whoops... the diff contains new (and from my point of view "better" ) filter-code for the RC-Filters,also... This was not(!) intended... ;-) The filter-code still is not ready for the human being... ;-) So "ignore" that part of the patch... sorry for that, Stefan |
From: Janne S. <jan...@gm...> - 2010-09-11 22:25:38
|
What version is this for? On my system LMMS (0.4.90) just crashes when I try to play TripleOsc. Compiled without optimizations. 2010/9/11 Stefan Fendt <st...@sf...>: > Ok, here we go... > > This patch changes the oscillators in such a way that they can be > oversampled up to 16x now. The only plugin currently using this feature > is Tripple-Oscillator (in which for the time being an > oversampling-factor of 8 is hardcoded currently). On my machine (slow > Intel dual-core) I still can play 32+ Instances of Tripple-Oscillator > with this patch applied, so it's not too slow anyways... But on the long > run there could be a knob reflecting the oversampling-setting for a > particular instance of a plugin, so you do not waste CPU-time with > oversampling bass-sounds... > > The main benefit from this approach compared to my last attemt (using > wavetables for alias-free waveform-generation) is, that it works with > the higher-order modulations (AM, FM, Sync, PM). The main drawback is, > that it isn't halfway that fast and while alias is suppressed reasonably > it's not completely alias-free... > > But as said above: this shouldn't be a problem, as you only would use > this feature adaptively for higher-pitched (and/or modulated) lead > voices anyways... > > Please test and comment... > > Stefan > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > > |
From: Janne S. <jan...@gm...> - 2010-09-11 22:28:02
|
Ehm...*latest* 0.4.90 2010/9/12 Janne Sinisalo <jan...@gm...>: > What version is this for? On my system LMMS (0.4.90) just crashes when > I try to play TripleOsc. Compiled without optimizations. > > 2010/9/11 Stefan Fendt <st...@sf...>: >> Ok, here we go... >> >> This patch changes the oscillators in such a way that they can be >> oversampled up to 16x now. The only plugin currently using this feature >> is Tripple-Oscillator (in which for the time being an >> oversampling-factor of 8 is hardcoded currently). On my machine (slow >> Intel dual-core) I still can play 32+ Instances of Tripple-Oscillator >> with this patch applied, so it's not too slow anyways... But on the long >> run there could be a knob reflecting the oversampling-setting for a >> particular instance of a plugin, so you do not waste CPU-time with >> oversampling bass-sounds... >> >> The main benefit from this approach compared to my last attemt (using >> wavetables for alias-free waveform-generation) is, that it works with >> the higher-order modulations (AM, FM, Sync, PM). The main drawback is, >> that it isn't halfway that fast and while alias is suppressed reasonably >> it's not completely alias-free... >> >> But as said above: this shouldn't be a problem, as you only would use >> this feature adaptively for higher-pitched (and/or modulated) lead >> voices anyways... >> >> Please test and comment... >> >> Stefan >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing >> http://p.sf.net/sfu/novell-sfdev2dev >> >> _______________________________________________ >> LMMS-devel mailing list >> LMM...@li... >> https://lists.sourceforge.net/lists/listinfo/lmms-devel >> >> > |
From: Stefan F. <st...@sf...> - 2010-09-13 22:10:17
|
The patch I sent contains a bug. The fir_length is computed wrong (and not clipped to the maximum size allowed by the sinc-tables). This leads to a spurious segfault (on my system this happens nearly always if autosave is triggered). I will fix this and allow for an even greater oversampling-range (which for the higher factors of course is not usable in realtime-application of lmms but will be for rendering out things...) sorry for the mess, Stefan PS: if I can, I will also optimize this a little bit (it mainly has the status of a working(? erm...) "proof-of-concept". Next patch will be without the mysterious filter-stuff, too btw, as this is not ready anyways... PPS: Toby, I really would appreciate if you could find some time to comment on this. From my point of view this approach makes more sense then any of the previous attempts in reducing the aliasing inside lmms (including the oversampling already available via rendering-out), as it inherently avoids numerical problems with extraordinary high sampling-rates in the (ladspa) plugins as these usually do not assume one could be so "insane" of driving them with multi-megaherz samplerates... PPPS: If you experienced spurious crashes and want a quick-fix: limit the variable "fir_length" in Oscillator.cpp to 128 on both places... |
From: Stefan F. <st...@sf...> - 2010-09-10 20:45:18
Attachments:
TrippleOSC_vs_TrippleOSC.ogg
|
Hello again from the oscillator-front... ok,... the last approach sounded very good... but... I was not able to get it performing the higher order modulations used in tripple-osc in real-time (Sync and AM/FM) ... Only basic waveforms were possible. While this was not too bad, I personally wanted to get these modulations working without alias, too... So, here is my second attempt using generator-based oversampling: 1. not wavetable-based any more (less memory consumption) 2. "just" oversamples the "naive" waveform-generators used by Tripple-Osc with a sinc-filter. 3. can be done up to 32 times oversampling (if the machine can do it — my can do this for at least 20 voices)... 4. Benefit: can be done individually for each Tripple-Osc-Instance (so if you don't need this because you synthesize a bass-waveform... you don't need to turn this on. So it does not waste CPU-cycles if it's not needed... allowing for the "old" behavior mixed with the new one...) 5. Drawback: if the plugin doesn't know it can use oversampling,... it doesn't use it... 6. Still some bugs preventing me from releasing this ... but I might get these out on weekend... ;-) While I can measure that there is some (minor) alias left... I can't hear the difference to the last approach... cu Stefan |
From: Paul G. <dr...@gm...> - 2010-09-14 12:24:02
|
I like where this is headed. Keep up the good work! On Sep 14, 2010 4:20 AM, "Stefan Fendt" <st...@sf...> wrote: > Hello again from the oscillator-front... > > ok,... the last approach sounded very good... but... I was not able to > get it performing the higher order modulations used in tripple-osc in > real-time (Sync and AM/FM) ... Only basic waveforms were possible. While > this was not too bad, I personally wanted to get these modulations > working without alias, too... So, here is my second attempt using > generator-based oversampling: > > 1. not wavetable-based any more (less memory consumption) > 2. "just" oversamples the "naive" waveform-generators used by > Tripple-Osc with a sinc-filter. > 3. can be done up to 32 times oversampling (if the machine can do it > — my can do this for at least 20 voices)... > 4. Benefit: can be done individually for each Tripple-Osc-Instance > (so if you don't need this because you synthesize a > bass-waveform... you don't need to turn this on. So it does not > waste CPU-cycles if it's not needed... allowing for the "old" > behavior mixed with the new one...) > 5. Drawback: if the plugin doesn't know it can use oversampling,... > it doesn't use it... > 6. Still some bugs preventing me from releasing this ... but I might > get these out on weekend... ;-) > > > While I can measure that there is some (minor) alias left... I can't > hear the difference to the last approach... > > cu > Stefan > |