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 PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.