Re: [sc-dev] Re: calling the stream upon EventStreamPlayer-stop

[James Harkins <jamshark70@xxxxxxxxx>]

On 1/2/06, rkuivila@xxxxxxxxxxxx <rkuivila@xxxxxxxxxxxx> wrote:
> But I am interested in solving the problem as it will help arrive at the
> best design.

On this point -- I feel I should at least make my potentially
heretical case against Pmono/Pfx :)  even if it goes nowhere -- as I
said, I don't want to push the point since there are probably people
relying on Pmono, so if you disagree, that's fine.

IMHO, the problem with patterns and streams is that communication into
a given stream is extremely limited. This is as it should be, given
the requirement that a single pattern can manufacture multiple
streams. It does result in some limitations:

- once they are created, streams are immutable because all of their
state variables are hidden inside local method variables. There is
not, and cannot be (because of pattern nesting), a consistent
interface to access or change them other than passing in values via
.next(). This doesn't bear directly on Pmono, but it is a
compositional limitation.

- patterns are not good at resource management. Any pattern that
relies on external resources (or, to an extent, any resource defined
outside the pattern constructor that needs to be maintained across
events) is risky in performance because you might create or destroy
the resources at the wrong time. Monophonic or effect synths qualify
as "resource[s] defined outside the pattern constructor" because they
exist only in the context of the embedInStream method.

My issue with Pmono and Pfx is that they're trying to manage resources
within a structure that isn't conducive. So, from my point of view,
stream.next(nil) is a workaround for a less-than-ideal design -- which
then has some unfortunate side effects.

My solution in my chucklib framework is to create a container for an
event pattern and event stream. The stream remains immutable, but it
can refer to environment variables that the user can access and
change. The container also handles resource management (there are user
hooks to release resources on stop and free). It's a heavier structure
(too heavy to be a general solution for the class library) but it
opens up a lot of possibilities that are otherwise impossible or
prohibitively inconvenient.

So I wonder if there's a way to decouple resource management in Pmono
and Pfx? It may not be possible, but I've obtained massive benefits by
using patterns and streams for what they're good at it and creating
other structures for the things they don't do so well.

hjh

--
James Harkins /// dewdrop world
jamshark70@xxxxxxxxxxxxxxxxx
http://www.dewdrop-world.net

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman