Sign in to follow this  
rcbarend

module for XML sounds

Recommended Posts

Eugene made the chalange and we are talking about specifying a module that will allow to play sounds in XML gauges. The alpha package is done but still need inputs. How does this works.The package is a module that interfaces XML gauges with direct sound and a program called convert.How to use it:Put the wav that you want to play in the fs sound dir (no more than 8 letters). Run the convert program and put the file name in it (without the .wav). Take a note of the number that the program gives.ReadSoundChar = 1 will prepare the program to read the filename. After reading the file the dll will return a number in this var telling the program what is the wave index number.SoundFile = number. Number is the value returned by the convert program.PlaySound=number. Number is a value greater than 0 returned by the dll in the ReadSoundChar and will tell to the module wich wave to play. Number=1 will tell to play the first wave loaded, number=2 to play the second wave loaded etc. After start playing the dll will reset the value to 0. The sound is kept in memory to prevent stutters.LoopSound=1. will loop the sound started by playsound. =0 will play once. This variable must be set before the playsound.StopSound=number. Stop playing the sound started with PlaySound =number;What I would like are some reviews to the interface (problems that you see with it etc) and brave souls that could make me xml gauges to test it.ThanksJos

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi Jose,I'm willing to do a review of the interface (or even make some test xml gauges). With my "groundhandling" gauges I have quite a good view on potential bottlenecks of such an interface. Especially since I now already use 3 different solutions (Two based on ADF as interface between XML and "C", and a third based on L:Vars).But none does exactly what I would like :-)Potential problems:1. Can you stop a non-repetitive sound before it finishes ?2. Can the XML gauge detect when a non-repetitive sound has finished playing ?3. Does each XML gauge have it's own "C" counterpart with which it communicates ??; if not, how do you ensure that a command given by one XML gauge is not overwritten by another XML gauge BEFORE it's seen by your "C" sound gauge ?? (because you use one L:Var for commands)4. Can you simultaneous start/stop various sounds from the same XML gauge ? Same interface problem as 3.3. and 4 are caused by the fact that you essentially use a "serial" interface to accommodate a "parallel" process of starting/stopping sounds from one or more XML gauges.Just some things that come to mind (which you may or may not have thought about)If you want to discuss it further, you can mail me at:rc.barendregt@planet.nlCheers, Rob Barendregt

Share this post


Link to post
Share on other sites

PMFJI, but if you truly want a "Universal" C gauge that will allow for infinite flexibility, would not an easier approach be to allow the gauge programmer to create a text list containing the sound.wav filenames, and store it in the current a/c's panel folder?You could even allow for reading in the number of L:vars to create by specifying the number needed as the first entry in the file, which could be used to set the "index number" in "for" or "while" loops. The second entry in the file could set the relative path to where he wants to store the .wav files. The developer could create a text file something like this:5 //number of .wav files defined../Sounds/MY_Project //relative path to .wav file locationclickpushboingsplatbounceSomething like this schema would have the benefit of allowing maximum flexibility, and would totally eliminate the issues of "conflict" with other users of such a gauge as enumerated by Rob... :)Another approach would be similar to the above, but allow the programmer to pass the name of the .dat file (and even the path) as the "fifth parameter" in the panel.cfg entry:gauge00=XML_Sound!XML_Sound, 0,0,0,0,Sounds/MyCustomSoundFileThese are just some thoughts from mine and Doug's development process for a "Universal File I/O" gauge module we're developing, which will allow any programmer of C -OR- XML gauges to read/write a data file to hard drive, without having to write their own routines. :)

Share this post


Link to post
Share on other sites

I thought about the ini approach. The problem was:If there is one ini only them when using more than 1 XML gauge there is the need to merge the ini.If there is one ini per gauge then there is the need to pass to the module the ini name, so instead of passing the ini name the wav name gives an easier solution for end user.Thanks for the inputJos

Share this post


Link to post
Share on other sites

Great questions. Some I had some ideas other I don't. Almost all of them could be solved by implementing a handshake or mutex approach to the interface. My doubt is: Is that really needed? My biggest problem right now is to see how the XML number is implemented. Tried the cast to _int64 and FLOAT64 and neither give the 8 bytes translation. The first one only translates the first 4 bytes. The last doesn't work, it seems the mantissa and expoent in FLOAT64 and number don't follow the same enconding).ThanksJos

Share this post


Link to post
Share on other sites

Hi Jose,"" My doubt is: Is that really needed? ""Well, for my groundhandling gauges such a handshake protocol it IS needed :-)Iow: the "C" gauge should indicate that it is ready to receive a new command.Doug Dawson made a solution based on a single L:Var, for which I made an XML "soundserver" that acts as a synchroniser for all other xml gauges (by delaying a requested sound untill the ""C" gauge has read/processed a previous command). So the synchronisation (= semaphore) is solved in one single XML gauge..But I do agree with Bill.If your intention is to create one "super" xml soundserver that solves all requirements, the idea of an .ini file that you can specify in the panel.cfg gauge definition is the best way to go.And, of course, allow for multiple instances of the soundserver to be loaded, each with there own L:var names for communication, to ensure designer-independability. E.g by reading the L:Var names also from the .ini file, or derive them from the "C" soundserver gauge name.But I guess creating such a "super" xmlsound server goes a bit beyond your intentions ??? :-)Cheers, Rob SUGGESTION: Maybe you should teamup with Bill and Doug; bringing all this knowhow together usually gives a better (and faster) result :-)And maybe include me for the XML side of it, since I've got a pretty good idea (with the experiance and "problems" I had with my sound-wise very complex groundhandling gauges) on what such a "super" XMLsound server gauge should do ..

Share this post


Link to post
Share on other sites

I have some code "lying "around allowing C gauges to play an arbatrary number of wav files. Anyone interested? Just some sample from the DirectX SDk with modifications. A C gauge as soundserver that has an ini like this:[soundset1]L_Var_name1="somesound.wav"L_Var_name2="someothersound.wav"[soundset2]L_Var_name1="someothersoundset_sound.wav"L_Var_name2="someothersoundset_someothersound.wav"and a panel.cfg syntax likegaugeNN=soundserv!soundserv,XX,YY,,,sound_set1and for another aircraft:gaugeNN=soundserv!soundserv,XX,YY,,,sound_set2should be easy. Or the fifth parmater is the ini name itself.I still plan to investigate the possibility to establish something like the "C:xxx:yyy" syntax from the GPS, something like e.g "'soundname' (>C:SoundServ:Playsound)"in a C-DLL but didn't get far by now.Arne Bartels

Share this post


Link to post
Share on other sites

Hi Arne,I would be very interested in the sample code you describeThanks.Doug Dawsondouglassdawson at netscape dot net

Share this post


Link to post
Share on other sites

Well well,It good to see all those knowledgable designers reacting in this thread ....LOLAnd Doug/Bill, the ability to read/write data to/from an .ini file directly into an XML gauge would really be a great function.I already have developped a number of gauges that should be configured for a specific aircraft. Now, if these configuration parameters could be specified in an .ini file instead of the gauge itself, it would save users to do a cumbersome edit of the XML gauge.Cheers, ROb

Share this post


Link to post
Share on other sites

I have programmed a C++ SoundServer gauge for a project, that communicates with the XML gauges, and use the 5th parameter from the panel.cfg to define the project name, number of single sounds and number of looped sounds to load and play. In this version of the gauge 60 sounds are possible, and you can use as many single or looped sounds as you want. Example from the panel.cfg: gaugexx=SoundServer!PlaySound, 10,10,25,25,TEST 6 5 would mean: TEST ist the project name, 6 single sounds and 5 looped sounds will be initialized.In the XML gauge you have to use (L:TEST_plsnd01s,number) to play single sound 01, and (L:TEST_plsnd01l,number) for looped sound 01. So PROJECTNAME_plsndXXs is for the single sounds, and PROJECTNAME_plsndXXl for the looped sounds. The SoundServer gauge looks for the wav files in the Sound folder, and the wav files have to look like TEST_plsnd01l.wav for single sound 01 and TEST_plsnd01s.wav for looped sound 01. So PROJECTNAME_plsndXXs.wav is for the single sounds, and PROJECTNAME_plsndXXl.wav for the looped sounds. Chris Koegler

Share this post


Link to post
Share on other sites

Rob,How many sounds do you need to initiate on the same schedule cycle? I could probably modify the existing gauge to read a number L:Vars on each cycle, with each one triggering a sound. This would give some degree of parallel communications without a big change in the existing code.I don't know that we will ever get to the point of a single guage that does everything, but I do like the idea of creating a more flexible solution than we have now.Doug

Share this post


Link to post
Share on other sites

As I told by E-Mail my intention is not to create a universal server. If there are persons developing one server I believe that is a waste of time to do the same. Anyway: This is the code it could help someone. The DirectSound functions are available in AVSIM library under my name:UINT_PTR TimerBridge;int index=0;char WaveStringVector [90] [40];VOID CALLBACK TimerBridgeCallBack(HWND hwnd, UINT uMsg,UINT_PTR idEvent, DWORD dwTime){ ID MyID; FLOAT64 PlaySound,StopSound,PlaySoundLoop; __int64 SoundFile; char *WaveStringTemp; char WaveString [100]; BOOL Found=0; int i; MyID = check_named_variable("PlaySound"); if (MyID>0) { PlaySound = get_named_variable_value(MyID); if (PlaySound) { MyID = check_named_variable("SoundFile"); if (MyID>0) { SoundFile = (__int64)get_named_variable_value(MyID); WaveStringTemp=(char*)&SoundFile; strcpy (WaveString,"sound"); strncat (WaveString,WaveStringTemp,8); strcat (WaveString,".wav"); for (i=0;i0) { PlaySoundLoop = get_named_variable_value(MyID); if (PlaySoundLoop) { MyID = check_named_variable("SoundFile"); if (MyID>0) { SoundFile = (__int64)get_named_variable_value(MyID); WaveStringTemp=(char*)&SoundFile; strcpy (WaveString,"sound"); strncat (WaveString,WaveStringTemp,8); strcat (WaveString,".wav"); for (i=0;i0) { StopSound = get_named_variable_value(MyID); if (StopSound) { MyID = check_named_variable("SoundFile"); if (MyID>0) { SoundFile = (__int64)get_named_variable_value(MyID); WaveStringTemp=(char*)&SoundFile; strcpy (WaveString,"sound"); strncat (WaveString,WaveStringTemp,8); strcat (WaveString,".wav"); for (i=0;i

Share this post


Link to post
Share on other sites

Just a new(?) idea while I was cooking my meal: instead of using L:vars directly to control soundplaying it is also possible to use XML-like coding to be evaluated directly by the C gauge via the execute_calculator_code() function. This would give even more flexibility in sound coding. L:vars would be a part of it.Something like:[sound1]soundname="soundanysound.wav"condition="(A:anyvar,number) 20 >"loop=1panning=0volume=0....[sound2]soundname="soundothersound.wav"condition="(L:myvar,number)"loop=1panning=0volume=0Arne Bartels

Share this post


Link to post
Share on other sites

Gentlemen,I spent a few hours today on the train :-) no air connection, I was thinking about this soundgauge and I came to similar conclusions that Jos

Share this post


Link to post
Share on other sites

Hi Chris,Would that be the same gauge that Claudio is using in his TU144 ??If so: I'm currently testing this TU144, and I am in heavy correspondance with Claudio, o.a. about this sound gauge.Claudio is using this for all his sounds, including a modified version of my groundhandling gauges (using this sound gauge).Unfortunately I discovered (with appear to be) some problems with this gauge. If you contact Claudio, he has all the info ..Cheers, ROb Barendregt

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this