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
Looks very nice. Can you show also the other sections of the dialog?
One minimal detail: "Use single device" instead of "devices"
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?
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
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
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.
I can't say anything about the technical points behind it. But I'll just
give an example of a patch I've programmed for someone to illustrate this
point:
the hardware: I've programmed a [adc~ 1 2 3 4 5 6], but when I performed
myself the piece I used adc~ 11-16 or adc~ 8-14 (the spdif channels are
switched in the linux driver).
input/output channels
that it should be performed without the performer having to go inside it -
many people don't know how to use a specific software, and the software
should allow them to run the patch without any special effort
These problems would be solved in the most easy way, if adc~/dac~ would
allow for a "set" method. A paralel solution would be to change the
routings of the audio channels in the audio settings - and if it's there,
then I could e.g. build a GUI for it, and save a configuration file for a
given performance. That means, the user would be able to set up everything
with a few clicks.
Surely these aren't the most relevant feature that need to be implemented,
but they would give some help.
Btw, related to this topic and to your startnext idea: how about a
messaging system that allows to edit an object? E.g. replace a [expr
$f1+1] with [expr $f1-1]. This would provide a (not optimal) solution to
the problems above, and would extend the possibilities of dynamic patching
a lot.