On Oct 31, 2012, at 10:36 AM, IOhannes m zmoelnig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2012-10-31 15:11, Hans-Christoph Steiner wrote: >> >> >> What about taking it in this direction fully and making it possible >> to encapsulate the entire implementation for a given audio API in a >> single file? Then having it so s_audio.c is never modified. > > in theory it is like that... > in practice it's almost like that: > the entire implementation of a given backend is contained within a > single file. > however, we still have references of the "built-in" audio-APIs in > s_audio.c. > > why? > > well the target platform is Pd-vanilla. > > i assume that it will take some time util Pd-vanilla itself will make > all the "default" audio-backends as loadable modules. > personally i would prefer it that way, but Pd has a history of keeping > a number of functionality "built-in"; e.g. most objects could/should > be loaded a runtime rather than being statically linked into the Pd > binary ... see your attempts with the "vanilla" library) > > so until then all audio-apis that "come with Pd" will continue to be > "built-in". > now all audio-apis have to register themselves, similar to how each > objectclass has to register itself. > if you check the code for how e.g. "metro" gets added, you'll see that > the relevant code is called in metro_setup(), which in turn gets > called by x_time_setup() which in turn gets called by conf_init(), > pd_init(), sys_main(), main(). > the same holds now true for audioapi_oss() (which registers the OSS > API), getting called by audioapi_register(), sys_set_audio_api(),... > > i could have moved the "#ifdef USEAPI_OSS" from s_audio.c to > s_audio_oss.c. > but given that s_audio_oss.c is only compiled with HAVE_OSS is set, it > seemed easier to do it that way.
Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module? .hc _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
