search

c172p-team / c172p

A high detailed version of the Cessna 172P aircraft for FlightGear
GNU General Public License v2.0
80 stars 43 forks source link

Apply new click sounds to switches #238

Closed gilbertohasnofb closed 9 years ago

gilbertohasnofb commented 9 years ago

Apply new click sounds to cockpit switches (lights, master, avionics switch, etc.). Should be fairly soft.

Could you give me a hand with this, @onox?

wkitty42 commented 9 years ago

that's for the parking brake, right? :wink:

onox commented 9 years ago

I can't hear flap sounds even when clicking on them

I can definitely hear a click sound when I click on the flaps lever, but you'll also hear the sound of the flaps itself. The sound of the flaps is positioned near the speaker in the top panel. Is that where it should come from? Or should it come from the left and right wings?

the dial sounds are too loud IMO. I'd make them barely audible when the engine is at high RPM.

I'll reduce the volume.

the masters switch sound (both ALT and BAT) are a bit buggy. light switches also got a bit buggy

I have no problems with the switches. If you toggle /sim/model/c172p/sound/click-master to true, the sound will play, and when you toggle it to false and then to true again, you can re-play the sound again. The Nasal code will toggle the property to false after 0.1 seconds, which is the more than the duration of these click sounds. You would have to click faster than 10 times per second if you want to interrupt the sounds. You can try to toggle /sim/model/c172p/sound/click-parking, which will play a sound that takes 1.6 seconds. If you toggle it to false the sound will simply stop, if you toggle it to true again, the sound will play from the beginning again. I can't hear any brokenness.

onox commented 9 years ago

@gilbertohasnofb I've reduced the volume of the dial sounds.

gilbertohasnofb commented 9 years ago

I can definitely hear a click sound when I click on the flaps lever

You are correct, the sound is definitely there. As for the position, I really don't know.

I've reduced the volume of the dial sounds.

Much better IMO!

You would have to click faster than 10 times per second if you want to interrupt the sounds.

I hear some weird effect sometimes at a much slower rate than this. I tried to record it but the video is horrible. Anyway, see if you can hear it (turn up your volume as the video is very soft). At around 00:07 you can hear the first times the sound breaks, and at around 00:14 again. Link: https://www.youtube.com/watch?v=mm3bInvy_hc&feature=youtu.be

I can't hear any brokenness.

What about what I wrote that some switches (mainly light switches and sometimes the circuit breakers) do not make any sound? For me they make sound let's say 85-90% of the time, but sometimes they fail.

onox commented 9 years ago

I can hear the clicks in the video, but I don't hear anything wrong with them :confused:

gilbertohasnofb commented 9 years ago

@onox Yeah, I was afraid of that. Unfortunately the program I use to record video is rubbish when it comes to recording sound. Let's just continue implementing this and in the meantime I will make some tests on my side and see if I find anything reliable on how to reproduce these things I mentioned, ok?

@wkitty42

that's for the parking brake, right?

Yep! Sorry for my EngRish :smile: I already corrected the Thanks file.

@tigert Tuomas, which kind of sound does a trim wheel make? Would you be able to describe it?

onox commented 9 years ago

@gilbertohasnofb I see you added a commit to the bug-238 branch you also added to the master branch? If you add it to the master branch, then there's no need to add the same commit to this feature branch. We only care about adding sounds in this branch.

gilbertohasnofb commented 9 years ago

@onox Yeah, it was my mistake and I realised as soon as I did it (you can note that I added it first to the bug-238 branch; I had forgotten which branch I was in, sorry). But since it was a harmless addition to that branch, I just left things as they were. Is that a problem? Sorry for the mess..

onox commented 9 years ago

No, it's not a problem.

onox commented 9 years ago

@gilbertohasnofb I have added the sounds for the radio stack, except the two comm/nav radio's and the transponder. Some issues with the radio stack:

  1. The two nav radio's and transponder live in: Aircraft/Instruments-3d/kt76a/kt76a.xml, Aircraft/Instruments-3d/kx165/kx165-1.xml, and Aircraft/Instruments-3d/kx165/kx165-2.xml, so I couldn't add sounds for them.
  2. The buttons of the autopilot (kap140) instrument do not move :cry:

  3. We are currently using just the first 0.1 seconds of double-click2.wav. The full sound is 0.25 seconds long. Using the full part doesn't make sense because you can keep a (mouse)button pressed.

    Maybe the ADF, radio's, and AP instruments can be modified, so that buttons move from their 0.0 position to 1.2 and then back to 1.0 if you want to enable the button. (If that's how the buttons work) And move from 1.0 to 1.2 and then back to 0.0 if you want to disable it. In that case it might make sense to split double-click2.wav into two parts.

Notes: Position comm1/nav1:

-0.3660 -0.12 -0.04

Position comm2/nav2:

-0.3660 -0.12 -0.09

Position transponder:

-0.3660 -0.12 -0.25

onox commented 9 years ago

@gilbertohasnofb I also think that a different sound than scroll.wav should be used for the trim wheel. The autopilot might move the trim wheel and then it looks like some dial is being moved. It sounds confusing :stuck_out_tongue_closed_eyes:

onox commented 9 years ago

I think if you can add a new sound for the trim wheel scroll, then we can merge PR #265. The issues above require copy and modifying files from fgdata.

onox commented 9 years ago

@gilbertohasnofb I think your commit actually caused the branch to not be automatically be merge-able. However, I have done some interactive rebasing to squash some commits and simply removed your particular commit in the process.

gilbertohasnofb commented 9 years ago

@onox I will try to add a new sound for the trim wheel by tonight.

About the nav radios and transponder, why don't we copy them into our project then? Together that's only 439 kb more.

As for my last erroneous commit on this branch, my apologies again. Glad to hear it's mergeable right now.

gilbertohasnofb commented 9 years ago

@onox Okay, so I have prepared the new sound for the trim tab, but I am having a problem with our branch. I still didn't even try to add nor commit nor push this time. I simply did a git pull on the master branch (all fine), then when I did a git checkout bug-238 I got:

    Switched to branch 'bug-238'
    Your branch and 'origin/bug-238' have diverged,
    and have 17 and 13 different commits each, respectively.
        (use "git pull" to merge the remote branch into yours)

So I tried git pull again, but this time I got:

    Auto-merging c172p-set.xml
    CONFLICT (content): Merge conflict in c172p-set.xml
    Auto-merging c172-sound.xml
    CONFLICT (content): Merge conflict in c172-sound.xml
    Automatic merge failed; fix conflicts and then commit the result.

And if I another git pull, I get:

    M   Models/Interior/Panel/Instruments/AI/AI.xml
    M   Models/Interior/Panel/Instruments/dme/dme.xml
    M   Models/Interior/Panel/Instruments/dme/ki266.xml
    M   Models/Interior/Panel/Instruments/kap140/KAP140TwoAxisAlt.xml
    M   Models/Interior/Panel/Instruments/kma20/kma20.xml
    M   Models/Interior/Panel/Instruments/kr87-adf/kr87.xml
    U   c172-sound.xml
    U   c172p-set.xml
    Pull is not possible because you have unmerged files.
    Please, fix them up in the work tree, and then use 'git add/rm <file>'
    as appropriate to mark resolution, or use 'git commit -a'.

Do you know what is happening? If you can give me a hand solving this then I can push the new sound file as soon as possible.

wlbragg commented 9 years ago

@gilbertohasnofb, onox is definitely the one to sort this out but I can tell you on the second pull you had conflicts that required resolution (meaning you need to edit those files and correct the "tagged" lines that are in conflict). Then you commit those conflict resolution changes you just fixed.and you are ready to merge again. The third pull is simply telling you that you have files that aren't merged (all your new ones marked with "M") and the 2 files you need to edit that had conflicts (marked U).

gilbertohasnofb commented 9 years ago

Thanks @wlbragg. So if I manually copy the raw data from those two xml files from the but-238 branch here on GitHub and paste it on my repository, then I would have solved the conflict?

wlbragg commented 9 years ago

The "two files" being U c172-sound.xml U c172p-set.xml ?

gilbertohasnofb commented 9 years ago

Yep. Would that solve the conflict?

wlbragg commented 9 years ago

Yes, that sounds right.

wlbragg commented 9 years ago

Is your local branch older than #238 PR?

wlbragg commented 9 years ago

That is why when you get a conflict notice you edit the files that are flagged in conflict. Because technically you should be able to tell what part to keep and what part to discard in the conflict. Have you ever seen or edited one of those conflicts?

gilbertohasnofb commented 9 years ago

Is your local branch older than #238 PR?

No, I re-cloned the whole repository some days ago.

Have you ever seen or edited one of those conflicts?

Not really.

Yes, that sounds right.

I will give it a shot now then.

wlbragg commented 9 years ago

"should be able to tell what part to keep and what part to discard in the conflict" Because you might be ahead of the PR or behind the PR and that makes a difference in what conflict part is discarded. If you are ahead , you may want to keep your version of the conflict, if behind, you may want to keep what is in 238.

wlbragg commented 9 years ago

Sometime if I really can't or don't want to wait for help, I'll reclone a fresh copy of master, make my changes and push that back to github (that is if the changes aren't too extensive.. I have the cpu power speed and bandwidth to allow me to do that in a reasonable amount of time.

wlbragg commented 9 years ago

But then again I guess you trying to work with a PR so that is a bit different.

gilbertohasnofb commented 9 years ago

I really don't know then, and copying the raw data didn't solve it, the conflict is still present...

Because you might be ahead of the PR

How could I be ahead of the PR? I myself never touch those xml files, I only add wav files.

Sometime if I really can't or don't want to wait for help, I'll reclone a fresh copy of master

I do the same when I am at my uni, but at home my internet is rubbish. This repository is quite large nowadays, so I am hoping to solve it somehow else.

wlbragg commented 9 years ago

Open the files that have the conflict and find the conflict, take a look at it and see if you recognize both versions of the conflict.

wlbragg commented 9 years ago

There may be more than one conflict in each file.

gilbertohasnofb commented 9 years ago

Sure, I already checked with a difference checker, it's just some few lines of code per file. But the point is that simply correcting these lines on the files is not solving the conflict...

You know what, I need to do some other stuff that does not involve internet right now, so I will just reclone the whole repository. This is too much headache for me. Thanks anyway for the help!

wlbragg commented 9 years ago

Good luck!

gilbertohasnofb commented 9 years ago

Thanks, with my bandwidth I will need it! :wink:

gilbertohasnofb commented 9 years ago

@wlbragg okay, it took me 2h but cloning is finished and problem is solved. Thanks again!

@onox so the new trim sound is pushed, named trim.wav. It should be really soft, and the sound is loopable. Let me know if we still need some work on these sounds, okay?

onox commented 9 years ago

I did an interactive rebase as I said in https://github.com/Juanvvc/c172p-detailed/issues/238#issuecomment-111710053 and force push to clean up this feature branch a bit, but you might not have understood the consequences of it . So what happens is that your commit tree is something like:

A->B->C->D->E->F->G->H

while mine (and Github) is:

A->B->I->J->K

What you should do in this case is find the most common ancestor, which is in this case commit B. Then you do git reset --hard B and then you do git pull to get commits I, J, and K. That will save you having to do a full clone.

Perhaps I should have added these instructions on the PR page, but I didn't.

onox commented 9 years ago

@gilbertohasnofb I get:

AL Error (sound manager): Invalid Enum at buffer add data
No such buffer!

Could it be because the sound is 24 bit instead of 16 bit? :confused:

onox commented 9 years ago

I've modified c172-sound.xml to use trim.wav, so you can check if the sound is accepted by FG or not.

gilbertohasnofb commented 9 years ago

I did an interactive rebase as I said in #238 (comment) and force push to clean up this feature branch a bit, but you might not have understood the consequences of it

Yeah, I didn't realise it at all :smile but no worries, now everything is okay.

As for your error, I will convert the sound to 16-bit tomorrow and also test your last work.

onox commented 9 years ago

About the nav radios and transponder, why don't we copy them into our project then? Together that's only 439 kb more.

I'll copy the files.

onox commented 9 years ago

@gilbertohasnofb Done.

gilbertohasnofb commented 9 years ago

Great!

gilbertohasnofb commented 9 years ago

Great news, I contacted the authors of the two CC-BY sound files we were using and they authorized the FlightGear project to include them as CC0 (public domain). I updated the Thanks file to reflect this (so now this Thanks file is not a license requirement but only a polite way of thanking who deserves credit and no license conflict will ever be inflicted). Now I have to solve only one issue with a single texture I used as source and then our project will be completely GPL or public domain (meaning that even if that licensing discussion going on in the mailing list decides to completely block CC-BY, we are clear to go).