Hi all--I'm stuck--

Is there a way to get a variable out of a reinit loop for use after 
rireturn? This seems like something that ought to be possible. Making 
the variable global sort of works when more instances are added to 
the score but the values below rireturn don't match those inside 
reinit. Are variables reinitialized to their original values upon 
exiting reinit? If so, is there a way to prevent it?

Here's an example:

sr      =       44100
kr      =       4410
ksmps   =       10
nchnls =        1

         instr 1
iamp   =        p4
ifrq    =       p5
idur    =       p7
ifade   init    0
ifadeadd init   0

loop:

idur    =       idur-(idur*.02)
idur    =       (idur>.005 ? idur:.005)
ifadeadd =     (idur>.005 ? 0:.005)
ifade  =        ifade+ifadeadd

         ;print ifade      ;shows correct incremented value,
                          ;about 5 seconds for values in score

         timout  0,idur,contin
         reinit  loop

contin:
         rireturn

         ;print ifade      ;shows ifade=0

a1      oscili  iamp,ifrq,1
kout    linseg  1,p3-ifade,1,ifade,0

         out     a1*kout   ;sound plays but no fade
         endin

[score]
f1      0       4096    10      1

;p1     p2      p3      p4      p5      p6      p7
i1      0       10      15000   200     0       .1


Thanks in advance for any suggestions--


David Mooney:  dmooney@city-net.com
Maxine Heller:  mheller@city-net.com
Opaque Melodies:  www.city-net.com/~moko/

When an opcode is initialized (at i-time), it sets the values for any i-time 
arguments and doesn't read them again unless it is itself reinitialized.  Any opcode 
or calculation that is supposed to use the reinit'ed value of an i-rate var must also 
be reinited.  So if you put your linseg inside the reinit loop it should work. 
That's also why the second 'print ifade' always prints 0.  It prints the value of 
ifade only the first time it is encountered, when ifade==0.  Since the print isn't 
reinit'ed, it doesn't print anything else even though the value of ifade has changed.

John W. Lato
School of Music
The University of Texas at Austin
1 University Station E3100
Austin, TX 78712-0435
(512) 232-2090

David Mooney/Maxine Heller wrote:
> Hi all--I'm stuck--
> 
> Is there a way to get a variable out of a reinit loop for use after 
> rireturn? This seems like something that ought to be possible. Making 
> the variable global sort of works when more instances are added to the 
> score but the values below rireturn don't match those inside reinit. Are 
> variables reinitialized to their original values upon exiting reinit? If 
> so, is there a way to prevent it?
> 
> Here's an example:
> 
> sr      =       44100
> kr      =       4410
> ksmps   =       10
> nchnls =        1
> 
>         instr 1
> iamp   =        p4
> ifrq    =       p5
> idur    =       p7
> ifade   init    0
> ifadeadd init   0
> 
> loop:
> 
> idur    =       idur-(idur*.02)
> idur    =       (idur>.005 ? idur:.005)
> ifadeadd =     (idur>.005 ? 0:.005)
> ifade  =        ifade+ifadeadd
> 
>         ;print ifade      ;shows correct incremented value,
>                          ;about 5 seconds for values in score
> 
>         timout  0,idur,contin
>         reinit  loop
> 
> contin:
>         rireturn
> 
>         ;print ifade      ;shows ifade=0
> 
> a1      oscili  iamp,ifrq,1
> kout    linseg  1,p3-ifade,1,ifade,0
> 
>         out     a1*kout   ;sound plays but no fade
>         endin
> 
> [score]
> f1      0       4096    10      1
> 
> ;p1     p2      p3      p4      p5      p6      p7
> i1      0       10      15000   200     0       .1
> 
> 
> Thanks in advance for any suggestions--
> 
> 
> David Mooney:  dmooney@city-net.com
> Maxine Heller:  mheller@city-net.com
> Opaque Melodies:  www.city-net.com/~moko/
> 

Thanks, John--

I understand what you are saying and did try this--tried it again to 
be sure. The linseg behaves the same whether in or out of the reinit 
portion of the orc. It behaves as though ifade is NOT incrementing, 
but stays at its initial value of 0. Could it be something about the 
way linseg operates?

Anyhow, I can use print to get ifade values then just put them in the 
score as another p field and so get the sound I want, but it would be 
nice to generate it automatically.

I'm fairly new to Csound and progress is glacial among other 
concerns. I suspect there's an easy answer out there waiting for me 
to stumble upon it.

At 03:11 PM 8/29/2007, you wrote:
>When an opcode is initialized (at i-time), it sets the values for 
>any i-time arguments and doesn't read them again unless it is itself 
>reinitialized.  Any opcode or calculation that is supposed to use 
>the reinit'ed value of an i-rate var must also be reinited.  So if 
>you put your linseg inside the reinit loop it should work. That's 
>also why the second 'print ifade' always prints 0.  It prints the 
>value of ifade only the first time it is encountered, when 
>ifade==0.  Since the print isn't reinit'ed, it doesn't print 
>anything else even though the value of ifade has changed.
>
>John W. Lato
>School of Music
>The University of Texas at Austin
>1 University Station E3100
>Austin, TX 78712-0435
>(512) 232-2090
>
>David Mooney/Maxine Heller wrote:
>>Hi all--I'm stuck--
>>Is there a way to get a variable out of a reinit loop for use after 
>>rireturn? This seems like something that ought to be possible. 
>>Making the variable global sort of works when more instances are 
>>added to the score but the values below rireturn don't match those 
>>inside reinit. Are variables reinitialized to their original values 
>>upon exiting reinit? If so, is there a way to prevent it?
>>Here's an example:
>>sr      =       44100
>>kr      =       4410
>>ksmps   =       10
>>nchnls =        1
>>         instr 1
>>iamp   =        p4
>>ifrq    =       p5
>>idur    =       p7
>>ifade   init    0
>>ifadeadd init   0
>>loop:
>>idur    =       idur-(idur*.02)
>>idur    =       (idur>.005 ? idur:.005)
>>ifadeadd =     (idur>.005 ? 0:.005)
>>ifade  =        ifade+ifadeadd
>>         ;print ifade      ;shows correct incremented value,
>>                          ;about 5 seconds for values in score
>>         timout  0,idur,contin
>>         reinit  loop
>>contin:
>>         rireturn
>>         ;print ifade      ;shows ifade=0
>>a1      oscili  iamp,ifrq,1
>>kout    linseg  1,p3-ifade,1,ifade,0
>>         out     a1*kout   ;sound plays but no fade
>>         endin
>>[score]
>>f1      0       4096    10      1
>>;p1     p2      p3      p4      p5      p6      p7
>>i1      0       10      15000   200     0       .1
>>
>>Thanks in advance for any suggestions--
>>
>>David Mooney:  dmooney@city-net.com
>>Maxine Heller:  mheller@city-net.com
>>Opaque Melodies:  www.city-net.com/~moko/
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

David Mooney:  dmooney@city-net.com
Maxine Heller:  mheller@city-net.com
Opaque Melodies:  www.city-net.com/~moko/

After looking at how some of the values in your example accumulate, I think the 
problem is with your linseg arguments.  You use
kout linseg 1, p3-ifade, 1,...

Since p3 is 10 in your example, kout will stay at 1 until p3-ifade seconds.  ifade is 
0 until idur drops to .005, which means that ifade will need to reach a total value 
of 10 before the linseg will ever get a chance to fade (after 2000 iterations). 
Furthermore, since ifade moves by .005 increments, the next reinit will give ifade a 
value of 10.005, giving linseg a negative time duration.  This is not likely what you 
want.

Perhaps it would work better if your linseg statement was
kout linseg 1, idur-ifade, 1, ifade, 0

ifade should also be strictly smaller than idur.
And, as I previously mentioned, linseg should be in the reinit loop.

Also, a note duration of .005 seconds seems a little short for the length of fade to 
be very perceptible.  You may want to increase the threshold for idur and ifadeadd to 
something larger.

John W. Lato
School of Music
The University of Texas at Austin
1 University Station E3100
Austin, TX 78712-0435
(512) 232-2090

David Mooney/Maxine Heller wrote:
> Thanks, John--
> 
> I understand what you are saying and did try this--tried it again to be 
> sure. The linseg behaves the same whether in or out of the reinit 
> portion of the orc. It behaves as though ifade is NOT incrementing, but 
> stays at its initial value of 0. Could it be something about the way 
> linseg operates?
> 
> Anyhow, I can use print to get ifade values then just put them in the 
> score as another p field and so get the sound I want, but it would be 
> nice to generate it automatically.
> 
> I'm fairly new to Csound and progress is glacial among other concerns. I 
> suspect there's an easy answer out there waiting for me to stumble upon it.
> 
> At 03:11 PM 8/29/2007, you wrote:
>> When an opcode is initialized (at i-time), it sets the values for any 
>> i-time arguments and doesn't read them again unless it is itself 
>> reinitialized.  Any opcode or calculation that is supposed to use the 
>> reinit'ed value of an i-rate var must also be reinited.  So if you put 
>> your linseg inside the reinit loop it should work. That's also why the 
>> second 'print ifade' always prints 0.  It prints the value of ifade 
>> only the first time it is encountered, when ifade==0.  Since the print 
>> isn't reinit'ed, it doesn't print anything else even though the value 
>> of ifade has changed.
>>
>> John W. Lato
>> School of Music
>> The University of Texas at Austin
>> 1 University Station E3100
>> Austin, TX 78712-0435
>> (512) 232-2090
>>
>> David Mooney/Maxine Heller wrote:
>>> Hi all--I'm stuck--
>>> Is there a way to get a variable out of a reinit loop for use after 
>>> rireturn? This seems like something that ought to be possible. Making 
>>> the variable global sort of works when more instances are added to 
>>> the score but the values below rireturn don't match those inside 
>>> reinit. Are variables reinitialized to their original values upon 
>>> exiting reinit? If so, is there a way to prevent it?
>>> Here's an example:
>>> sr      =       44100
>>> kr      =       4410
>>> ksmps   =       10
>>> nchnls =        1
>>>         instr 1
>>> iamp   =        p4
>>> ifrq    =       p5
>>> idur    =       p7
>>> ifade   init    0
>>> ifadeadd init   0
>>> loop:
>>> idur    =       idur-(idur*.02)
>>> idur    =       (idur>.005 ? idur:.005)
>>> ifadeadd =     (idur>.005 ? 0:.005)
>>> ifade  =        ifade+ifadeadd
>>>         ;print ifade      ;shows correct incremented value,
>>>                          ;about 5 seconds for values in score
>>>         timout  0,idur,contin
>>>         reinit  loop
>>> contin:
>>>         rireturn
>>>         ;print ifade      ;shows ifade=0
>>> a1      oscili  iamp,ifrq,1
>>> kout    linseg  1,p3-ifade,1,ifade,0
>>>         out     a1*kout   ;sound plays but no fade
>>>         endin
>>> [score]
>>> f1      0       4096    10      1
>>> ;p1     p2      p3      p4      p5      p6      p7
>>> i1      0       10      15000   200     0       .1
>>>
>>> Thanks in advance for any suggestions--
>>>
>>> David Mooney:  dmooney@city-net.com
>>> Maxine Heller:  mheller@city-net.com
>>> Opaque Melodies:  www.city-net.com/~moko/
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> David Mooney:  dmooney@city-net.com
> Maxine Heller:  mheller@city-net.com
> Opaque Melodies:  www.city-net.com/~moko/
> 

Thanks, John, for continuing to look at this--

kout linseg is supposed to be an overall envelope that fades over the 
p3 value of the "note" in the score, not for each iteration generated 
by the reinit loop. kout works when I put in some absolute value--the 
many iterations fade nicely with aout*kout

However, in reading over your replies, I thought of a completely 
different way of getting a fade that works. Instead of an overall 
envelope, use the incrementing value to reduce the amp of each 
iteration once the critical value (idur=.005) is reached. This works:

iamp    =       p4
...
idur    =       p7
ifadeadd init   0

loop:
...
kamp    linseg  0,idur*.1,iamp,idur*.9,0        ;envelope for each iteration,
                                                 ;smooth tone when idur long,
                                                 ;no clicking when 
it's short
ifadeadd =      (idur>.005 ? 0:iamp*.005)
iamp    =       iamp-ifadeadd

         timout  0,idur,contin
         reinit  loop

contin:
         rireturn
a1      oscili  kamp,kfrq,1
         out     a1

The ".005" value in the conditional would need to be adjusted 
according to p3 so that the overall "note" fades during p3, but the 
principle is here. Thanks again--you made me think differently which 
is always appreciated.

At 04:58 PM 8/31/2007, you wrote:
>After looking at how some of the values in your example accumulate, 
>I think the problem is with your linseg arguments.  You use
>kout linseg 1, p3-ifade, 1,...
>
>Since p3 is 10 in your example, kout will stay at 1 until p3-ifade 
>seconds.  ifade is 0 until idur drops to .005, which means that 
>ifade will need to reach a total value of 10 before the linseg will 
>ever get a chance to fade (after 2000 iterations). Furthermore, 
>since ifade moves by .005 increments, the next reinit will give 
>ifade a value of 10.005, giving linseg a negative time 
>duration.  This is not likely what you want.
>
>Perhaps it would work better if your linseg statement was
>kout linseg 1, idur-ifade, 1, ifade, 0
>
>ifade should also be strictly smaller than idur.
>And, as I previously mentioned, linseg should be in the reinit loop.
>
>Also, a note duration of .005 seconds seems a little short for the 
>length of fade to be very perceptible.  You may want to increase the 
>threshold for idur and ifadeadd to something larger.
>
>John W. Lato
>School of Music
>The University of Texas at Austin
>1 University Station E3100
>Austin, TX 78712-0435
>(512) 232-2090
>
>David Mooney/Maxine Heller wrote:
>>Thanks, John--
>>I understand what you are saying and did try this--tried it again 
>>to be sure. The linseg behaves the same whether in or out of the 
>>reinit portion of the orc. It behaves as though ifade is NOT 
>>incrementing, but stays at its initial value of 0. Could it be 
>>something about the way linseg operates?
>>Anyhow, I can use print to get ifade values then just put them in 
>>the score as another p field and so get the sound I want, but it 
>>would be nice to generate it automatically.
>>I'm fairly new to Csound and progress is glacial among other 
>>concerns. I suspect there's an easy answer out there waiting for me 
>>to stumble upon it.
>>At 03:11 PM 8/29/2007, you wrote:
>>>When an opcode is initialized (at i-time), it sets the values for 
>>>any i-time arguments and doesn't read them again unless it is 
>>>itself reinitialized.  Any opcode or calculation that is supposed 
>>>to use the reinit'ed value of an i-rate var must also be 
>>>reinited.  So if you put your linseg inside the reinit loop it 
>>>should work. That's also why the second 'print ifade' always 
>>>prints 0.  It prints the value of ifade only the first time it is 
>>>encountered, when ifade==0.  Since the print isn't reinit'ed, it 
>>>doesn't print anything else even though the value of ifade has changed.
>>>
>>>John W. Lato
>>>School of Music
>>>The University of Texas at Austin
>>>1 University Station E3100
>>>Austin, TX 78712-0435
>>>(512) 232-2090
>>>
>>>David Mooney/Maxine Heller wrote:
>>>>Hi all--I'm stuck--
>>>>Is there a way to get a variable out of a reinit loop for use 
>>>>after rireturn? This seems like something that ought to be 
>>>>possible. Making the variable global sort of works when more 
>>>>instances are added to the score but the values below rireturn 
>>>>don't match those inside reinit. Are variables reinitialized to 
>>>>their original values upon exiting reinit? If so, is there a way to prevent it?
>>>>Here's an example:
>>>>sr      =       44100
>>>>kr      =       4410
>>>>ksmps   =       10
>>>>nchnls =        1
>>>>         instr 1
>>>>iamp   =        p4
>>>>ifrq    =       p5
>>>>idur    =       p7
>>>>ifade   init    0
>>>>ifadeadd init   0
>>>>loop:
>>>>idur    =       idur-(idur*.02)
>>>>idur    =       (idur>.005 ? idur:.005)
>>>>ifadeadd =     (idur>.005 ? 0:.005)
>>>>ifade  =        ifade+ifadeadd
>>>>         ;print ifade      ;shows correct incremented value,
>>>>                          ;about 5 seconds for values in score
>>>>         timout  0,idur,contin
>>>>         reinit  loop
>>>>contin:
>>>>         rireturn
>>>>         ;print ifade      ;shows ifade=0
>>>>a1      oscili  iamp,ifrq,1
>>>>kout    linseg  1,p3-ifade,1,ifade,0
>>>>         out     a1*kout   ;sound plays but no fade
>>>>         endin
>>>>[score]
>>>>f1      0       4096    10      1
>>>>;p1     p2      p3      p4      p5      p6      p7
>>>>i1      0       10      15000   200     0       .1
>>>>
>>>>Thanks in advance for any suggestions--
>>>>
>>>>David Mooney:  dmooney@city-net.com
>>>>Maxine Heller:  mheller@city-net.com
>>>>Opaque Melodies:  www.city-net.com/~moko/
>>>--
>>>Send bugs reports to this list.
>>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>David Mooney:  dmooney@city-net.com
>>Maxine Heller:  mheller@city-net.com
>>Opaque Melodies:  www.city-net.com/~moko/
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

David Mooney:  dmooney@city-net.com
Maxine Heller:  mheller@city-net.com
Opaque Melodies:  www.city-net.com/~moko/

Ahh, I misunderstood what you were trying to do.  I did not get that the linseg was 
supposed to be an overall envelope.  But it looks like you got a working instrument 
despite my mis-interpretation.  This new version looks pretty idiomatic.  You could 
use a non-reinited linseg to create an overall envelope instead of this approach, but 
  all the parameters would need to be set at the first i-time and not changed.  Then 
you'd need another, reinit'ed linseg, for a de-click envelope.  Your way of doing it 
seems easier, though.

John W. Lato
School of Music
The University of Texas at Austin
1 University Station E3100
Austin, TX 78712-0435
(512) 232-2090

David Mooney/Maxine Heller wrote:
> Thanks, John, for continuing to look at this--
> 
> kout linseg is supposed to be an overall envelope that fades over the p3 
> value of the "note" in the score, not for each iteration generated by 
> the reinit loop. kout works when I put in some absolute value--the many 
> iterations fade nicely with aout*kout
> 
> However, in reading over your replies, I thought of a completely 
> different way of getting a fade that works. Instead of an overall 
> envelope, use the incrementing value to reduce the amp of each iteration 
> once the critical value (idur=.005) is reached. This works:
> 
> iamp    =       p4
> ...
> idur    =       p7
> ifadeadd init   0
> 
> loop:
> ...
> kamp    linseg  0,idur*.1,iamp,idur*.9,0        ;envelope for each 
> iteration,
>                                                 ;smooth tone when idur 
> long,
>                                                 ;no clicking when it's 
> short
> ifadeadd =      (idur>.005 ? 0:iamp*.005)
> iamp    =       iamp-ifadeadd
> 
>         timout  0,idur,contin
>         reinit  loop
> 
> contin:
>         rireturn
> a1      oscili  kamp,kfrq,1
>         out     a1
> 
> The ".005" value in the conditional would need to be adjusted according 
> to p3 so that the overall "note" fades during p3, but the principle is 
> here. Thanks again--you made me think differently which is always 
> appreciated.
> 
> At 04:58 PM 8/31/2007, you wrote:
>> After looking at how some of the values in your example accumulate, I 
>> think the problem is with your linseg arguments.  You use
>> kout linseg 1, p3-ifade, 1,...
>>
>> Since p3 is 10 in your example, kout will stay at 1 until p3-ifade 
>> seconds.  ifade is 0 until idur drops to .005, which means that ifade 
>> will need to reach a total value of 10 before the linseg will ever get 
>> a chance to fade (after 2000 iterations). Furthermore, since ifade 
>> moves by .005 increments, the next reinit will give ifade a value of 
>> 10.005, giving linseg a negative time duration.  This is not likely 
>> what you want.
>>
>> Perhaps it would work better if your linseg statement was
>> kout linseg 1, idur-ifade, 1, ifade, 0
>>
>> ifade should also be strictly smaller than idur.
>> And, as I previously mentioned, linseg should be in the reinit loop.
>>
>> Also, a note duration of .005 seconds seems a little short for the 
>> length of fade to be very perceptible.  You may want to increase the 
>> threshold for idur and ifadeadd to something larger.
>>
>> John W. Lato
>> School of Music
>> The University of Texas at Austin
>> 1 University Station E3100
>> Austin, TX 78712-0435
>> (512) 232-2090
>>
>> David Mooney/Maxine Heller wrote:
>>> Thanks, John--
>>> I understand what you are saying and did try this--tried it again to 
>>> be sure. The linseg behaves the same whether in or out of the reinit 
>>> portion of the orc. It behaves as though ifade is NOT incrementing, 
>>> but stays at its initial value of 0. Could it be something about the 
>>> way linseg operates?
>>> Anyhow, I can use print to get ifade values then just put them in the 
>>> score as another p field and so get the sound I want, but it would be 
>>> nice to generate it automatically.
>>> I'm fairly new to Csound and progress is glacial among other 
>>> concerns. I suspect there's an easy answer out there waiting for me 
>>> to stumble upon it.
>>> At 03:11 PM 8/29/2007, you wrote:
>>>> When an opcode is initialized (at i-time), it sets the values for 
>>>> any i-time arguments and doesn't read them again unless it is itself 
>>>> reinitialized.  Any opcode or calculation that is supposed to use 
>>>> the reinit'ed value of an i-rate var must also be reinited.  So if 
>>>> you put your linseg inside the reinit loop it should work. That's 
>>>> also why the second 'print ifade' always prints 0.  It prints the 
>>>> value of ifade only the first time it is encountered, when 
>>>> ifade==0.  Since the print isn't reinit'ed, it doesn't print 
>>>> anything else even though the value of ifade has changed.
>>>>
>>>> John W. Lato
>>>> School of Music
>>>> The University of Texas at Austin
>>>> 1 University Station E3100
>>>> Austin, TX 78712-0435
>>>> (512) 232-2090
>>>>
>>>> David Mooney/Maxine Heller wrote:
>>>>> Hi all--I'm stuck--
>>>>> Is there a way to get a variable out of a reinit loop for use after 
>>>>> rireturn? This seems like something that ought to be possible. 
>>>>> Making the variable global sort of works when more instances are 
>>>>> added to the score but the values below rireturn don't match those 
>>>>> inside reinit. Are variables reinitialized to their original values 
>>>>> upon exiting reinit? If so, is there a way to prevent it?
>>>>> Here's an example:
>>>>> sr      =       44100
>>>>> kr      =       4410
>>>>> ksmps   =       10
>>>>> nchnls =        1
>>>>>         instr 1
>>>>> iamp   =        p4
>>>>> ifrq    =       p5
>>>>> idur    =       p7
>>>>> ifade   init    0
>>>>> ifadeadd init   0
>>>>> loop:
>>>>> idur    =       idur-(idur*.02)
>>>>> idur    =       (idur>.005 ? idur:.005)
>>>>> ifadeadd =     (idur>.005 ? 0:.005)
>>>>> ifade  =        ifade+ifadeadd
>>>>>         ;print ifade      ;shows correct incremented value,
>>>>>                          ;about 5 seconds for values in score
>>>>>         timout  0,idur,contin
>>>>>         reinit  loop
>>>>> contin:
>>>>>         rireturn
>>>>>         ;print ifade      ;shows ifade=0
>>>>> a1      oscili  iamp,ifrq,1
>>>>> kout    linseg  1,p3-ifade,1,ifade,0
>>>>>         out     a1*kout   ;sound plays but no fade
>>>>>         endin
>>>>> [score]
>>>>> f1      0       4096    10      1
>>>>> ;p1     p2      p3      p4      p5      p6      p7
>>>>> i1      0       10      15000   200     0       .1
>>>>>
>>>>> Thanks in advance for any suggestions--
>>>>>
>>>>> David Mooney:  dmooney@city-net.com
>>>>> Maxine Heller:  mheller@city-net.com
>>>>> Opaque Melodies:  www.city-net.com/~moko/
>>>> -- 
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>> David Mooney:  dmooney@city-net.com
>>> Maxine Heller:  mheller@city-net.com
>>> Opaque Melodies:  www.city-net.com/~moko/
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> David Mooney:  dmooney@city-net.com
> Maxine Heller:  mheller@city-net.com
> Opaque Melodies:  www.city-net.com/~moko/
> 

I just noticed this when trying to run sndinfo. I scanned this forum but
missed this thread, for some reason. In any case, wrote a report into the
sourceforge bug list.

(Thanks again Steven for a way to fix this annoyance.)


Adam Chennells wrote:
> 
> 
> Great.  After moving widgets.dll from OPCODEDIR to elsewhere,  
> no error reported.  
> 
> Pvoc and the pvx file is now working too. 
> 
> FYI: This just leaves the warnings; 
> ... csladspa.dll
> ... csnd.dll
> ... scoregen.dll 
> 	  is/are not a Csound plugin library. 
> 
> Which I can live with.  
> 
> Fantastic.  Many thanks. 
> 
> 
> 
> Steven Yi wrote:
>> Hi All,
>>
>> Using the binary installer version from SourceForge I get the problem.
>>    Using a freshly compiled one from CVS I do not have the problem.
>> Perhaps it was fixed in CVS or something is off.  The problem running
>> in gdb with the installer version was on module destroy of the FLTK
>> widgets library dll.  If you're using the installer version, you can
>> try removing widgets.dll from your OPDCODEDIR to see if you still get
>> the error; if so then it's a different error than I was getting.
>> Otherwise, not sure what is going on with the installer version.
>>
>> steven
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/segmentation-violation-on-XP-tf4291044.html#a12511524
Sent from the Csound - General mailing list archive at Nabble.com.