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.