| [AD] Audio addon API / Re: Renaming of functions in kcm_audio addon | 
[ Thread Index | 
Date Index
| More lists.liballeg.org/allegro-developers Archives
] 
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.
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.
Evert