PureBasic Forums - English

Posted: **Fri Jul 14, 2006 6:24 pm**

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.

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? :)

Posted: **Fri Jul 14, 2006 6:41 pm**

Will do it

It's AM2:00 here, gotta go bed now, I'll try to figure it out tomorrow.
Most modules are compiled with BM's propertiary compiler, dunno what the difference is

See ya tomorrow, and thanks for helping.

Posted: **Fri Jul 14, 2006 6:58 pm**

yoxola wrote: Most modules are compiled with BM's propertiary compiler, dunno what the difference is :|

Probably, If you send me one of thouse modules (Pub.win32 is quite representative), I'd figure out it's format as I did for v1.12 demo. Thanks in advance. Good night!

Posted: **Fri Jul 14, 2006 7:41 pm**

i try to make it work under BMax 1.20 too but, as you said it, it's a new format. After looking the asm source of the example, BMax want to make a call to __bb_ufmod_ufmod (when using winmm)

Maybe by making a bmx code with "c" import inside ...

Posted: **Sat Jul 15, 2006 5:27 pm**

BMax addon updated @ Source Forge. flaith figured out the differences in v1.20. Now it should work with both v1.12 and v1.20.

Posted: **Sat Jul 15, 2006 6:46 pm**

Thanks, it's working now

It's really magic to have a working xm player for BlitzMax.
(not joke, we took several months, trying to figuring it out

)

How do we change the volume without alter master volume,
that will come handy for games, as the current version is pretty useful now.

Big Thanks!

Posted: **Sat Jul 15, 2006 8:05 pm**

well, change and use PureBasic

Posted: **Sun Jul 16, 2006 2:55 am**

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.

For now, it can be done as follows:

In DirectSound you can use the IDirectSoundBuffer.SetVolume(new_volume) method directly:

Code: Select all

DirectSoundBuffer.SetVolume(0) ' muting

Take in mind the volume scale should be logarithmic (log10) for DirectSound.

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

The scale is linear this time, not logarithmic as in DX. It's recommended to call waveOutGetDevCaps first to ensure this channel supports volume control.

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.

Posted: **Sun Jul 16, 2006 12:36 pm**

Yes, please add native volume control, that'll be very useful.

With volume control, pause/resume, uFmod can be a great game bgm player

Posted: **Thu Jul 20, 2006 3:38 am**

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

Posted: **Thu Jul 20, 2006 5:28 pm**

Amiga5k wrote: Would it be possible to incorporate uFMod directly into future versions of PB

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:

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.

Posted: **Sat Jul 22, 2006 4:14 am**

Quantum wrote:
Amiga5k wrote: Would it be possible to incorporate uFMod directly into future versions of PB
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:

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 problem I'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?

Posted: **Sun Jul 23, 2006 5:03 pm**

uFMOD v1.18 available for download. Win32-specific changes:

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 ;)

Download: http://ufmod.sf.net

Amiga5k

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?

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.

Posted: **Sun Jul 23, 2006 6:44 pm**

ooooooh man, this IS great!

Thanks

Posted: **Sun Jul 23, 2006 6:58 pm**

yoxola wrote:ooooooh man, this IS great!

Thanks

+1

PureBasic Forums - English

uFMOD v1.15 supports PureBasic v3.50 or later

uFMOD 1.18