Re: [AD] Audio addon API / Re: Renaming of functions in kcm_audio addon

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On November 26, 2008, Evert Glebbeek wrote:
> On 26-Nov-08, at 8:55 PM, Thomas Fjellstrom wrote:
> > Ugh, I hope not. The good thing about allegro 5 is all of the cruft
> > can be
> > expunged.
>
> Yeah, but someone designed the API from scratch the way it is, he must
> have had a reason to do it the way he did.
> It does look like a bit more hassle, though some clever regexps should
> be able to do it.

Eh, api design and naming is all mostly down to preference, at least in this 
case. Changing the particular names, so long as they mean the same basic thing 
won't change a darn thing and will make it fit in better with the rest of 
allegro.

> That doesn't really solve the major issue with the audio API at the
> moment though: it's too damn complicated if you just want to load and
> play a sample.
>
> I guess it's possible to have Allegro allocate a default mixer and a
> default voice that it can manage behind your back if you ask it to.
> I'm also reasonably sure we can provide a function that combines
> al_load_sample() and al_set_sample_data() (aside: al_load_sample() is
> misleading and should be called al_load_sample_data()).
>
> How about the following:
>
> 1. Rename al_load_sample -> al_load_sample_data()
> 2. Provide ALLEGRO_SAMPLE *al_load_sample(char * filename), which
> combines  al_create_sample(), al_load_sample_data() and
> al_set_sample_data()
> 3. If al_play_sample() is called on a sample that has not been
> attached to a mixer, Allegro attaches it to the default mixer. If the
> default mixer hasn't been created yet, it is created (along with the
> default voice). These latter two should maybe use thread local storage.
>
> This has the advantage of making the "simple common case" simple and
> easy while leaving complete freedom to the advanced user who wants
> more control over voices and mixers. Thoughts?
> There is one caveat: al_destroy_sample() should also destroy the
> datastream attached it if it is created by al_load_sample() proposed
> above; maybe this can be kept track of by an (internal) flag? I have
> to admit I'm not sure I like the extra level of interconnectedness
> that implies.

Maybe it would be better to have a higher level simple sound player api that 
wraps around kcm instead?

> Evert
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx