[PD] Pd preferences dialog progress

[João Pais]

> 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 piece has either 2 or 6 inputs and outputs (to be chosen separately)
- the channels chosen for the number of inputs can be varied depending on  
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).
- another person performing the piece with another hardware will use other  
input/output channels
- the purpose of the patch (and of any patch that is sent with a score) is  
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.