search

grame-cncm / faust

Functional programming language for signal processing and sound synthesis
http://faust.grame.fr
Other
2.58k stars 322 forks source link

Physical Modeling examples (pressure) issues? #275

Closed GeorgeNs closed 5 years ago

GeorgeNs commented 5 years ago

Hi All.I just built the latest faust,and faustlive on linux and while testing the winds,the PM examples,i got either strange pops,flute, or weird distortions,bottle,..it seems an issue relted to pressure?I haven't searched more but i 'd like to know, anyone else with the same problem? all versions before had worked normal. Thanks

rmichon commented 5 years ago

Hi George, Could you be a bit more specific: which function did you try and didn't work?

GeorgeNs commented 5 years ago

Hi. I compiled the latest version of faust with llvm-7,then i also built the latest faustlive. The first thing i did was to do some testing with the examples included in faustlive. Every example that includes winds PM(blow bottle,clarinet,flute etc.) doesn't work as expected(heavy distortion,plops without following any sound etc.). I also tried the examples without faustlive, on FaustWorks and command as well, i got the same issues. I haven't tried more testing yet,but i am wondering is that happening only to me?

rmichon commented 5 years ago

Every example that includes winds PM(blow bottle,clarinet,flute etc.) doesn't work as expected(heavy distortion,plops without following any sound etc.).

I just tried the following example: https://github.com/grame-cncm/faust/blob/master-dev/examples/physicalModeling/clarinet.dsp both in FaustLive and in the terminal and it works as expected when I increase pressure... Which example doesn't work for you?

GeorgeNs commented 5 years ago

That is strange then. Any example that contains pressure modeling,that is all the examples such as clarinet,flutes etc., don't work as before. The rest of them plucked strings,harp etc. work. I have to search what is wrong from my side,I didn't get any warning while compiling Faust. By the way I had to use ,make all, command for faust in order to be able to build Faustlive later on successfully. is this correct?

GeorgeNs commented 5 years ago

Update: tested in older laptop with Ubuntu 16 and llvm 6 , everything works. I will keep searching what's wrong on my Ubuntu 18.04 compilation

josmithiii commented 5 years ago

Hi All,

This sounds possibly related to denormals to me. To check, change the pressure signal in physmodels.lib / blower_ui from

pressure = hslider("v:blower/[0]pressure",0,0,1,0.01) : si.smoo;

to something like

pressure = hslider("v:blower/[0]pressure",1e-10,1e-10,1,0.01) : si.smoo;

The idea is to avoid zero completely.

I found this sort of guard to be necessary in GeoShred after the most recent iOS update. Apparently Apple has a problem with its Bitcode implementation (the problem occurred in TestFlight builds but not Xcode builds, either Debug or Release).

My experience is that denormalized floats are the most common source of numerical failures in physical models, even after we think we've taken care of them with compiler flags, chip modes, etc. The good news is that there is no such thing as zero in the real world (with probability one), so physical models can simply avoid zero and anything too close to it.

Perhaps zero-point energy was introduced to avoid zero in our Universe Physics Engine. :-)

On Wed, Feb 6, 2019 at 8:50 AM GeorgeNs notifications@github.com wrote:

Update: tested in older laptop with Ubuntu 16 and llvm 6 , everything works. I will keep searching what's wrong on my Ubuntu 18.04 compilation

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/grame-cncm/faust/issues/275#issuecomment-461097071, or mute the thread https://github.com/notifications/unsubscribe-auth/ACGVFVuWQx52CJmQEm7JXqeaITc27Vupks5vKwfMgaJpZM4af-np .

--

Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ http://ccrma.stanford.edu/

rmichon commented 5 years ago

Thanks for your input, Julius. It sounds like this could be the issue indeed, which is kind of crazy...

GeorgeNs commented 5 years ago

Thanks a lot! Yes denormals! Didn't think about since version before ( 2.5) had not such an issue... So crazy! I am gonna test a bit more,then close this topic. Cheers

GeorgeNs commented 5 years ago

Probably I should not ask this question here,maybe it is not related to the issue before,but running faustlive from command i can see the following:

llvm_dsp_poly_factory : fEffectFactory FaustDSP : 111 : ERROR : undefined symbol : effect

Is this something that can affect any functionality or just ignoring it is okay?

sletz commented 5 years ago

Ignoring it is OK.

GeorgeNs commented 5 years ago

Alright, Thank you All!

sletz commented 5 years ago

So does this mean we should correct to pressure = hslider("v:blower/[0]pressure",1e-10,1e-10,1,0.01) : si.smoo; in the official physmodels.lib ? @rmichon ?

rmichon commented 5 years ago

@sletz mmmh that's a good question. I'm afraid that's a bit more complicated than that since many of the functions in this lib use envelope generators (e.g., ADSR) to control pressure or similar types of parameters. May be a better/more universal solution would be to add an option to the Faust compiler to add a tiny DC offset to the output signals of a Faust program. I remember we talked about this @josmithiii at some point. What do you guys think? @orlarey @sletz @josmithiii ?

josmithiii commented 5 years ago

I would probably do it something like this:

diff --git a/physmodels.lib b/physmodels.lib index daaeff7..5b23cca 100644 --- a/physmodels.lib +++ b/physmodels.lib @@ -1771,6 +1771,12 @@ with{ // reedStiffness: reed stiffness (0-1) // bellOpening: the opening of bell (0-1) //---------------------------------- + +// move these to signals.lib or basics.lib ? +denormalGuard = 1.0e-20; // below 64-bit machine epsilon and above denormalization for 32 bits

On Thu, Feb 7, 2019 at 4:58 PM Romain notifications@github.com wrote:

@sletz https://github.com/sletz mmmh that's a good question. I'm afraid that's a bit more complicated than that since many of the functions in this lib use envelope generators (e.g., ADSR) to control pressure or similar types of parameters. May be a better/more universal solution would be to add an option to the Faust compiler to add a tiny DC offset to the output signals of a Faust program. I remember we talked about this @josmithiii https://github.com/josmithiii at some point. What do you guys think? @orlarey https://github.com/orlarey @sletz https://github.com/sletz @josmithiii https://github.com/josmithiii ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/grame-cncm/faust/issues/275#issuecomment-461653117, or mute the thread https://github.com/notifications/unsubscribe-auth/ACGVFbdWF8KzD-2CJz6KohDeKajbcc1vks5vLMufgaJpZM4af-np .

--

Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ http://ccrma.stanford.edu/

sletz commented 5 years ago

Well after discussion a bit with Yann we are still not clear about the root reason of the problem: denormalized samples are supposed to possibly cause CPU spikes but should not change the semantic of the computed code. Moreover we use hardware FTZ or DAZ to force denormalized samples to be zero (at least on Intel CPU). @josmithiii do you have a simple example Faust DSP program that we could test to better understand ?

josmithiii commented 5 years ago

I’m not sure we know that the problem here is denormals, but I really did run into a problem where adding a DC offset such as this fixed the problem – it was a numerical failure that sounded similar to what is being reported here that only happened in apple’s bitcode. I don’t have any failing examples on the Mac or even iOS built on the Mac, etc. in summary, I don’t trust IEEE floats. Since true physical models don’t need zero, I have adopted that convention. That solved my problem and nothing else did.

On Thu, Feb 7, 2019 at 11:31 PM Stéphane Letz notifications@github.com wrote:

Well after discussion a bit with Yann we are still not clear about the root reason of the problem: denormalized samples are supposed to possibly cause CPU skips but should not change the semantic of the computes code. Moreover we use hardware FTZ or DAZ to force denormalized samples to be zero (at least on Intel CPU). @josmithiii https://github.com/josmithiii do you have a simple example Faust DSP program that we could test to better understand ?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/grame-cncm/faust/issues/275#issuecomment-461715209, or mute the thread https://github.com/notifications/unsubscribe-auth/ACGVFaN7_QBC4hjyn8FDhgYXSAG7cGNyks5vLSfIgaJpZM4af-np .

--

Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ http://ccrma.stanford.edu/

sletz commented 5 years ago

OK so it seems more like a numerical precision issue. Have you ever tried to compile and run the code in double?

GeorgeNs commented 5 years ago

Hi guys, Was I too hasty to close the topic? Actually I was in hurry these days and I am still on the way so I haven't tried something new yet. As soon as I will be back in a few days I will search more thoroughly. Also it seems that it's not only me who had this issue on Ubuntu 18.04. thank you All

PS. Currently I can only test with my old laptop which is AMD,Ubuntu 16,and everything works fine. My Intel new laptop with Ubuntu 18.04 has the issue

josmithiii commented 5 years ago

OK so it seems more like a numerical precision issue. Have you ever tried to compile and run the code in double?

I don't think bitcode (a bitstream file format for LLVM IR) should have a different precision. It should be bit-for-bit identical. My guess is that the bitcode translator does not support whatever FTZ and/or DAZ support used in Faust architecture files.

I searched the Faust architecture files just now for ftz and daz and do not find much mention of them. Is this normally handled in the faust2* scripts instead? It looks like I must take responsibility for ensuring ftz and daz are set when compiling C++ for all Intel platforms I aim for, but what do I do for Arm?

Avoiding zero is not only easier by far, but it propagates to all users of my Faust code, on all platforms they compile for, with no special compilation flags required.

IEEE floating point was not intended for signal processing.

On Fri, Feb 8, 2019 at 3:04 AM GeorgeNs notifications@github.com wrote:

Hi guys, Was I too hasty to close the topic? Actually I was in hurry these days and I am still on the way so I haven't tried something new. As soon as I will be back in a few days I will search more thoroughly. Also it seems that it's not only me who had this issue on Ubuntu 18.04. thank you All

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

--

Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/

sletz commented 5 years ago

FTZ and/or DAZ support hardware activation is done by the AVOIDDENORMALS macro defined in dsp.h (https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/dsp.h) Then AVOIDDENORMALS is used in the audio callback just before callingdsp::compute(....) when is is necessary (for instance CoreAudio layer already does the equivalent of AVOIDDENORMALS in the audio callback, so nothing has to be done with the OS X (https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/audio/coreaudio-dsp.h) and iOS (https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/audio/coreaudio-ios-dsp.h) audio driver).

AVOIDDENORMALS has to be explicitly added in JACK, alsa drivers..etc...

sletz commented 5 years ago

About double: I was thinking in testing with faust -double doc.dsp. Obviously since audio callback samples are float in OS X and iOS, float => double conversion would have to be done by wrapping the compute method. This is some code for that here https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/dsp-adapter.h (look at the dsp_sample_adapter class).

josmithiii commented 5 years ago

FTZ and/or DAZ support hardware setup is done by the AVOIDDENORMALS macro define in dsp.h ...

Ok, thanks for the info.

What happens on standalone ARM processors such as in the many DIY boards?

I assume the ADI SHARC Audio Module (SAM) has its act together on this front. DSP chips always get it right, as far as I know.

On Fri, Feb 8, 2019 at 10:47 AM Stéphane Letz notifications@github.com wrote:

FTZ and/or DAZ support hardware setup is done by the AVOIDDENORMALS macro define in dsp.h ( https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/dsp/dsp.h ) Then AVOIDDENORMALS is used in the audio callback just before calling dsp::compute(....) when is is necessary (for instance CoreAudio layer already does the equivalent of AVOIDDENORMALS in the audio callback, so nothing has to be done with the CoreAudio ( https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/audio/coreaudio-dsp.h) and iOS ( https://github.com/grame-cncm/faust/blob/master-dev/architecture/faust/audio/coreaudio-ios-dsp.h) audio driver).

AVOIDDENORMALS haes to be explicitly added in JACK, alsa drivers..etc...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/grame-cncm/faust/issues/275#issuecomment-461905009, or mute the thread https://github.com/notifications/unsubscribe-auth/ACGVFd9o43yVLHVX5_4HuYPJUY1UwGRfks5vLcY0gaJpZM4af-np .

--

Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ http://ccrma.stanford.edu/

sletz commented 5 years ago

Good question !

I found some elements here : https://stackoverflow.com/questions/7346521/subnormal-ieee-754-floating-point-numbers-support-on-ios-arm-devices-iphone-4. I understand that iSO is configured with FTZ.

I just asked on Bela forum: https://forum.bela.io/d/782-ftz-status-on-bela

josmithiii commented 5 years ago

That's very encouraging to hear that ARM does FTZ and DAZ by default. However, that leaves open the mystery of why bitcode builds for iOS seem to have a problem.

On Fri, Feb 8, 2019 at 11:53 PM Stéphane Letz notifications@github.com wrote:

Good question !

I found some elements here : https://stackoverflow.com/questions/7346521/subnormal-ieee-754-floating-point-numbers-support-on-ios-arm-devices-iphone-4. I understand that iSO is configured with FTZ.

I just asked on Bela forum: https://forum.bela.io/d/782-ftz-status-on-bela

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

--

Julius O. Smith III jos@ccrma.stanford.edu Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/

GeorgeNs commented 5 years ago

Hi guys, I just did some testing today and I can say that -double and DC doesn't change anything related to the particular issue. I discovered that if I build the master-dev branch then everything works again using terminal! However,i don't know why the stable release doesn't work.OK,so far so good... The problem is that i cannot have faustlive now. the faustqt.h is missing in the gui directory. I can find it in release stable version but not in git cloned master branch. and if i just copy the missing file

then i get the error: fCurrentAudio->setShutdownCb(cb, arg); and i change it to fCurrentAudio->setShutdownCallback(cb, arg);

and everything goes well until: tmp/FLWindow.o: In function FLWindow::allocateInterfaces(QString const&)': FLWindow.cpp:(.text+0xa9a5): undefined reference tovtable for QTGUI' tmp/FLWindow.o: In function FLWindow::deleteInterfaces()': FLWindow.cpp:(.text+0xb906): undefined reference tovtable for QTGUI' tmp/FLWindow.o: In function QTGUI::~QTGUI()': FLWindow.cpp:(.text._ZN5QTGUID2Ev[_ZN5QTGUID5Ev]+0x3): undefined reference tovtable for QTGUI' tmp/FLWindow.o: In function non-virtual thunk to QTGUI::~QTGUI()': FLWindow.cpp:(.text._ZN5QTGUID2Ev[_ZN5QTGUID5Ev]+0x17c): undefined reference tovtable for QTGUI' tmp/FLWindow.o: In function non-virtual thunk to QTGUI::~QTGUI()': FLWindow.cpp:(.text._ZN5QTGUID2Ev[_ZN5QTGUID5Ev]+0x2e3): undefined reference tovtable for QTGUI' tmp/FLWindow.o:FLWindow.cpp:(.text._ZN5QTGUID2Ev[_ZN5QTGUID5Ev]+0x44c): more undefined references to `vtable for QTGUI' follow

Thanks a lot

sletz commented 5 years ago

Use the FaustLive dev branch.

GeorgeNs commented 5 years ago

Yes can build now.Thanks. Finally i can conclude that my problem is related to faustlive and faustworks as well. Using terminal everything works. But only this way works.

BTW I also tried to run the sitar example and it sounds weird,so it seems is not only the winds

sletz commented 5 years ago

How are you testing in the terminal? Which faust2xx script are you using ?

GeorgeNs commented 5 years ago

faust2jaqt is what i mainly use For all my tests I use jack

GeorgeNs commented 5 years ago

Update: Hi guys!It is very strange but I think the dsp files in examples are not identical in faustlive and faust compilations. Is this true? Just taking the blowbottle from faustlive and running it using terminal produces weird distortions,while taking the same example from faust directory makes everything work again. The two files look identical but I think they are not.I will search later what is the small difference,but if you have any similar experience pls let me know.thanks

GeorgeNs commented 5 years ago

I think in all these envelopes site in signal processing part of all these dsp files,the value 100 is wrong.it should be 1. Could you pls confirm?

GeorgeNs commented 5 years ago

Update2: Something really weird happens to me! I checked the examples in faustlive source and there is no value 100 in envelopes functions. However, I open one example(blowBottle) then right click to edit faust code,i save the new file somewhere and there i see the value 1 changed to 100! for example: envelopeMod = asr(nonLinAttack,100,envelopeRelease,gate);

but this belongs to back up examples that won't be used So something is merging the backup with the actual examples regarding the adsr(s) functions, the imported libraries stay the same as in the examples files

sletz commented 5 years ago
GeorgeNs commented 5 years ago

OMG! Yes, I had compiled long time ago the dynamic faustlive 2.5.8 if remember well,the hidden CurrentSession files in home directory will be preserved after building the new faustlive version. Removing this totally solved all the issues. In my old machine i used the binary for ubuntu so when i built the new faustlive i didn't have this issue. Thank you All for your support and your time