[PD] Reverse Kickstarter Update

Jonathan Wilkes jancsika at yahoo.com
Thu Aug 1 04:46:57 CEST 2013


On 07/31/2013 11:59 AM, Jamie Bullock wrote:
> On 31 Jul 2013, at 16:46, Jonathan Wilkes <jancsika at 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
>




More information about the Pd-list mailing list