From: Joćo Pais <jmmmpais@googlemail.com>
To: "pd-list@iem.at" <pd-list@iem.at>; Jonathan Wilkes <jancsika@yahoo.com>
Sent: Tuesday, May 28, 2013 2:34 AM
Subject: Re: [PD] Pd preferences dialog progress

> Looks very nice. Can you show also the other sections of the dialog?

The GUI tab is just a placeholder for the moment.  I don't have anything
hooked up there yet.

> One minimal detail: "Use single device" instead of "devices"

Yeah, that's bad but it could still be two devices which is why I wrote
it that (bad) way.  I'll try to think of an improvement.

> A bigger detail: does it make sense (for logical and practical reasons) to 
add a menu to select which channels go into which inputs/outpus, like on 
max/msp?

Now that I've got the ttk styles down the frontend would take about 5 minutes
to make.  Actually making it do something would take a lot longer, unless there's
a trick to it that one of the audio gurus knows about.

I may be wrong but that feature only seems important in making insane patches
sane.  If you make an audio-producing patch in a maintainable way I imagine you'd
have everything ending up in a single [dac~] somewhere, especially a patch that's
massive-channel. In that case you could make an abstraction [ltop~] with
the same number of inlets as the [dac~],edit the [dac~] object box and make it
an [ltop~], then route the logical [inlets~] inside your abstraction to the physical
channels of a [dac~] inside it.  It doesn't work if there are [dac~]s
sprinkled throughout a complex patch, but then that kind of patch probably doesn't
work anyway. :)

But if the idea is to avoid editing the patch itself and instead edit the Pd instance,
maybe someone can write a gui-plugin to automate what I wrote above.
You'd right-click on a [dac~] and choose "map i/o" and it opens up a patch window
with [inlet~]s corresponding to the number of of logical inputs, with a [dac~]
sitting in the middle of the patch.  That's a much better user-interface than a
big table.  Do the same with [outlet~]s and [adc~] and you're done.

-Jonathan


> Hi List,
>      I've made some progress on the centralized preferences dialog 
> window.  Screenshot attached show the appearance under X11.
>
>
> Progress:
> * dropdown menus modeled after gtk for GNU/Linux (ttk::combobox)
> * native dropdown menus for Windows (ttk::combobox)
>
> * native-ish dropdown menus for OSX (ttk::menubutton)
>
> * multi-device button doesn't disappear when clicked (see attached 
> audiodialog3.png)
> * audio api/settings/devices all in a single window
> * devices aligned in grid
> * removed cruft: unnecessary colons, device checkbuttons, label 
> repetition
>
> * multi-device button disabled when there aren't multiple ins/outs
> * single "connect" button to clarify when Pd is supposed to open audio
>
> * can specify "None" as device (same as unchecking the device in the old 
> audio dialog)
>
> * replaced "Apply" and "Ok" buttons with "Connect", which is more 
> explicit.  Also, it makes a nice
> flow from top to bottom: choose an api, the common audio settings, the
> specific devices (and device specific attributes: "channels"), and 
> finally click "Connect".  Connect also saves the audio settings-- I 
> think that's generally what
> the user wants to do, and there can be a more general feature to make
> "profiles" if the user has a more complex/dynamic setup.
>
>
> I can also make it possible to specify no api (or a dummy one) if that's 
> desirable.
>
> Screenshots currently lack a "Close" button which will be common to all 
> preference frames. (I.e., at the bottom of the dialog below the notebook 
> widget.)
>
> For my own sanity the API dropdown list currently shows Pd's api number 
> as well as the API name.
>
>
> -Jonathan