I support Mike here (another vote for 3).

The important votes are from those like Mike who *use* pset. We need to hear 
from anyone who has used pset - especially anyone for whom a 
change/clarification would break something.

Art Hunkins

----- Original Message ----- 
From: "Michael Gogins" 
To: 
Sent: Wednesday, August 25, 2010 11:25 AM
Subject: [Csnd] Re: Re: Re: default p-fields?


I need 3.

Mike

On Wed, Aug 25, 2010 at 11:07 AM, joachim heintz  
wrote:
> my vote is for 3. i don't think 1 makes sense, or anyone wished to have 
> it.
>
>
> Am 25.08.2010 um 16:56 schrieb jpff@cs.bath.ac.uk:
>
>> For some value of current....
>>
>> There are three options
>>
>> 1: pset always wins
>> 2: score always wins
>> 3: pset fills in what score does not give.
>>
>> It was 2, now 1. I know how to do 3 if that is what is wanted.
>>
>> So what is correct? The manual says 1 to me
>>
>>
>>> the current behaviour is that the score line without p4, p5, p6, ...
>>> overwrites also p4, p5, p6, ... from a pset statement, as they are
>>> implicitely regarded as 0 or as equal to the previous p-field. this:
>>> 
>>> 
>>> ksmps = 4410
>>> instr 1
>>> pset 11, 12, 13, 14, 15, 16
>>> print p4, p5, p6
>>> endin
>>> 
>>> 
>>> i 1 0 0
>>> i 1 0 0 4 5 6
>>> i 1 0 0
>>> 
>>> 
>>>
>>> prints:
>>> instr 1: p4 = 0.000 p5 = 0.000 p6 = 0.000
>>> instr 1: p4 = 4.000 p5 = 5.000 p6 = 6.000
>>> instr 1: p4 = 4.000 p5 = 5.000 p6 = 6.000
>>>
>>> so, in the first and the third case the values should be taken from
>>> the pset statement.
>>> i think this is what you mean, but it is not the current behaviour.
>>>
>>> joachim
>>>
>>>
>>>
>>> Am 25.08.2010 um 16:16 schrieb Michael Gogins:
>>>
>>>> This behavior is correct. I need the score values to overwrite the
>>>> pset values. I need to use exactly the same instr definitions both for
>>>> MIDI-driven performance and for score-driven performance. This way the
>>>> pset opcode supplies default values for pfields during MIDI
>>>> performance that are supplied by score during score-driven
>>>> performance.
>>>>
>>>> It would be fine for me if pset pfields only were overwritten if there
>>>> actually was a pfield at that slot from the score. But perhaps this is
>>>> the current behavior? If not, I think it should be. I think that would
>>>> cover most cases.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Wed, Aug 25, 2010 at 9:55 AM, John ff  wrote:
>>>>>
>>>>> Fixed in CVS
>>>>> ==John ffitch
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>> https://sourceforge.net/tracker/?
>>>>> group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe csound"
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>>
>>>>
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>