[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] RFC: Pbind redesign?

Hi James,

Oh, of course, I was not thinking about the event building inside the pbind.
It is essential to be able to see results from other streams in the event as it is specified;
I am in complete agreement that they should not be 'blind'.

So, that also implies that callbacks are a necessary evil for cleanup.  You do not know
what form the event will take (for example, what server it is on - which is now changed 
by Pattern:asScore) until it is played and you cannot know in what object it will reside.

Thanks! This was very helpful.


PS: The leak left by not copying in EventStreamPlayer is pretty esoteric, so I am going to leave the whole
thing alone.


On Dec 12, 2007, at 9:00 AM, James Harkins wrote:

To solve (2), I think a pattern that plans to modify the input event will have to make its own copy, work on the internal copy, and then if it has to terminate early, return the original event.

I know that means extra garbage to collect, but I don't see another choice. For a long time, I found Pbind hard to work with when I thought its child streams were blind to previously calculated values, and it really became musically useful to me only when I learned how to read the event in progress. If the proposal is to explicitly make the child streams blind, then no, I couldn't agree to it.

I'm okay with some extra garbage if it improves usability.


On Dec 12, 2007, at 8:20 AM, James Harkins wrote:

I would have to vote no, I'm afraid. I routinely write child patterns in Pbind that look in the partially populated event for the values of earlier child patterns - Pkey. I mean, I do this all the time. I can't stress that enough. All the time. This proposal would break every one of my compositions.


On Dec 12, 2007, at 6:54 AM, ronald kuivila wrote:

Hi all,
  Currently, patterns that alter the contents of multiple keys of an event must make a copy of the event.
There are two reasons for this:

1. to prevent pollution of the protoEvent
2. to prevent a partially altered event from being propagated (if one of the streams defining a key value terminates).

  Item 1 could be addressed by making the copy in the EventStreamPlayer before sending 'next' to the event stream.

  Item 2 requires a reimplementation of patterns like Pbind to get all the new values and then transfer them into the Event.

: H. James Harkins

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

Sc-devel mailing list