intfiction.org

As I said, I mean no offense to Damusix. You built it to work the only way that is currently possible: by requesting very rapid timer events and changing the volume at very short intervals. That's horribly inefficient and ugly -- even though there's no alternative! Once this API goes in, you'll be able to make the same features work with a much lower CPU load.

Creating a sound channel with a specific volume is trivial.

The other new API call, lowering the volume over a specified number of milliseconds, poses some difficulties. It's not a feature that SDL_mixer provides. I'd need to use OS timers for that, which would be workable under Windows and Linux but would mean a complete rewrite of the way I handle timers in OS X to avoid clashing with the Glk timer functionality.

OpenAL may offer a way to accomplish the same thing out of the box, but I'm not quite ready to go there.

Given the small number of IF games that use sound and the potential availability of Damusix for the ones that do, I don't welcome the idea of more sound API functions. It's a pile of work with a very small payoff.

I'd like to see an OpenAL implementation rather than a DirectSound one, since this would provide portability. Or better yet, SDL.

An interpreter using SDL for display and sound... This has potential.

Don't Mix_FadeOutMusic(), Mix_FadeInMusic(), Mix_FadeInChannel(), Mix_FadeInChannelTimed() and Mix_FadeOutChannel() do exactly that? I've used them for the timed cross-fade implementation in QTads, and they work OK.

They do allow a timed fade, but not bounded by a specific volume - only to full or zero.

Damusix already does that It does the following: to assign a sound to a channel ...

1) Channel is previously created.
2) Damusix changes the channel volume.
3) Eventually the sound plays.

Damusix stores in its kernel several information of its managed channels, including volume, repetitions, sound notifications, etc. So whenever the channels are initialized with the specified volume at the time of the assignment.

I understand that having a formal Glk call to do this can be optimal, but I want to say that Damusix already does by itself.

Saludos!

EDITED:



OMG. Damusix already does this. Damusix's fades can have arbitrary volumes... 25% to 80%, 100% to 50%, etc. You can even do that after a fade occurs another, producing a lot of fun effects.

See ya!

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/

There's also Mix_RegisterEffect() to do it manually, but I guess this is where it will get hairy as you'd need to modify the sound data directly. Your effects processor would need to modify the amplitude of each waveform chunk it receives, keeping track of where it left off previously. This approach is for the brave though, which is why I never bothered It does produce the best results however.

As long as we're talking about the sound API...

I would like to be able to specify the starting point as an optional parameter for glk_schannel_play_ext. By default, the sound would start at the beginning, otherwise, it would track to the time passed by the parameter. Concomitantly, glk_schannel_stop could return the stopping point, allowing for a sound to be restarted in the same place after stopping (in other words, providing a "pause" functionality).

Another related feature--likely (much?) more work to implement, and not central to anything I'd like to do--would be to allow the notify flag in glk_schannel_play_ext to specify *when* the sound notification event would be fired, e.g. a flag of 0 would request no notification (as it currently does), while -1 could request a notification when the sound finishes playing, while a positive value would indicate the point at which the sound notification should be returned.

--Erik

_________________
Glimmr: Advanced Graphics for I7
blog | download | bug-tracker

Hi Eliuk! I realize that Damusix already does all this. It rocks! I think you should just release it as-is; authors who want to use it can put the documentation through Google Translate or ask usage questions here.

From a philosophical perspective I thought that the motivation behind adding Glk API functions was to enable broadly new capabilities, rather than to make existing features more convenient and accessible. I see that focus slipping here and it's not clear that the benefits to authors outweigh the hassle to library maintainers.

There are many more people creating extensions than working on Glk implementations; if it's territory that extensions can cover, let them cover it.

This thread isn't about Damusix, but I beg indulgence to add:



I agree with Ben--just release it now if the code is ready. People do their best to get by w/o reading documentation anyway! You could try putting the documentation up in wiki format at Google Code or IFWiki; maybe folks will be motivated to contribute to a group-mind translation.

--Erik

_________________
Glimmr: Advanced Graphics for I7
blog | download | bug-tracker