patch parameterisation: was [PD] abstractions which have their own memory

[Frank Barknecht]

Hallo,
(cc'ing pd-list) 

padawan12 hat gesagt: // padawan12 wrote:

> Yes, I strongly agree with this, with a couple of
> caveats. It's something I'm struggling to formulate
> on other subject threads and is tied up with 
> the process of "parameterisation".
> 
> In the old days you basically had 3 layers
> 
> Performance data sitting on top of the patch
> sitting on top of the hardware. The hardware was
> an immutable given, and the patch could be seen like
> a "firmware" on which you could base a performance.
> 
> The line between pre-configuration and real-time control
> has always been blury and shifting. In some ways it is
> an artifice of historical design practices, but it has
> utility to reduce performance data.
> 
> You can see the "patch" as being the data that is factored
> out of a performance, stuff that will remain the same for
> every note/event.
> 
> On the other hand, a properly flexible synthesiser
> can address every parameter on every note, or even at
> every computation tick, the synth is constantly updated.
> In this model we stop viewing the synth as a fixed instrument.
> This fits well with the ground between explicit synthesis
> (human parameterised) and resynthesis (where the parameters
> are analytic signals.)
> 
> If you take this model to its logical conclusion, it's an
> argument agaist "patches" of any kind whatsoever. Patches
> don't exist anymore. Instead you have only a rich set of
> performance/control data. 
> 
> Problem is, it's unmanagable in most practical cases.
> 
> So, the optimal digital synthesiser is a layered model
> with the "patch" data as an interpreter of performance
> data, which passes it down to the synthesis subsystem.
> That synthesis engine/gubbins/guts should be as you describe,
> unsullied by any design decisions hardcoded into it.
> 
> This is essential in my model for effective real-time 
> clientside synthesis of sounds on a replicated multiplayer
> network game. The actual DSP parts that do the hard work
> are very small, and must be split from the data that tells
> them what to do - that comes over the network or from
> the physics engine.

That's actually exactly the setup I used when I was hit with problems
in netsend/netreceive: I'm using a physics engine and graphical
visualisation in one Pd, then connect this to another Pd which
functions as the synth engine. The synth-"patch" is very simple and
small, while most of the work is done in the other Pd. Physics is more
demanding than sound synthesis in this case.

> I am hoping to expand this analysis into a whole chapter 
> on the issues of parameterisation. Many more questions
> are raised, such as the need for a fourth layer that 
> sits between the synth and patch interpreter to manage
> scaling and limits, a kind of realtime type and bounds
> checking and coercion process. Clearly this doesn't belong
> in the synthesis core either. 

Cyrille Henry and Ali Momeni wrote about this in e.g. their paper: 
"Dynamic Autonomous Mapping Layers for Concurrent Control of Audio and
Video Synthesis" where they view this "fourth layer" or mapping layer
as a dynamic system itself, that is, it's something that follows its
own rules and can change as well. This is just one example where a
naive way of state saving hits at borders: What if you want to
programmatically change your "state" through interpolation or other
means? If this state is distributed over many patch file or
hardcoded into message boxes, processing the state itself becomes hard
or impossible. I admit that Memento doesn't have a solution for this
problem yet, and I'm still not sure how it can get one.

> Until this is all explained clearly the semantic problem
> is what we mean by a "patch". Most peoples synthesisers contain
> all of the five layers, which they call a patch, so naturally
> the fixed "patch" values go inside that. It isn't until
> you have to decouple the interface from the DSP gubbins that
> you realise the bad software engineering decisions in there.

Now I'll first have to look up what "gubbins" are, but I have a
guess ... ;)

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__