On Jul 31, 2013, at 6:00 AM, pd-list-request@iem.at wrote:
At the very least, I think "Connect" is a bit confusing. It implies that there can be an unconnected state when the main purpose of the dialog is managing which things are connected. Maybe "Apply Settings", "Update Connection Settings", or even "Update", etc is better.
Ok. I think "Update" or "Update Connection Settings" is probably best.
When would a user want to change a setting but not "apply"? Surely you want the actual settings in the backend to always reflect the current state of the preferences dialog and vice versa.
best,
Jamie
I think you misunderstand me. Of course the changes should be applied, I'm just saying I thought the "Connect" button label was a little confusing. "Apply" would work as well in this case, but I think something like "Update Connection Settings" etc is more verbose, but also more clear.
What I meant by not having an apply button a few posts ago, was that in most Mac apps you don't have a 2 step process to change settings aka change then apply. When you change a setting that's it, it's both changed and updated at the same time. I do agree with Jonathan that, in this case, it makes sense to have a 2 step process. I was mainly pointing out I thought the labeling could be more clear.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 31 Jul 2013, at 16:11, Dan Wilcox danomatika@gmail.com wrote:
On Jul 31, 2013, at 6:00 AM, pd-list-request@iem.at wrote:
At the very least, I think "Connect" is a bit confusing. It implies that there can be an unconnected state when the main purpose of the dialog is managing which things are connected. Maybe "Apply Settings", "Update Connection Settings", or even "Update", etc is better.
Ok. I think "Update" or "Update Connection Settings" is probably best.
When would a user want to change a setting but not "apply"? Surely you want the actual settings in the backend to always reflect the current state of the preferences dialog and vice versa.
best,
Jamie
I think you misunderstand me. Of course the changes should be applied, I'm just saying I thought the "Connect" button label was a little confusing. "Apply" would work as well in this case, but I think something like "Update Connection Settings" etc is more verbose, but also more clear.
What I meant by not having an apply button a few posts ago, was that in most Mac apps you don't have a 2 step process to change settings aka change then apply. When you change a setting that's it, it's both changed and updated at the same time. I do agree with Jonathan that, in this case, it makes sense to have a 2 step process. I was mainly pointing out I thought the labeling could be more clear.
Actually, I don't think I expressed myself very well as I was arguing the opposite. I think the settings should take effect immediately and there shouldn't be an "apply" or "connect" or anything button — you just change a setting and that's it — done!
Hence my question about when you would want to "not apply" the settings.
I can't find any other application on my Mac that has an "apply" button in the audio prefs dialog, and FWIW, in Integra Live we managed to create an audio prefs without an apply step, based on Pd using IOhannes' [mediasettings] externals, so it's definitely possible.
best,
Jamie
On Jul 31, 2013, at 11:22 AM, Jamie Bullock jamie@jamiebullock.com wrote:
On 31 Jul 2013, at 16:11, Dan Wilcox danomatika@gmail.com wrote:
On Jul 31, 2013, at 6:00 AM, pd-list-request@iem.at wrote:
At the very least, I think "Connect" is a bit confusing. It implies that there can be an unconnected state when the main purpose of the dialog is managing which things are connected. Maybe "Apply Settings", "Update Connection Settings", or even "Update", etc is better.
Ok. I think "Update" or "Update Connection Settings" is probably best.
When would a user want to change a setting but not "apply"? Surely you want the actual settings in the backend to always reflect the current state of the preferences dialog and vice versa.
best,
Jamie
I think you misunderstand me. Of course the changes should be applied, I'm just saying I thought the "Connect" button label was a little confusing. "Apply" would work as well in this case, but I think something like "Update Connection Settings" etc is more verbose, but also more clear.
What I meant by not having an apply button a few posts ago, was that in most Mac apps you don't have a 2 step process to change settings aka change then apply. When you change a setting that's it, it's both changed and updated at the same time. I do agree with Jonathan that, in this case, it makes sense to have a 2 step process. I was mainly pointing out I thought the labeling could be more clear.
Actually, I don't think I expressed myself very well as I was arguing the opposite. I think the settings should take effect immediately and there shouldn't be an "apply" or "connect" or anything button — you just change a setting and that's it — done!
Hence my question about when you would want to "not apply" the settings.
I can't find any other application on my Mac that has an "apply" button in the audio prefs dialog, and FWIW, in Integra Live we managed to create an audio prefs without an apply step, based on Pd using IOhannes' [mediasettings] externals, so it's definitely possible.
Ah ok. Then yeah, we both agree. The issue then is really about being cross platform. Windows and Linux use the change/apply metaphor, so I figured it probably doesn't make sense to ask Jonathan to code a separate Mac-only dialog.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 07/31/2013 11:22 AM, Jamie Bullock wrote:
On 31 Jul 2013, at 16:11, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
On Jul 31, 2013, at 6:00 AM, pd-list-request@iem.at mailto:pd-list-request@iem.at wrote:
At the very least, I think "Connect" is a bit confusing. It implies that there can be an unconnected state when the main purpose of the dialog is managing which things are connected. Maybe "Apply Settings", "Update Connection Settings", or even "Update", etc is better.
Ok. I think "Update" or "Update Connection Settings" is probably best.
When would a user want to change a setting but not "apply"? Surely you want the actual settings in the backend to always reflect the current state of the preferences dialog and vice versa.
best,
Jamie
I think you misunderstand me. Of course the changes should be applied, I'm just saying I thought the "Connect" button label was a little confusing. "Apply" would work as well in this case, but I think something like "Update Connection Settings" etc is more verbose, but also more clear.
What I meant by not having an apply button a few posts ago, was that in most Mac apps you don't have a 2 step process to change settings aka change then apply. When you change a setting that's it, it's both changed and updated at the same time. I do agree with Jonathan that, in this case, it makes sense to have a 2 step process. I was mainly pointing out I thought the labeling could be more clear.
Actually, I don't think I expressed myself very well as I was arguing the opposite. I think the settings should take effect immediately and there shouldn't be an "apply" or "connect" or anything button --- you just change a setting and that's it --- done!
Hence my question about when you would want to "not apply" the settings.
I can't find any other application on my Mac that has an "apply" button in the audio prefs dialog, and FWIW, in Integra Live we managed to create an audio prefs without an apply step, based on Pd using IOhannes' [mediasettings] externals, so it's definitely possible.
My question: are all current (and imaginable future) audio APIs able to handle quick changes to the setttings? Say, if a user toggles "Use Callbacks" three times within 500ms and Pd tries to connect to ALSA each time, does ALSA handle that gracefully? (Or whatever backend-- I can't remember if ALSA has that option available atm.)
-Jonathan
best,
Jamie
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 31 Jul 2013, at 16:46, Jonathan Wilkes jancsika@yahoo.com wrote:
Actually, I don't think I expressed myself very well as I was arguing the opposite. I think the settings should take effect immediately and there shouldn't be an "apply" or "connect" or anything button — you just change a setting and that's it — done!
Hence my question about when you would want to "not apply" the settings.
I can't find any other application on my Mac that has an "apply" button in the audio prefs dialog, and FWIW, in Integra Live we managed to create an audio prefs without an apply step, based on Pd using IOhannes' [mediasettings] externals, so it's definitely possible.
My question: are all current (and imaginable future) audio APIs able to handle quick changes to the setttings? Say, if a user toggles "Use Callbacks" three times within 500ms and Pd tries to connect to ALSA each time, does ALSA handle that gracefully? (Or whatever backend-- I can't remember if ALSA has that option available atm.)
I think that's a separate issue to whether or not you have an apply button. That is, you could have an apply button, but still be in a situation where the user can change state faster than the backend can respond. In any case, I think adding a UI component the purpose of which is to throttle user input is a bad idea. I don't want to be slowed down ;)
I think you should design what you think is the best UI for humans, and then figure out how to make the business logic robust enough to handle problematic cases like the one you describe above as and when they arise.
Just my 2¢
All best,
Jamie
On 2013-07-31 11:59, Jamie Bullock wrote:
On 31 Jul 2013, at 16:46, Jonathan Wilkes jancsika@yahoo.com wrote:
Actually, I don't think I expressed myself very well as I was arguing the opposite. I think the settings should take effect immediately and there shouldn't be an "apply" or "connect" or anything button — you just change a setting and that's it — done!
Hence my question about when you would want to "not apply" the settings.
I can't find any other application on my Mac that has an "apply" button in the audio prefs dialog, and FWIW, in Integra Live we managed to create an audio prefs without an apply step, based on Pd using IOhannes' [mediasettings] externals, so it's definitely possible.
My question: are all current (and imaginable future) audio APIs able to handle quick changes to the setttings? Say, if a user toggles "Use Callbacks" three times within 500ms and Pd tries to connect to ALSA each time, does ALSA handle that gracefully? (Or whatever backend-- I can't remember if ALSA has that option available atm.)
I think that's a separate issue to whether or not you have an apply button. That is, you could have an apply button, but still be in a situation where the user can change state faster than the backend can respond. In any case, I think adding a UI component the purpose of which is to throttle user input is a bad idea. I don't want to be slowed down ;)
I think you should design what you think is the best UI for humans, and then figure out how to make the business logic robust enough to handle problematic cases like the one you describe above as and when they arise.
What if someone wants to change two or more settings without having them activated until all is correct? On the Mac network settings you have an "apply" button so you can change multiple things without getting stupid error messages because it's only half set up...
Martin
On 31 Jul 2013, at 17:07, Martin Peach martin.peach@sympatico.ca wrote:
I think you should design what you think is the best UI for humans, and then figure out how to make the business logic robust enough to handle problematic cases like the one you describe above as and when they arise.
What if someone wants to change two or more settings without having them activated until all is correct? On the Mac network settings you have an "apply" button so you can change multiple things without getting stupid error messages because it's only half set up...
That makes sense (kind of) for Network Settings because there's a degree of mutual interdependence between the settings — although I'd still prefer no "apply" (iOS doesn't have one for example).
But in the case of audio / MIDI prefs the settings are independent once you've selected driver and device, so users explicitly wanting _not_ to apply a setting immediately seems like an unlikely corner case to me.
Jamie
Hi List, Here is the first stab at a nearly completed set of tools with a nearly standard interface for finding the attributes of pd's global settings, canvas state, and object classes. When I say "nearly complete" I mean I've completed just about everything I set out to implement at the beginning of the "reverse kickstarter". There is certainly room for adding more features-- like the programmatic equivalent of the "find" dialog.
Right now each class posts a message when loaded about what its stable methods are. These are currently a small subset of what I've implemented-- mainly things I find fairly trivial. For the others, I'd like to get more feedback from people before calling them "stable"-- whether they seem to work well, if they have bugs, and if there's a cleaner way to implement them.
Then I'll go through a few more revisions and hopefully remove the "stable" messages once everything looks good.
Some points:
- there is a discrepancy between what is a class and what can be created inside an
object box. This will become apparent when you try to do [args(---[classinfo] for things like canvas and message. I'm not exactly sure how to "get at" the arguments for these objects. Pdobviously accesses them but I don't know how.
- I can probably add a bang method to [classinfo] that merely checks for existence.
- It would probably be nice if [classinfo] could output a list of all loaded classes. That is
very similar to iterating through [classinfo objectmaker], but for the reason outlined it's not exactly the same.
- currently, [methods(---[classinfo foo] only lists the non-standard methods. I.e., it doesn't
include float, bang, pointer, list, etc. Not sure if those should just be separate methods like [bangmethod(---[classinfo], or if they should be include at the beginning of the method list.
- I added [pi(---[pdinfo] because I always forget its value, and it allows consistent precision
between saving and loading a patch. (The implementation is also forward compatible with pd-64, if I did my copy/pasting correctly...)
- Probably should add a method to [pdinfo] to get the operating system name.
That's about it. I don't have demo builds for these-- only patches to pd-0.45. But it should apply equally well to 0.44 and pd-l2ork. Regardless you can get a sense of the interface from opening info-test.pd.
As always, donations of rice and beans are appreciated!
On 07/31/2013 11:59 AM, Jamie Bullock wrote:
On 31 Jul 2013, at 16:46, Jonathan Wilkes jancsika@yahoo.com wrote:
Actually, I don't think I expressed myself very well as I was arguing the opposite. I think the settings should take effect immediately and there shouldn't be an "apply" or "connect" or anything button — you just change a setting and that's it — done!
Hence my question about when you would want to "not apply" the settings.
I can't find any other application on my Mac that has an "apply" button in the audio prefs dialog, and FWIW, in Integra Live we managed to create an audio prefs without an apply step, based on Pd using IOhannes' [mediasettings] externals, so it's definitely possible.
My question: are all current (and imaginable future) audio APIs able to handle quick changes to the setttings? Say, if a user toggles "Use Callbacks" three times within 500ms and Pd tries to connect to ALSA each time, does ALSA handle that gracefully? (Or whatever backend-- I can't remember if ALSA has that option available atm.)
I think that's a separate issue to whether or not you have an apply button. That is, you could have an apply button, but still be in a situation where the user can change state faster than the backend can respond. In any case, I think adding a UI component the purpose of which is to throttle user input is a bad idea. I don't want to be slowed down ;)
I think you should design what you think is the best UI for humans, and then figure out how to make the business logic robust enough to handle problematic cases like the one you describe above as and when they arise.
One thing I'm not crazy about is that when you get rid of the "Connect" button, or whatever we call it, I then have to make the text entry widgets (e.g., sample rate) reconnect audio when the entry _loses_ focus. I've never liked that about instantiating Pd objects (for example, the more objects in the patch the more anxious I get about finding empty canvas spaces to click for instantiation). Pd patching solves this by also instantiating with ctrl-enter so there's visual feedback of the dashed line changing to solid (as well as rectangle bgcolor changing and xlets appearing). But with a tk entry widget if I bind to the enter/return key I don't get visual feedback that the audio reconnection has occurred.
This usually isn't a problem on most of the UIs I tend to use-- GNU/Linux and Windows usually have an "Apply" type button, and text entries on webpages typically post the form on clicking enter so you get visual feedback there. The OSX HIG has nothing to say on the matter, or I can't find it if it does. If OSX folks are used to text entry values updating upon losing focus I can revise the dialog to do that.
Bigger than the "Apply" issue: I think I need to add a "Refresh" button for the API because AFAICT pd core does not update the GUI when new devices are added. Currently you can just select the API again to trigger an update, but I'd like to make it more obvious to the user that core pd doesn't report hardware changes unless the GUi asks about them.
-Jonathan
Just my 2¢
All best,
Jamie
Hi List, More Pd Preferences Dialog improvements:
- color preset object names lined up vertically
- improved colorchooser on Windows
- better placement of audio and midi options
- multi-device checkbutton for simpler UI
- multi-device greyed out if hardware can't handle do it (thought I
already had this, but it was buggy)
- removed code that's no longer used
- added pd extended color scheme
- more consistent padding
- help patches open on all platforms
Just download pdprefs[Your-Platform-Name-Here] from: http://puredata.info/Members/jancsika
Bonus:
- includes [canvasinfo], [pdinfo], and [classinfo]. These are still a
work in progress, but you can send each a bang to see what attributes are there. (For [classinfo] give it the classname of an object as an arg.) Apropos of the thread about finding the directory of the pd executable, just do: [dir( | [pdinfo] | [print]
and you should give you an honest answer. :)
Some things that I didn't change:
- still an old prefs menu option on Windows and GNU/Linux in Vanilla
that I didn't remove
- didn't fix the labelframe fonts
- haven't hooked into routine to save gui prefs yet (but audio and midi
prefs should save on "Applying"
- haven't looked into the MIDI bug, but I am protecting against it
throwing a tcl error
- still have an "Apply Settings" button that doesn't follow OSX HIG
Advice needed: The gui prefs are rather static. How can I make it so a gui-plugin or gui object class can register one or more of its visual aspects to appear in the list so the user (or a preset) can change it globally?
Feedback much appreciated!
Finally, if you like the work please feel free to throw some rice and beans my way: https://jwilkes.nfshost.com/donations.php
Best, Jonathan
-
Dan Wilcox -
Jamie Bullock -
Jonathan Wilkes -
Martin Peach