[Pd] Feature Request: trigger editing (fwd)

Mathieu Bouchard matju at artengine.ca
Wed Jul 5 20:00:15 CEST 2006


---------- Forwarded message ----------
Date: Tue, 4 Jul 2006 09:27:44 +0100
From: padawan12 <padawan12 at obiwannabe.co.uk>
To: Mathieu Bouchard <matju at artengine.ca>
Subject: Re: [Pd] Feature Request: trigger editing

On Mon, 3 Jul 2006 13:11:46 -0400 (EDT)
Mathieu Bouchard <matju at artengine.ca> wrote:

> On Tue, 4 Jul 2006, padawan12 wrote:
>
>
>> Anyway it seems in Pd, perhaps because passing parmeters to subpatches
>> and abstractions isn't formal,
>
> What do you mean "not formal" ?
formal in the common english, not the same as formal parameters of a
C function. As in, I'd rather have a name-value hash to pass in :)


> BTW subpatches don't take any creation arguments (just a name).
> Abstraction instances do.

Indeed, but I'm not talking about creation args.
>
>> and there's not a handy way to wrap the parameters of a block of code,
>> that trigger gets abused.
>
> I don't know what you mean here. Want to give an example?


Sure, say we have built a brass instrument subpatch. Our parameters
are 3 floats which describe continuous controls, breath pressure,
lip tightness, mute position, and 3 bools for discontinuous controls
like for 3 valves. When I talk about a "parameter" I'm talking
about this sort of thing, values that are applied in real time to the
computation. I want to say here's a trumpet, and here's its named
parameters

valve1: type bool, default 1
valve2: type bool, default 1
valve3: type bool, default 1
breath_pressure: type float, default 0, range 0 1
lip tightness: type float, default 0.5, range -1 1
mute position: type float, default 1, range 0 1

Right now the most 'elegant' way of doing that I know of is
using [route]. I often find myself making a "wrapper" for a instrument
that goes through a familiar pattern.
First scale all the values or normalise
them as required, bound the ranges with [min] and [max], weed out
any coupling or collapse groups of them, and present a nice
shiny named list. This list, usually gets appended to the end of
a [poly] list for routing individual poly voices etc. That seems
te established method for making polysynths. But it seems fiddly and
difficult because the only mapping between a parameter and its purpose
is in the ordering of the list passed. Is there a better way to do this?
Better than using routes and unpacks?

Isn't using [t b f f f a a a a a ] and sending everything in a mixed
list, instead of the above, an abuse of [t]? It seems less robust.















More information about the Pd-list mailing list