Re: Observer pattern limitations


"David Barrett-Lennard" wrote:
Frans Bouma wrote:

<snip>

I think people should take a step back and drop the whole 'pattern'
approach until they've figured out which problems they want to solve
in the first place. Too many developers design their software by
connecting patterns with patterns like lego blocks, but that's not
what they're all about.

I agree with that as well.

Well, I may be beating a dead horse at this point. But I was thinking
about David's X, Y, Z example in his original post as it applies to a
domain I'm interested in, sound synthesis for musical application (I've
talked a little about this elsethread), and wanted to share my thoughts
and hopefully get some feedback. I'm hoping that even though the example
I'm using is of personal interest, I can use it to shine light on some
problems whose solutions may have larger applicability.

Hardware synthesizers have been popular for decades, and as computers
have become more powerful, modeling hardware synthesizers in software
has become popular as well, just look at VST. The first thing that
strikes you when you look at the old analog synthesizers is how modular
many of them were. They were made up of components that could be plugged
into each other in countless ways. So when you begin thinking about
modeling synthesizers in software, it's natural to think in terms of
modeling components individually. It's also desirable to give them the
same pluggable interfaces.

This is good, but there is a problem: You're modeling an analog domain
in a digital one. Why is this a problem?

If you take the output of one hardware component, split it, and send one
branch to the input of a component and the other branch to the input of
another component, you can assume that the output of the original
component will arrive simultaneously at the input of both components
(actually, I'm not knowledgeable enough in physics to say this with
absolute certainty, but at least from a practical standpoint, it is
true).

-------------->

+---+
| B |-->
+---+
+---+ out |in
| A |-------+
+---+ |in
+---+
| C |-->
+---+

If you model the components in software as objects, the same cannot be
said. The output becomes descreet with the component sending its output
to the two input components in turn, one right after the other via an
Observer notification or direct communication or whatever.

In some situations this isn't a problem, but in other situations it is.
Certainly if you want to design a general framework for creating and
configuring synthesizer components, you have to find some way to make
your discreet signals behave more like continuous ones.

Here is an example that can cause a problem:

---------------->

+---+out
| B |--+
+---+ |
+---+ out |in | in+---+out
| A |-------+ +---| D |---->
+---+ |in | +---+
+---+ |
| C |--+
+---+out

Let's run through how this works:

A generates a signal, and it passes this signal along to B and C
synchronously. Let's say that B gets notified first. B receives the
signal and does whatever processing it needs on it and sends the
modified signal on to D. In turn, D does its thing and sends the results
to its output. The problem is that C has not gotten a chance to
contribute its part. It's only after D has finished that A finally gets
back control and can notify C. C then processes the signal and sends it
to D... So the output from D doesn't reflect the intent of the
algorithm.

This illustrates the problem of treating the signal discreetly, and it
is similiar to David's X, Y, Z problem, IMO.

So how can this be solved?

I described one way elsethread, and that is to treat each component as a
simple state machine. Each component knows how many components have been
connected to it. It doesn't process the signal until its received the
output from all of the components connected to its input. Once that
happens it fires and resets itself for the next sample. The protocol
here would have to be strict and well thought out. The signals from the
components could not arrive in an arbitrary way, e.g. you wouldn't want
one component sending out a signal twice in a row before all of the
other components have sent out their signals.

Another possible way of solving this problem is to use David's approach.
When the output from D is retrieved, D in turn retrieves the output from
B and C. B and C retrieve the output from A. We have to make sure that
when B and C retrieve the output from A, A only performs its calculation
once instead of twice. So before the output of D is retrieved, the
components are marked as dirty. The dirtiness can be propagated through
the components as they change, or, as I was thinking, a seperate
algorithm could mark them instead, depends on the situation. At any
rate, when A performs its calculation in response to B or C, it marks
itself as clean. That way, when it is accessed a second time, it doesn't
perform the calculation again. B and C do their thing and pass it back
to D which then outputs its result.

Both approaches solve the same problem, IMO, and that is to turn
descreet events into continuous ones. Or another way of thinking about
it, it's as if we have an algorithm, and we're making sure that each
step of the algorithm completes before the next step is begun. We run
into a problem, as I see it, when the partial results of a step in an
algorithm are acted upon by the next step prematurely.




.

Relevant Pages

  • Re: Other "tested" techniques for detecting bias
    ... If you know that an algorithm was used then you don't need to ... You don't "know" until you test your prediction against what actually ... This is the restriction that SETI ... ways to conceal their signals so that we could not decipher them. ...
    (talk.origins)
  • Re: Other "tested" techniques for detecting bias
    ... If you know that an algorithm was used then you don't need to ... ways to conceal their signals so that we could not decipher them. ... coding theory and cryptography as ... any tested technique you know of by which you can detect and measure ...
    (talk.origins)
  • Re: MUSIC and LMS together??
    ... "A smart antenna system at the base station of a cellular mobile ... The adaptive beamforming algorithm optimizes ... is tailored to the signals they will measure. ...
    (comp.dsp)
  • Cracking Skype
    ... As encryption goes a donut algorithm would likely attack. ... encrypted analog signals. ...
    (sci.crypt)
  • Re: "Humans Do It Now" Criteria (was: Definition Challenge)
    ... signals, there may be OTHER SIGNALS in the data, that some OTHER ... identify the ET-archelogy. ... bottleneck. ... I think your algorithm is not useful. ...
    (talk.origins)