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

[James Harkins <jamshark70@xxxxxxxxx>]

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.

hjh

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.

hjh

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

: 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