[PD] Pd preferences dialog progress
João Pais
jmmmpais at googlemail.com
Tue May 28 11:20:36 CEST 2013
> 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.
More information about the Pd-list
mailing list