On May 13, 2008, at 9:11 PM, IOhannes m zmölnig wrote: > SourceForge.net wrote: >>> Comment By: Hans-Christoph Steiner (eighthave) >> >> That could work. I don't think this will cover every possibility. I >> think a more straightforward approach would be to handle very special >> hardware setups in the patch rather than the preferences. I think >> the >> preferences should be general things, since you can't really query >> or test >> for failures with the preferences system. > > interesting, i would have done it the other way around: everything but > the hardware should be handled in the patch, as these are the settings > that make the patch load correctly. > the hardware cannot be foreseen by the upstream author, so the user > has > to take care of that (they hopefully do know which hardware they > are using)
I mean if you write a patch that needs special hardware, then you would handle the settings in the patch. I think most people set up their primary hardware to the primary soundcard, then it "just works" with Pd default audio settings. Or at least I do it this way on ALSA and Mac OS X (I only use Windows to test Pd bugs). .hc > > >> >> For the built-in audio, it almost always just works, so specific >> configuration isn't needed. > > well, the only apple machine i have regular access to, has it's > built-in > audio not connected to anything and keyboard/mouse are dislocated from > the machine (separate rooms). > > mfgad.sr > IOhannes > > _______________________________________________ > PD-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev ------------------------------------------------------------------------ ---- If you are not part of the solution, you are part of the problem. _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
