[Sc-devel] Pattern Reform Part II
James Harkins
jamshark70 at gmail.com
Mon Oct 8 16:05:09 PDT 2007
On 10/7/07, Julian Rohrhuber <rohrhuber at uni-hamburg.de> wrote:
> Toward a better scheme of ending streams, I've made a little
> prototype. It simplifies a lot of patterns, but of course adds to
> Event:play.
Since this will probably affect me, I'd like to be sure I understand
the proposal. IIUC, the issue is how to get child streams to clean up
if a parent pattern (such as Pfindur) ends?
My main concern, when I complained about some of this a while back, is
that some patterns must clean up when stopped, but for other (most)
patterns, the cleanup request is irrelevant. I had some unpleasant
consequences in my algorithmic composition routines when a no-cleanup
stream would get called with the signal to stop. That stream would
produce one value that would not be used, causing the value to be
skipped on the next play. (That problem is exposed only when you use a
mechanism to persist a stream outside of the event pattern, which is
critical to my working method.)
Maybe I'm missing something, but how will this suggestion solve that problem?
Maybe there is no good solution that would not overcomplicate the
current scheme. A big part of the problem, as I see it, is that the
Stream object doesn't know which Pattern class is responsible for its
current behavior. That rules out a whole class of polymorphic
solutions, where you could issue a "cleanup" method call and only
those patterns that need to clean up would respond. That would make
things more complicated, though, and I doubt it's worth it.
Probably the best thing is for me to make sure I always use a wrapper
around the persistent streams that filters out next(cleanupEvent). But
I still can't shake the feeling that I'm just hacking around a
limitation of the current pattern architecture.
hjh
--
James Harkins /// dewdrop world
jamshark70 at dewdrop-world.net
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
More information about the Sc-devel
mailing list