Two things from me:
missing a "Pd-extended" theme aka grey filled boxes
the Apple interface guidelines generally frown on "Apply" buttons like the "Connect" button in the audio/midi dialogs. The expected behavior is that you also connect when you select the device in the drop down, the idea being you don't require 2 steps. At least that's how I would do it. It's a niggle, but thought I'd throw it in.
Oh and in case my poorly formatted last email didn't get through, your donations page is down ...
On Jul 30, 2013, at 6:00 AM, pd-list-request@iem.at wrote:
From: Jonathan Wilkes jancsika@yahoo.com Subject: Re: [PD] Reverse Kickstarter Update Date: July 29, 2013 9:47:15 PM EDT To: pd-list@iem.at
Ok, with Dan's help I've now got a quick demo of the dialog preferences for OSX (intel): http://puredata.info/Members/jancsika/Pd-with-prefs-0.43.zip/view?searchterm...
Turns out the ability to build for ppc arch is no longer supported in recent versions of XCode (if I understand it correctly).
I guess I built without support for any other audio APIs, so the dropdown is permanently empty which is a little weird. Also you need at least tcl/tk 8.5 on your system. But other than that it should work.
If you try it out then me some feedback on the preferences dialog.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 07/30/2013 01:22 PM, Dan Wilcox wrote:
Two things from me:
missing a "Pd-extended" theme aka grey filled boxes
the Apple interface guidelines generally frown on "Apply" buttons
like the "Connect" button in the audio/midi dialogs. The expected behavior is that you also connect when you select the device in the drop down, the idea being you don't require 2 steps. At least that's how I would do it. It's a niggle, but thought I'd throw it in.
Oh and in case my poorly formatted last email didn't get through, your donations page is down ...
Oh no! I tested the link in my browser and somehow left a typo in the email. My host is Nearly Free Speech-- the actual address is:
https://jwilkes.nfshost.com/donations.php
There's also a link to "donate" from http://www.jonathanwilkes.net
So yeah, ssl has its problems, _especially_ when you type your url wrong in the first place! Thanks for catching that.
-Jonathan
On Jul 30, 2013, at 6:00 AM, pd-list-request@iem.at mailto:pd-list-request@iem.at wrote:
*From:*Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> *Subject:**Re: [PD] Reverse Kickstarter Update* *Date:*July 29, 2013 9:47:15 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at
Ok, with Dan's help I've now got a quick demo of the dialog preferences for OSX (intel): http://puredata.info/Members/jancsika/Pd-with-prefs-0.43.zip/view?searchterm...
Turns out the ability to build for ppc arch is no longer supported in recent versions of XCode (if I understand it correctly).
I guess I built without support for any other audio APIs, so the dropdown is permanently empty which is a little weird. Also you need at least tcl/tk 8.5 on your system. But other than that it should work.
If you try it out then me some feedback on the preferences dialog.
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On 07/30/2013 01:22 PM, Dan Wilcox wrote:
Two things from me:
- missing a "Pd-extended" theme aka grey filled boxes
Ah yes, forgot that one.
- the Apple interface guidelines generally frown on "Apply" buttons
like the "Connect" button in the audio/midi dialogs. The expected behavior is that you also connect when you select the device in the drop down, the idea being you don't require 2 steps. At least that's how I would do it. It's a niggle, but thought I'd throw it in.
But then what about the blocksize, samplerate, and callbacks? If those don't immediately update then the user would have to switch devs to get them to update. If they immediately update then the user would need to press <tab> or click somewhere to make the text entry lose focus. Both of those seem problematic, but if there's an Apple-like HIG solution I'll try to implement it.
-Jonathan
Oh and in case my poorly formatted last email didn't get through, your donations page is down ...
On Jul 30, 2013, at 6:00 AM, pd-list-request@iem.at mailto:pd-list-request@iem.at wrote:
*From:*Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> *Subject:**Re: [PD] Reverse Kickstarter Update* *Date:*July 29, 2013 9:47:15 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at
Ok, with Dan's help I've now got a quick demo of the dialog preferences for OSX (intel): http://puredata.info/Members/jancsika/Pd-with-prefs-0.43.zip/view?searchterm...
Turns out the ability to build for ppc arch is no longer supported in recent versions of XCode (if I understand it correctly).
I guess I built without support for any other audio APIs, so the dropdown is permanently empty which is a little weird. Also you need at least tcl/tk 8.5 on your system. But other than that it should work.
If you try it out then me some feedback on the preferences dialog.
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On Jul 30, 2013, at 2:55 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
- the Apple interface guidelines generally frown on "Apply" buttons like the "Connect" button in the audio/midi dialogs. The expected behavior is that you also connect when you select the device in the drop down, the idea being you don't require 2 steps. At least that's how I would do it. It's a niggle, but thought I'd throw it in.
But then what about the blocksize, samplerate, and callbacks? If those don't immediately update then the user would have to switch devs to get them to update. If they immediately update then the user would need to press <tab> or click somewhere to make the text entry lose focus. Both of those seem problematic, but if there's an Apple-like HIG solution I'll try to implement it.
-Jonathan
Yeah, as I said, it's a niggle and more Mac specific but you do it this way, for instance, in the GUI pane.
The Apply button concept is more firmly entrenched on the other desktops. I really only understood that after writing a Mac-only app and trying to make it work like the other native apps. There are certain situations where you need to start and stop things which does have a separate button. In some cases, certain options are disabled (greyed out / deactivated) when changing them has no effect and deactivated based on another control, say starting/stopping some background process.
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 a few more now that I'm looking more closely:
the MIDI channels text box should probably be filled by default aka "16". Better yet, maybe it should be a drop down box? Also, we weren't able to set the number of channels per device in the old Midi settings dialog? Does this mean we can split up channels now? Say use two devices but give them only 8 each? If we can't, then maybe you don't need this text box.
in the MIDI dialog pane, I get an error when I switch to Multiple devices then back again: can't read "::midi_inchan2": no such variable
in the Audio dialog pane, you could shorten "msec" to "ms" IMO, and I would add some text to explain what "Use callbacks" and "Delay" mean and why there's a setting for them. Everything else makes sense really, but those always bothered me.
I wish the API dropdown box + "Number of devices" button was centered like the content below it
The toggle nature of the "Use single/multiples devices" never made sense to me. IMO is should really be a toggle button: Use multiple devices? [x] Better yet, there wouldn't need to be a direct control if there was a [+] [-] mechanism in the device section itself. The option would be implied: if you are only using 1 device then yeah "Using single device", as soon as you add a second one, then "Using multiple devices". This makes sense for both
Audio and Midi. I know this is probably more work on the GUI side, but I thought I'd bring it up from a UI point of view.in the GUI dialog pane, I'd put the color swatch buttons first, then the labels. This way they'd be aligned to the left better.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 07/30/2013 03:16 PM, Dan Wilcox wrote:
On Jul 30, 2013, at 2:55 PM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
- the Apple interface guidelines generally frown on "Apply" buttons
like the "Connect" button in the audio/midi dialogs. The expected behavior is that you also connect when you select the device in the drop down, the idea being you don't require 2 steps. At least that's how I would do it. It's a niggle, but thought I'd throw it in.
But then what about the blocksize, samplerate, and callbacks? If those don't immediately update then the user would have to switch devs to get them to update. If they immediately update then the user would need to press <tab> or click somewhere to make the text entry lose focus. Both of those seem problematic, but if there's an Apple-like HIG solution I'll try to implement it.
-Jonathan
Yeah, as I said, it's a niggle and more Mac specific but you do it this way, for instance, in the GUI pane.
The Apply button concept is more firmly entrenched on the other desktops. I really only understood that after writing a Mac-only app and trying to make it work like the other native apps. There are certain situations where you need to start and stop things which does have a separate button. In some cases, certain options are disabled (greyed out / deactivated) when changing them has no effect and deactivated based on another control, say starting/stopping some background process.
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.
Ok a few more now that I'm looking more closely:
- the MIDI channels text box should probably be filled by default aka
"16". Better yet, maybe it should be a drop down box? Also, we weren't able to set the number of channels per device in the old Midi settings dialog?
I'm a little restricted because I don't have any MIDI devices to test with.
Does this mean we can split up channels now?
I haven't changed anything on the C side, nor really any of the settings in the MIDI dialog.
Say use two devices but give them only 8 each? If we can't, then maybe you don't need this text box.
- in the MIDI dialog pane, I get an error when I switch to Multiple
devices then back again: can't read "::midi_inchan2": no such variable
Ok, sounds like a bug on my part. I'll check it out.
- in the Audio dialog pane, you could shorten "msec" to "ms"IMO, and I
would add some text to explain what "Use callbacks" and "Delay" mean and why there's a setting for them. Everything else makes sense really, but those always bothered me.
Actually, I still have some work to do testing with Jack and probably changing some of those settings when it's the API, because I don't think "Delay" has an effect in that case.
Also if you notice the "Help" window for the Audio dialog, you will see I clearly explained "Use callbacks" with "???". :)
I haven't looked at the API code closely enough to understand what it does. If anyone can supply a nice user-facing explanation I'll add it.
- I wish the API dropdown box + "Number of devices" button was
centered like the content below it
Hm... I'll try that.
- The toggle nature of the "Use single/multiples devices" never made
sense to me. IMO is should really be a toggle button: Use multiple devices? [x]
Ah, yes! That will help a lot on OSX, too-- a disabled button doesn't really look disabled for some reason...
Better yet, there wouldn't need to be a direct control if there was a [+] [-] mechanism in the device section itself. The option would be implied: if you are only using 1 device then yeah "Using single device", as soon as you add a second one, then "Using multiple devices". This makes sense for both Audio and Midi. I know this is probably more work on the GUI side, but I thought I'd bring it up from a UI point of view.
Yeah, that's probably the right way to do it.
- in the GUI dialog pane, I'd put the color swatch buttons first, then
the labels. This way they'd be aligned to the left better.
That should be pretty easy to test out. I'll try it.
Thanks for the feedback!
-Jonathan
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
On 30 Jul 2013, at 21:56, Jonathan Wilkes jancsika@yahoo.com 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
-
Dan Wilcox -
Jamie Bullock -
Jonathan Wilkes