Yeah, It's hard to make a module in a different format without knowing the specs. Where can I find an example of a new format module? BTW, may I suggest continuing this discussion by email or in our public forum (registration not required), because it's not very related to PureBasic? :)yoxola wrote: However the module format was changed for around 3 times till the current release (1.20), and I don't know ho to port it to new version.
uFMOD v1.15 supports PureBasic v3.50 or later
For now, it can be done as follows:yoxola wrote: How do we change the volume without alter master volume,
that will come handy for games, as the current version is pretty useful now.
In DirectSound you can use the IDirectSoundBuffer.SetVolume(new_volume) method directly:
Code: Select all
DirectSoundBuffer.SetVolume(0) ' muting
The DirectSoundBuffer object (instance of IDirectSoundBuffer) is the same you pass to uFMOD_DSPlay*.
There're some more useful methods in DirectSound: SetPan, Stop (for pause/resume). Take a look at dsound.bmx. And if you know C/C++, there're some advanced DX sound effects in VISUAL_C\DIRECTX\PLAY_DS.C.
In WINMM volume control is a bit different. uFMOD_Play* returns the handle of the currently playing channel. Pass it to waveOutSetVolume API function, like this:
Code: Select all
waveOutSetVolume(handle, 0) ' muting
Volume control in Linux is much harder to implement, but we'll add an example some day.
Next release will introduce 2 new optional functions: uFMOD_Pause and uFMOD_Resume (or combine 'em in 1 function) to simplify a bit pausing/resuming and make it crossplatform. Maybe, volume control will be the next planned feature.
Fred & Quantum:
Would it be possible to incorporate uFMod directly into future versions of PB so that we don't have to worry about Midas sound library requirements, dlls and licensing issues? This seems like the perfect fit for PB! (And there are several other things about Midas I never liked...)
Please think it over carefully!
Russell
Would it be possible to incorporate uFMod directly into future versions of PB so that we don't have to worry about Midas sound library requirements, dlls and licensing issues? This seems like the perfect fit for PB! (And there are several other things about Midas I never liked...)
Please think it over carefully!
Russell
*** Diapers and politicians need to be changed...for the same reason! ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
It doesn't depend on Asterix or me, but entirely on PB developers. Personally, I don't mind they doing so, but have to point a couple of cons:Amiga5k wrote: Would it be possible to incorporate uFMod directly into future versions of PB
1. uFMOD updates about once per month, so I guess newer versions whould become available sooner than newer PB releases and people whould have to download uFMOD separately most of the times. BTW, a new release is already packed and waiting for all tests to complete.
2. Although it's OK to use precompiled uFMOD libraries in many applications, sometimes it's worth it recompiling uFMOD from source after using Eff to make it smaller and faster. I'm afraid people whould forget that when using uFMOD already precompiled and incorporated in PB. Not a big issue...
3. There are no plans to support Mac, for now.
Quantum wrote:It doesn't depend on Asterix or me, but entirely on PB developers. Personally, I don't mind they doing so, but have to point a couple of cons:Amiga5k wrote: Would it be possible to incorporate uFMod directly into future versions of PB
1. uFMOD updates about once per month, so I guess newer versions whould become available sooner than newer PB releases and people whould have to download uFMOD separately most of the times. BTW, a new release is already packed and waiting for all tests to complete.
Too many updates is not really somethng I would call a problemI'm sure most of us would be happy with the latest version incorporated into the quarterly PB updates.
2. Although it's OK to use precompiled uFMOD libraries in many applications, sometimes it's worth it recompiling uFMOD from source after using Eff to make it smaller and faster. I'm afraid people whould forget that when using uFMOD already precompiled and incorporated in PB. Not a big issue...
Smaller is excellent, but as-is it is not really that big, so this is not really that big of a deal as you say.
3. There are no plans to support Mac, for now.
Since it is written in assembler, I can see where this might be somewhat of a tricky matter (although the InteliMacs use the same opcodes now!) Maybe someone would be willing to do a Mac port?
*** Diapers and politicians need to be changed...for the same reason! ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
*** Make every vote equal: Abolish the Electoral College ***
*** www.au.org ***
uFMOD 1.18
uFMOD v1.18 available for download. Win32-specific changes:
Download: http://ufmod.sf.net
Amiga5k
Code: Select all
[+] New API functions:
uFMOD_Pause / uFMOD_Resume - crossplatform
pause / resume feature.
uFMOD_SetVolume - crossplatform volume control.
It's OK to use this function before starting
to play an XM, as opposed to platform-
specific volume control used in previous
releases. Volume scale is linear (no need to
deal with logarithms). Platform-specific
volume controls can still be used alone or
in conjunction with uFMOD_SetVolume.
[+] Introducing support for ADPCM compressed XM tracks.
(Modplug Player can be used to compress regular XM
tracks.)
[+] DirectSound uFMOD lib checks for "buffer lost" and
automatically attempts to restore the buffer. So,
it's no need to care about loosing the buffer in
your main app code.
[*] Size 'n speed optimization, as usual ;)
Amiga5k
You are right. Porting an assembler project is a bit hard, especially when dealing with a totally different processor. Since Macs will be IA-based from now on, an uFMOD Mac port will become available someday... I hope so. Maybe, after porting it into KolibriOS and making an x64 version, we'll target MacOS.Since it is written in assembler, I can see where this might be somewhat of a tricky matter (although the InteliMacs use the same opcodes now!) Maybe someone would be willing to do a Mac port?