Hi, Tim!
> On November 15, 2014 12:37:36 PM Andrew Deryabin wrote:
>> Hi, guys!
>>
>> Recently I found out why dexed synth is initialized with volume
>> control set to zero in lv2host and how to deal with this.
>>
>> Here is the steps I've taken:
>>
>> 1. After examining ttl files used by plugin it became clear that default
>> value for volume control is zero. So plugin was initialized right in MusE.
>> 2. But, in ardour and jalv volume was initizlized to 1 (maximum value).
>> I started to search for a reason.
>> 3. Dexed is built on the base of juce. Juce uses it's own cache of
>> controls and on each run() checks this cache and current control values.
>> If the cache value differs, juce sets plugin value to current supplied
>> host value:
>>
>> curValue = *portControls[i];
>> if (lastControlValues[i] != curValue)
>> {
>> filter->setParameter (i, curValue);
>> lastControlValues.setUnchecked (i, curValue);
>> }
>> Here portControls is array of pointers to controls (of type float) that
>> were connected by lv2 host via connect_port() calls.
>>
>> It was clear, that current volume control is not set to zero upon plugin
>> instantiation.
>>
>> 4. Than I found that class member PluginFx fx holds member `float
>> uiGain` that is the current volume level. But PluginFx has no default
>> constructor, so uiGain may be left uninitialized. C++ standard says that
>> this default value should be zero. But it seams that gcc ignores this
>> standard or implements it in a different way. The result is that member
>> float variable in that case was initialized to 4.59163468e-41. It's very
>> close to zero, but expression (0 == 4.59163468e-41) whatever gives false
>> (and it's right).
>>
>> 5. Than, while checking dexed activate() method I found that uiGain was
>> initialized to 1 (maximum value). But:
>> juce already cached wrong value of uiGain = 4.59163468e-41 during plugin
>> construction. And on the first call of run() current value (1, set by
>> activate()) is reset to zero (current host value) by the above code
>> because 0 != 4.59163468e-41. And as a result we have no output from the
>> plugin.
>>
>> 6. But anyway it was very interesting why in ardour, qtractor and jalv
>> dexed does not reset it volume level though the lv2 code of all these
>> hosts sets volume control by to default value (zero from ttl files) - I
>> checked it.
>>
>> And now it's time for the very interesting finding. Somehow gcc makes
>> this equation (0 == 4.59163468e-41) return true in these hosts. But how?
>> I've checked various flags and found the one that makes it:
>> -funsafe-math-optimizations
>> Yes, that's it. This flags makes assumption that values too close to
>> zero == 0, so in this case (0 == 4.59163468e-41) is always be true is
>> this flag is set. That's why juce doesn't reset volume to zero and uses
>> cached control. But in the same time host holds current volume level ==
>> 0. So there are 3 values are there: 4.59163468e-41 (cached by juce), 0
>> (host value) and 1 (current plugin value).
>>
>> This flag is a part of -ffast-math gcc option, so, when MusE is built in
>> release mode (0 == 4.59163468e-41) will always return true.
>>
>> So the summary is:
>>
>> 1. This bug is completely releted to Dexed.
>> 2. Hosts, that compiled with -funsafe-math-optimizations set in any way
>> will respect this bug.
>> 3. Only the lack of this option in MusE debug build helped me to find
>> out the reason, so I leaved debug build flags as is.
>>
>> That's all, quest is solved :)
>>
>>
>> P.S. I've also made some optimizations to lv2 host code recently to get
>> rig of warnings and support new lv2 lib api in atom forge.h. Changes are
>> in master now.
>>
>> Regards,
>> Andrew
> Hi, thanks for the painstaking work investigating this.
> Is it possible you have found something which could, and should,
> be fixed upstream by the makers of Dexed, or LV2?
> Maybe inform them of your findings?
Just posted these results to Filipe Coelho, the maintainer of lv2 port
of Dexed. May be it will be fixed in the future.
> ---
>
> On another note, I noticed you have wandered into the tempo and
> signature classes coding.
> I hope it was not too confusing and frustrating.
>
> I just wanted to point out how it came to be like that:
> The folders 'AL' and 'AWL' were imported by me after the change
> to QT4. The folders come from the QT4 muse_evolution branch
> (the one I mentioned before which was the original 'muse2' by Werner).
>
> In old MusE-QT3 we had the older version of the Deicsonze synthesizer.
> But in muse_evolution the Deicsonze author made a completely new
> version which was far superior.
>
> I could not let this wonderful Deicsonze go to waste in an abandoned branch,
> so I imported the whole thing, which required importing the 'AL' and 'AWL'
> folders.
>
> So the 'AWL' folder contains widgets which are currently only used by
> the Deicsonze synth.
>
> At the time, it was not clear what future additional roles these widgets
> might play, so I left them in their own folder instead of our own
> /muse/widgets folder.
>
> Also, the 'AL' folder contains classes which were improved classes
> over our own, such as tempo and signature.
>
> You can see that I made use of some the classes, replacing our own
> versions. Yet I never moved them into our own /muse folder,
> nor did I ever remove the replaced classes modules.
>
> So there may be confusion when trying to follow tempo and
> signature classes and so on. Some reside in 'AL' while others
> reside in /muse.
> By this day, we should probably consolidate this stuff and
> move it around to the proper places, and either remove or
> consolidate the unused widgets and classes in 'AWL' and 'AL'.
Thanks for explanation!
My changes to those headers were caused by not compiling MusE in debian
6, which has gcc 4.4 version.
Some friend class definitions in AL and AWL headers declared friend
classes as:
friend <class_name>;
instead of
friend class <class name>;
gcc 4.4 don't like such declarations, so I added the keyword <class> to
definitions and nothing more.
If you don't mind, I can do the consolidation work you explained. I like
clean code :)
Regards,
Andrew
> Thanks.
> Tim.
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Lmuse-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
