MarkH

Okay, thanks. I wonder if this means I can make a mono sound and that will work differently. Got to be worth a try, anyway.

I am tinkering with the sound library and I can get sounds playing, looping and stopping easily enough. But I am a bit stumped with the volume and position parameters, which have some effect but which don't seem to be doing what I need. Volume, for example, varies the volume somewhat but there doesn't seem to be a huge difference between 0% and 100% and 0% is still quite audible. Also, most importantly for my present purposes the position parameter doesn't seem to let me to play a sound on one channel (left or right) only. I am using 90 or 270 for the position (I have tried other positions) but it seems to mix the sound and merely bias it left or right, even if the WAV file contains a sound playing on the left or right channel only. What I need to be able to do is play a sound unmistakably on one channel or the other and to be able to fade it in and out gradually. I can get the fade in and out with a bit of ingenuity and three separate WAV files - one that fades in, one that can be looped and a third that fades out. (Actually I can do away with the looping one if I make the faded-in one long enough.) For what it's worth, I have written a little program to give me audible cues for the balance ball position. So when the ball drifts out of the middle I get wind noise building from the right or left. It sort of works but the channel separation issue is letting it down. Am I missing anything or do I need to find another way?

Yes, in the interim I've tried reading and writing the axis controls using the offsets and that works as expected. (I only mentioned the PFC offsets as from the HID demo I thought maybe it had to be done that way.) As for why do this in the first place? Well, because I think it's better - and it's how it behaves in real life! For example, if I start up my Twin Otter with the fuel lever in the ON position I should get an engine fire. Currently I can get away with that if I am lax with the checklist. (Which I am.) Anyway, it's just an experiment. It seems worth doing at the moment but once I get it working it may turn out to be less useful than I expect. That seems to be how it works! As a deeper thinker than I am once said, 'We never say all that we expect to be heard as having said, and we often say something quite different from what we intend to be heard as having said. That is, we expect the hearer to do what is technically referred to as “conversational implicature”; to “add” the implicated meanings and respond to them. In this way we are able to use jargon, idioms, figures of speech, and the like.' (I have often wondered if the clumsy phrasing was a deliberate irony :huh:) Thanks for the help.

Yes, that's exactly it. If I load a situation I want FSX to set its switches and axes to match the positions of the real ones in my cockpit. (And no, I shouldn't need to do the axis mapping more than once but I would prefer a generic solution that wouldn't care if I did change something.) Sorry, I don't understand this - send where? Do you mean to write to the FSUIPC offset for the axis? And what is x - what I find at that offset in the first place or what I read from the HID?

Yes, I think that's the sort of thing I had in mind when I talked about doing it 'manually'. I suppose I could write a separate Lua program that does this in the background and arrange for it to run at startup. It could record its mappings in an ini file and it could stop monitoring (and terminate) when it has identified every slider. Well I'll try to say it clearer (and hope it doesn't just come out as longer and less clear!) My joysticks are built around physical sliders and FSX maintains axis data that the positions of those sliders are mapped to. In between is a chain of software that I don't know much about. FSUIPC is somewhere in this chain, and further out are a HID driver and probably other things I cannot name. Knowing what I do about how these things work, that chain is an intricate mechanism of polling loops, timers and interrupts that links the joysticks to FSX in a way that makes the data shadow their movements - almost. That they can get out of step tells me that somewhere along the chain there is at least one link that pushes data to FSX, rather than sending it on demand. If I physically wiggle a joystick, that link notifies FSX and the axis data gets updated. In principle there is a way (perhaps several ways) to poke around in the mechanism and make that push happen without actually wiggling the joystick. Whether there is a practical way to do it is the real question. I had assumed the 'delta' setting on your axis assignment dialog meant that FSUIPC uses a push model to send axis updates to FSX. It would be nice to be able to say 'push now' to FSUIPC.

I have been working on getting FSX to stay in sync with my physical cockpit. For this I am using LINDA and the COM library's HID functions. I have been successful in reading all the button states and then setting up FSX to match my switches. The HID demo program was very helpful in this and by studying it I have taken what I had hoped was the next step, which is to successfully read all the analogue axis data. But now I am stuck. I want to use the axis data to set the appropriate values in FSX to match the current settings (e.g. throttle, prop, mixture) but I am stuck because I don't see a way to identify which HID axis is mapped to which FSX function. As far as I can tell (from the demo) I will need to write data to the PFC axis offsets but to do that I need to know which is which. Is there any way to find this out? Obviously I have the Vendor/Product/Unit ids available but I'm not sure that helps. The only way I can currently see to do this is to manually determine which HID axes match which functions and then hard-code them (or more likely make a table of them in my own ini file). But that seems inelegant and not at all robust. I am not wedded to any particular solution to this so if anyone understands what I'm trying to do and knows another way, please say. I had originally sort of hoped there was a software equivalent to wiggling each axis slightly, so FSX would update through the normal channels, but I think that was a bit optimistic. I would be happy to hear people's ideas on this.