Re: [LAD] Is -ffast-math safe for audio?
On Sat, 24 Nov 2018 14:19:01 +0100
Fons Adriaensen wrote:
>On Sat, Nov 24, 2018 at 10:49:46AM +, Will Godfrey wrote:
>
>> >The safe way is of course:
>> >
>> >int i = (int) floorf (p);
>> >float f = p - i;
>
>> I'd been mulling over *exactly* that point for some time. My reasoning being
>> that in the latter case, if the integer was slightly wrong then using it for
>> the subtraction should give a remainder that was also slightly wrong, but in
>> a
>> direction that tends to compensate for the error.
>
>How can an int be 'slightly wrong' ? :-)
Ummm, bad wording on my part. I meant out by 1. The difference would be made up
next period.
>The advantage of the 'safe' way is that you always have p == i + f.
>
>> The other thing, is why do we need the floorf? Or in the original example
>> (which was taken from working code) truncf?
>> A straight cast to int seems to give exactly the same result, and is at least
>> twice as fast with -O3 and about 4 times as fast unoptimised.
>
>We want f >= 0, so rounding must be towards -inf. Casting will truncate
>(i.e. round towards zero). This gives the correct result only if p >= 0.
>That may be all you need, but I wouldn't like to depend on it.
Well in this particular case, it can't be less than zero - notwithstanding time
travel :)
>There is a way to avoid all float to int conversions, at least outside
>the per-sample loops.
>
>Suppose you have a wavetable of size L, current position is float p,
>and increment is float f. To generate N samples you'd have something
>like:
>
>
>for (i = 0; i < N; i++)
>{
>k = floorf (p);
>u = p - k;
>
>// use k, u to interpolate in wavetable
>
>p += f;
>if (p >= L) p -= L;
>}
>
>To avoid floorf() inside the loop, instead of maintaining p and f
>as floats, split both of them from the start into an integer and
>float part:
>
>k = floorf (p);
>u = p - k;
>
>kf = floorf (f);
>uf = f - kf;
>
>for (i = 0; i < N; i++)
>{
>// use k, u to interpolate in wavetable
>
>k += kf;
>u += uf;
>if (u >= 1.0f)
>{
> k += 1;
> u -= 1;
>}
>if (k >= L) k -= L;
>// or k &= L-1 if L is a power of 2.
>}
>
>
>Ciao,
>
Interesting. I'll look into this.
--
Will J Godfrey
http://www.musically.me.uk
Just because you know what I'm talking about, it doesn't mean *I* do.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] So in 2019, which plugin "format"?
Hi folks, At the risk of igniting a flame war, if one were to develop softsynth plugins for Linux, what would be the "framework" of choice these days? Back in the day I wrote some using DSSI, which was a model I was pretty comfortable with. I had a look at LV2 but couldn't work out how to generate the huge incomprehensible non-human-readable "ttl" files. Where does the world stand now? -- Gordonjcp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] So in 2019, which plugin "format"?
On 11/25/2018 11:47 PM, Gordonjcp wrote: > Hi folks, > > At the risk of igniting a flame war, if one were to develop softsynth > plugins for Linux, what would be the "framework" of choice these days? https://distrho.github.io/DPF/ -- https://github.com/DISTRHO/DPF > Back in the day I wrote some using DSSI, which was a model I was pretty > comfortable with. I had a look at LV2 but couldn't work out how to > generate the huge incomprehensible non-human-readable "ttl" files. I thought you didn't want a flame-war? :) How are they not human-readable? They're nice semantic triplets. Anyway, you could use DPF to auto-generate the file for you. > Where does the world stand now? I don't know about 2019, but in 2018 LV2 still sucks least of the available options. In 2019, perhaps VST3 may become an alternative, but right now Bitwig is the only Linux host to support it, and the VST-GUI API for Linux is also still in flux. ciao, robin PS. you could /steal/ some GPL code from e.g. zyn-fusion or helm. The former uses DPF, the latter a patched JUCE to export LV2, both also offer VST2 as alternative. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] So in 2019, which plugin "format"?
I have been happy using falkTX's Disthro Plugin Framework: https://github.com/DISTRHO/DPF It's very lightweight on GUI stuff, so depending on what you want out of a framework, you may or may not like it. JUCE is a (very different) alternative: https://juce.com/ If you're doing a sampled virtual instrument, you might find HISE useful: http://www.hise.audio/ ... HISE is built on JUCE. Regards, Michael On Sun, Nov 25, 2018 at 4:26 PM Gordonjcp wrote: > Hi folks, > > At the risk of igniting a flame war, if one were to develop softsynth > plugins for Linux, what would be the "framework" of choice these days? > > Back in the day I wrote some using DSSI, which was a model I was pretty > comfortable with. I had a look at LV2 but couldn't work out how to > generate the huge incomprehensible non-human-readable "ttl" files. > > Where does the world stand now? > > -- > Gordonjcp > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
