Patches item #1962700, was opened at 2008-05-12 19:18 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1962700...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: two embedded prefs for Mac: default and override all
Initial Comment: This patch creates two different kinds of embedded org.puredata.pd.plist prefs files on Mac OS X. The first is the default settings that come with Pd-extended.app, the second is a prefs file that overrides all others, so that people can make their own custom apps based on the Pd.app, and be sure that the user's prefs aren't going to override things.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-13 13:06
Message: Logged In: YES user_id=27104 Originator: YES
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.
For the built-in audio, it almost always just works, so specific configuration isn't needed.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-05-13 03:37
Message: Logged In: YES user_id=564396 Originator: NO
hmm, but how should the author of a custom app know about the hardware-settings of the end-user? wouldn't it be better to split the configuration files into machine-dependencies (soundcard,...) and user-dependencies (libs,...) which could then be overridden seperately?
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1962700...
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)
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
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.
Hans-Christoph Steiner wrote:
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.
i think we are not that far appart.
however, i cannot resist to make 2 remarks
1. first, i don't know what you mean by "special hardware". is a multichannel soundcard "special"? is an external soundcard (usb, firewire, pcmcia,...) "special"?
i think that most (though not all) people will use their built-in soundcard (if present) for everyday purposes. but few (though some) people will use their crappy laptop soundcard for a performance...
so if your "application" is just for people to test things out (instead of using it in a "professional" way), i would say you are on the right track. however, in this case i (personally) think too much time has already been spent on the topic.
whoa, all this sounds rather elitist. it is not my intention (nor my self-perception :-)) i am just trying to find a way to do preferences in a re-useable way...
2. if most people set up their "primary hardware to the primary soundcard" and use Pd's default audio settings, then there is no need for other settngs :-) if people have to use the audio-settings (for whatever reasons), then an application should not plainly ignore it. hence my request to split the preferences into hardware and software specific settings.
Or at least I do it this way on ALSA and Mac OS X (I only use Windows to test Pd bugs).
:-)
fgmasdr IOhannes
On May 14, 2008, at 9:40 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
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.
i think we are not that far appart.
however, i cannot resist to make 2 remarks
first, i don't know what you mean by "special hardware". is a multichannel soundcard "special"? is an external soundcard (usb, firewire, pcmcia,...) "special"?
i think that most (though not all) people will use their built-in soundcard (if present) for everyday purposes. but few (though some) people will use their crappy laptop soundcard for a performance...
so if your "application" is just for people to test things out (instead of using it in a "professional" way), i would say you are on the right track. however, in this case i (personally) think too much time has already been spent on the topic.
whoa, all this sounds rather elitist. it is not my intention (nor my self-perception :-)) i am just trying to find a way to do preferences in a re-useable way...
It seems that a good Jack API in Pd would be the best way to handle multi-channel setups that are meant to work on multiple computers. When I use my 6 channel setup, it's with Jack. I can't see any other reasonable way of handling all of the different setup possibilities with multichannel sound cards.
.hc
if most people set up their "primary hardware to the primary soundcard" and use Pd's default audio settings, then there is no need for other settngs :-) if people have to use the audio-settings (for whatever reasons), then an application should not plainly ignore it. hence my request to split the preferences into hardware and software specific settings.
Or at least I do it this way on ALSA and Mac OS X (I only use Windows to test Pd bugs).
:-)
fgmasdr IOhannes
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
Hans-Christoph Steiner wrote:
whoa, all this sounds rather elitist. it is not my intention (nor my self-perception :-)) i am just trying to find a way to do preferences in a re-useable way...
It seems that a good Jack API in Pd would be the best way to handle multi-channel setups that are meant to work on multiple computers. When I use my 6 channel setup, it's with Jack. I can't see any other reasonable way of handling all of the different setup possibilities with multichannel sound cards.
me thinketh that you are trying to solve the users' problems while i am trying to use their solutions.
fgmasdr IOhannes