Supersonic Audio

16 Apr 2020 12:56 #45935 by timi
This AeonWave, is it also called "sound system version 2.0" in FG by any chance?

Because the source says you can use expressions within a volume block with
sound system version 2.0.

sourceforge.net/p/flightgear/simgear/ci/...r/sound/xmlsound.hxx

But this didn't work in 2019.1.2.

Please Log in or Create an account to join the conversation.

01 May 2020 09:43 #46148 by Algernon
Yeah, I've had the same experience - expressions never work.

Please Log in or Create an account to join the conversation.

06 May 2020 06:00 #46264 by Richard
I've just checked and sure enough expressions should be available for use in <volume> and <pitch> - but there is a (long standing) in the logic that causes it not to work. I'll see if I can get this fixed for 2020 and also for the next release of 2018.3 LTS

Please raise a ticket or post to the devlist when stuff like this that looks broken and it might get fixed.

tickets: sourceforge.net/p/flightgear/codetickets/
devlist: sourceforge.net/projects/flightgear/lists/flightgear-devel

Please Log in or Create an account to join the conversation.

06 May 2020 06:08 #46265 by Algernon
Damn! Literally a few hours after I perfected using autopilot rules for sound!! Although it's still better than the built in system, as you can use the gain element of a filter as a sidechain to influence the gain of other properties...

There is also another issue - Timi, I think you experienced this, but can you confirm? - where the documentation says you should be able to have five volume and pitch control elements for each sample, but I can't make it work with more than two volume and one pitch. I'll raise a ticket for it, if others concur and it's not just me breaking it with foolishness.

Please Log in or Create an account to join the conversation.

06 May 2020 07:28 #46267 by timi
Yes, I have that same issue with the number of volume blocks. But I opened an issue about it too.

Please Log in or Create an account to join the conversation.

06 May 2020 07:33 #46268 by timi
However if the expressions would work, one volume block might be enough even.

Please Log in or Create an account to join the conversation.

06 May 2020 07:47 #46269 by timi
Here's my ticket.
sourceforge.net/p/flightgear/codetickets/2194/

It only talks about volume though. I haven't needed more than one pitch block yet.

Please Log in or Create an account to join the conversation.

06 May 2020 13:55 #46275 by Richard

Algernon wrote: Damn! Literally a few hours after I perfected using autopilot rules...

...documentation says you should be able to have five volume and pitch control elements...


Now more than ever it really is worth reporting problems to either the devlist or the issue tracker - as there is a real desire to get as many long standing bugs fixed as possible - and also to fix any new bugs that get introduced. So if you find something that doesn't work right, or needs a workaround then pretty please report it.

At the moment there are more active core developers than FG has had in a long time and things are getting fixed.

From the code it does look as though the processing of multiple volume elements works - however do bear in mind that the volume is a set of factors

volume = 1.0 * volume0 * volume1 * volume2 * volume3 * volume4 * volume5
volume_offset = volume_offset0 + volume_offset1 + volume_offset2 + volume_offset3 + volume_offset4 volume_offset5

volume offset could be subtracted if the <fasctor> is negative.

Please Log in or Create an account to join the conversation.

06 May 2020 14:08 - 06 May 2020 14:09 #46276 by timi
Thanks Richard, I'm aware of them being multiplied and I was counting on it to mute the inside cockpit audio when I opened the canopy for example. But that particular volume block just got ignored depending on the order of them in the config file. And order should not be a factor when they are multiplied, right?

So what I observed is that if I have three volume blocks only the first and the third are considered.
the second one is just skipped for whatever reason.
The following user(s) said Thank You: Algernon

Please Log in or Create an account to join the conversation.

06 May 2020 14:29 #46277 by timi
Also the logic of the volume configs in my bug report may look insane though
as it's just something I tried in case there's an issue using the same property
in two volume blocks going to opposite directions. So I tried what happens if
I control the volume with the throttle and the N2 at the same time.

Please Log in or Create an account to join the conversation.

06 May 2020 17:57 #46287 by Richard
given a version of your example:
            <volume>
                <property>/a/v1</property>
                <factor>0.1</factor>
            </volume>
            <volume>
                <property>/a/v2</property>
                <offset>1</offset>
                <factor>-3</factor>
            </volume>
            <volume>
                <property>/a/v3</property>
                <offset>1</offset>
                <factor>-1</factor>
            </volume>

With v1=0.11, v2=0.12 v3=0.13 it is applying all of the volume parts; the thing to watch is that when the factor is < 0 the equation becomes volume = offset - v instead of volume = volume * v (where v is the calculated number).

Having a -ve factor will in effect throw away the computed value prior to this point.

This debugs as follows.
update(): Have 3 volume entries
 --> 0:prop /a[0]/v1[0] => 0.110000 factor = 0.100000 v=0.011000 offset 0.000000, now 0.000000, v=0.011000 vol=0.011000 ==> 0.011000
 --> 1:prop /a[0]/v2[0] => 0.120000 factor = 3.000000 v=0.360000 -ve offset 1.000000 0.360000 = 0.640000  ==> 0.640000
 --> 2:prop /a[0]/v3[0] => 0.130000 factor = 1.000000 v=0.130000 -ve offset 1.000000 0.130000 = 0.870000  ==> 0.870000

I think it is possibly doing what is intended which is not necessarily what it is documented to do, or even what it should do.

This is the complete section of code that does the volume calcs (for reference)
   printf("update(): Have %d volume entries\n", max);

   for(i = 0; i < max; i++) {
      double v = 1.0;
      printf(" --> %d:", i);
      if (_volume[i].expr) {
         volume *= _volume[i].expr->getValue(nullptr);
         printf("expr=%f\n", _volume[i].expr->getValue(nullptr));
         expr = true;
         continue;
      }

      if (_volume[i].prop) {
         // do not process if there was an expression defined
         if (expr) continue;

         v = _volume[i].prop->getDoubleValue();
         printf("prop %s => %f ", _volume[i].prop->getPath(),v);
      }
      else if (_volume[i].intern) {
         // intern sections always get processed.
          printf("intern ");
          v = *_volume[i].intern;
      }

      if (_volume[i].fn)
         v = _volume[i].fn(v);

      v *= _volume[i].factor;
      printf("factor = %f v=%f ", _volume[i].factor,v);

      if (_volume[i].max && (v > _volume[i].max)) {
          v = _volume[i].max;
          printf("lim max=%f\n", _volume[i].max);
      }

      else if (v < _volume[i].min){
         v = _volume[i].min;
         printf("lim min=%f\n", _volume[i].min);
      }


      if (_volume[i].subtract){				// Hack!
         volume = _volume[i].offset - v;
         printf("-ve offset %f %f = %f ", _volume[i].offset, v, volume);
      }
      else {
         volume_offset += _volume[i].offset;
         volume *= v;
         printf("offset %f, now %f, v=%f vol=%f", _volume[i].offset, volume_offset, v, volume);
      }
      printf(" ==> %f\n", volume);
   }

Please Log in or Create an account to join the conversation.

07 May 2020 10:37 #46296 by timi
Ok, let's say the value of the /a/v2 property gets to 1 and everything else stays
the same in your example. What would you expect the final volume to be?

Please Log in or Create an account to join the conversation.

07 May 2020 14:42 #46313 by Algernon
Have you tried doing audio with autopilot rules and expressions yet, Timi? First hour that you do is a sheer joy - able to reload and hear your changes with a simple click of the Debug menu instead of having to restart. I would suggest it's a great way to prototype sound work, even if expressions in blocks was fixed, as it allows you to fine tune your sounds, and hear the change immediately when you click to reload autopilot. I got more done in one hour than I would have in a day constantly restarting FG.

Please Log in or Create an account to join the conversation.

07 May 2020 14:46 #46315 by timi
Yes, I used FCS controls for the F-16 which is almost the same as using these autopilot rules
but as I understand, the FCS is JSBSim only but autopilot works for everything.

Please Log in or Create an account to join the conversation.

07 May 2020 15:28 #46317 by Richard
Given that the documentation says this:

Normally all offset values are added together and the results after property calculations will be multiplied. A special condition occurs.

When the value of factor is negative, in which case the offset doesn't get added to the other offset values but instead will be used in the multiplication section.


I'd expect it to evaluate as follows

example(1)
  1. volume = /a/v1 * 0.1 * volume which is 0.011
  2. volume = (/a/v2*3 - offset) * volume :: which is (3-1) * 0.011 which is 0.022
  3. volume = (/a/v3*1 - offset) * volume :: which is (0.13-1) * 0.022 which is -0.01914

So I'd expect the volume to be 0 because of (2) above.

However what the code actually does is this;
  1. volume = /a/v1 * 0.1 * volume :: which is 0.011
  2. volume = 1 - /a/v2*3 which is -2
  3. volume = 1 - /a/v3*1 which is 0.87

Because of the -ve factor the previously calculated value of volume is being lost (see xmlsound.cxx:460).

I think this is wrong, and in fact this whole method is a mess and I don't think it's ever worked as intended, or as described in the documentation.

I can probably fix it so that it works as in example(1) above;

However what do you expect that it should do.

Please Log in or Create an account to join the conversation.

07 May 2020 15:45 #46319 by timi
I was expecting zero as well. But what I really got is that nothing happened
while changing the property of the second volume block. It literally didn't
change the volume no matter the value.

Then if I moved the third block up to be the second one, then that block
stopped changing the volume no matter the value of the property.

It was always the first and last block that actually changed the volume and
the second one was ignored somehow.

Please Log in or Create an account to join the conversation.

08 May 2020 17:10 #46372 by Richard
I'd be interested in all opinions about exactly how the multiple volume elements should work; that way we can hopefully fix it for 2020.x and backport to 2018.3.x LTS

Please Log in or Create an account to join the conversation.

08 May 2020 17:18 #46373 by timi
I would like the volume blocks always to be multiplied regardless of the factor being
negative or not in one or more of them.

Please Log in or Create an account to join the conversation.

08 May 2020 17:22 #46374 by timi
Also I don't want the value of the volume get smaller than zero while at it.
For pitch I want to be able to use as large negative offsets as I want while
the actual value of the pitch don't get smaller than zero.

Please Log in or Create an account to join the conversation.

08 May 2020 17:33 #46377 by timi
So I want the total offset + final value to work but if it's less than zero in any
of the blocks then it just gets truncated to zero in that block and gets
multiplied with the rest of them.
The following user(s) said Thank You: Algernon

Please Log in or Create an account to join the conversation.

Time to create page: 0.206 seconds
Powered by Kunena Forum

Latest Forum Posts

PM Notifications

You are not logged in.

PM Mailbox

You are not logged in.

Latest updated downloads