I have found that there is now a big slowdown in csoundScoreEvent as
compared to prior versions of Csound.

The slowdown shows up for me as I call csoundScoreEvent from
csound.node when a JavaScript function inserts Csound "i" statements
into a real-time performance. Each event takes many seconds or what
seems like a minute or so to insert. I have proved that the slowdown
is not caused by csound.node code in jscsound.cpp or by my JavaScript
code by commenting out only the csoundScoreEvent call in jscsound.cpp.
In that case the performance runs smoothly (Csound is still running
with the same always on instruments etc. in this case).

Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.

There is no problem with regular command-line Csound.

I will attempt to provide a simple example to reproduce the problem,
but I wanted to mention this first. I know that the score handling
code in Csound has been changed recently.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com

I just ran this Python program and could find no issue. It played as expected.

===================
import csnd6
import time

cs = csnd6.Csound()
cs.SetOption('-odac')
cs.CompileOrc('''
instr 1
k1 expon 1,p3,0.001
a1 oscili p4,cpspch(p5)
   out a1*k1
endin
''')
cs.Start()
perf = csnd6.CsoundPerformanceThread(cs)
perf.Play()
i = 0
while i < 12:
  str = "i1 0 1 16000 %f " %  (8+i/100.)
  cs.InputMessage(str)
  print str
  time.sleep(0.1)
  i+=1
time.sleep(1)
perf.Stop()
perf.Join()
=================

Is it something else you’re reporting?

========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
> 
> I have found that there is now a big slowdown in csoundScoreEvent as
> compared to prior versions of Csound.
> 
> The slowdown shows up for me as I call csoundScoreEvent from
> csound.node when a JavaScript function inserts Csound "i" statements
> into a real-time performance. Each event takes many seconds or what
> seems like a minute or so to insert. I have proved that the slowdown
> is not caused by csound.node code in jscsound.cpp or by my JavaScript
> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
> In that case the performance runs smoothly (Csound is still running
> with the same always on instruments etc. in this case).
> 
> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
> 
> There is no problem with regular command-line Csound.
> 
> I will attempt to provide a simple example to reproduce the problem,
> but I wanted to mention this first. I know that the score handling
> code in Csound has been changed recently.
> 
> Regards,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com

My case is not comparable to your test because csound.node does not
use the Csound performance thread class. I may change csound.node to
do so, or I may modify my thread to handle events similarly to the
performance thread class.

I have proved that for csound.node, if I remove the csound->API_lock
mutex in csoundScoreEvent, it works beautifully, so there is some
thread mixup somewhere.

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
 wrote:
> I just ran this Python program and could find no issue. It played as expected.
>
> ===================
> import csnd6
> import time
>
> cs = csnd6.Csound()
> cs.SetOption('-odac')
> cs.CompileOrc('''
> instr 1
> k1 expon 1,p3,0.001
> a1 oscili p4,cpspch(p5)
>    out a1*k1
> endin
> ''')
> cs.Start()
> perf = csnd6.CsoundPerformanceThread(cs)
> perf.Play()
> i = 0
> while i < 12:
>   str = "i1 0 1 16000 %f " %  (8+i/100.)
>   cs.InputMessage(str)
>   print str
>   time.sleep(0.1)
>   i+=1
> time.sleep(1)
> perf.Stop()
> perf.Join()
> =================
>
> Is it something else you’re reporting?
>
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
>>
>> I have found that there is now a big slowdown in csoundScoreEvent as
>> compared to prior versions of Csound.
>>
>> The slowdown shows up for me as I call csoundScoreEvent from
>> csound.node when a JavaScript function inserts Csound "i" statements
>> into a real-time performance. Each event takes many seconds or what
>> seems like a minute or so to insert. I have proved that the slowdown
>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
>> In that case the performance runs smoothly (Csound is still running
>> with the same always on instruments etc. in this case).
>>
>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
>>
>> There is no problem with regular command-line Csound.
>>
>> I will attempt to provide a simple example to reproduce the problem,
>> but I wanted to mention this first. I know that the score handling
>> code in Csound has been changed recently.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com

Note that I am not sending events through the PerformanceThread class, but
directly to Csound. So it’s not using that mechanism, but plain Csound::InputMessage(),
and that is subject to the API lock, from threadsafe.c:

void csoundInputMessage(CSOUND *csound, const char *message){
    csoundLockMutex(csound->API_lock);
    csoundInputMessageInternal(csound, message);
    csoundUnlockMutex(csound->API_lock);
}

Regards
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 14 Apr 2016, at 09:09, Michael Gogins  wrote:
> 
> My case is not comparable to your test because csound.node does not
> use the Csound performance thread class. I may change csound.node to
> do so, or I may modify my thread to handle events similarly to the
> performance thread class.
> 
> I have proved that for csound.node, if I remove the csound->API_lock
> mutex in csoundScoreEvent, it works beautifully, so there is some
> thread mixup somewhere.
> 
> Best,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
>  wrote:
>> I just ran this Python program and could find no issue. It played as expected.
>> 
>> ===================
>> import csnd6
>> import time
>> 
>> cs = csnd6.Csound()
>> cs.SetOption('-odac')
>> cs.CompileOrc('''
>> instr 1
>> k1 expon 1,p3,0.001
>> a1 oscili p4,cpspch(p5)
>>   out a1*k1
>> endin
>> ''')
>> cs.Start()
>> perf = csnd6.CsoundPerformanceThread(cs)
>> perf.Play()
>> i = 0
>> while i < 12:
>>  str = "i1 0 1 16000 %f " %  (8+i/100.)
>>  cs.InputMessage(str)
>>  print str
>>  time.sleep(0.1)
>>  i+=1
>> time.sleep(1)
>> perf.Stop()
>> perf.Join()
>> =================
>> 
>> Is it something else you’re reporting?
>> 
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
>>> 
>>> I have found that there is now a big slowdown in csoundScoreEvent as
>>> compared to prior versions of Csound.
>>> 
>>> The slowdown shows up for me as I call csoundScoreEvent from
>>> csound.node when a JavaScript function inserts Csound "i" statements
>>> into a real-time performance. Each event takes many seconds or what
>>> seems like a minute or so to insert. I have proved that the slowdown
>>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
>>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
>>> In that case the performance runs smoothly (Csound is still running
>>> with the same always on instruments etc. in this case).
>>> 
>>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
>>> 
>>> There is no problem with regular command-line Csound.
>>> 
>>> I will attempt to provide a simple example to reproduce the problem,
>>> but I wanted to mention this first. I know that the score handling
>>> code in Csound has been changed recently.
>>> 
>>> Regards,
>>> Mike
>>> 
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com

In fact, I also tried with ScoreEvent(), and it works in a similar way:

import csnd6
import time

cs = csnd6.Csound()
cs.SetOption('-odac')
cs.CompileOrc('''
instr 1
k1 expon 1,p3,0.001
a1 oscili p4,cpspch(p5)
   out a1*k1
endin
''')
cs.Start()
perf = csnd6.CsoundPerformanceThread(cs)
perf.Play()
i = 0
arr = csnd6.CsoundMYFLTArray(5)
arr.SetValues(0, 1.0, 0, 1.0, 16000.)
while i < 12:
  arr.SetValue(4, (8+i/100.))
  cs.ScoreEvent("i", arr.GetPtr(0), 5)
  print str
  time.sleep(0.1)
  i+=1
time.sleep(1)
perf.Stop()
perf.Join()

========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 14 Apr 2016, at 09:29, Victor Lazzarini  wrote:
> 
> Note that I am not sending events through the PerformanceThread class, but
> directly to Csound. So it’s not using that mechanism, but plain Csound::InputMessage(),
> and that is subject to the API lock, from threadsafe.c:
> 
> void csoundInputMessage(CSOUND *csound, const char *message){
>    csoundLockMutex(csound->API_lock);
>    csoundInputMessageInternal(csound, message);
>    csoundUnlockMutex(csound->API_lock);
> }
> 
> Regards
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 14 Apr 2016, at 09:09, Michael Gogins  wrote:
>> 
>> My case is not comparable to your test because csound.node does not
>> use the Csound performance thread class. I may change csound.node to
>> do so, or I may modify my thread to handle events similarly to the
>> performance thread class.
>> 
>> I have proved that for csound.node, if I remove the csound->API_lock
>> mutex in csoundScoreEvent, it works beautifully, so there is some
>> thread mixup somewhere.
>> 
>> Best,
>> Mike
>> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>> 
>> 
>> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
>>  wrote:
>>> I just ran this Python program and could find no issue. It played as expected.
>>> 
>>> ===================
>>> import csnd6
>>> import time
>>> 
>>> cs = csnd6.Csound()
>>> cs.SetOption('-odac')
>>> cs.CompileOrc('''
>>> instr 1
>>> k1 expon 1,p3,0.001
>>> a1 oscili p4,cpspch(p5)
>>>  out a1*k1
>>> endin
>>> ''')
>>> cs.Start()
>>> perf = csnd6.CsoundPerformanceThread(cs)
>>> perf.Play()
>>> i = 0
>>> while i < 12:
>>> str = "i1 0 1 16000 %f " %  (8+i/100.)
>>> cs.InputMessage(str)
>>> print str
>>> time.sleep(0.1)
>>> i+=1
>>> time.sleep(1)
>>> perf.Stop()
>>> perf.Join()
>>> =================
>>> 
>>> Is it something else you’re reporting?
>>> 
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
>>>> 
>>>> I have found that there is now a big slowdown in csoundScoreEvent as
>>>> compared to prior versions of Csound.
>>>> 
>>>> The slowdown shows up for me as I call csoundScoreEvent from
>>>> csound.node when a JavaScript function inserts Csound "i" statements
>>>> into a real-time performance. Each event takes many seconds or what
>>>> seems like a minute or so to insert. I have proved that the slowdown
>>>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
>>>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
>>>> In that case the performance runs smoothly (Csound is still running
>>>> with the same always on instruments etc. in this case).
>>>> 
>>>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
>>>> 
>>>> There is no problem with regular command-line Csound.
>>>> 
>>>> I will attempt to provide a simple example to reproduce the problem,
>>>> but I wanted to mention this first. I know that the score handling
>>>> code in Csound has been changed recently.
>>>> 
>>>> Regards,
>>>> Mike
>>>> 
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com

Obviously what you both say is true, yet equally obviously there absolutely is a problem when I use the same approach, which therefore must not really be the same approach. I have a simple solution that I am trying.

Best,
Mike

If you had a C++ program that showed the issue, we could debug. I am just concerned because the API lock is important for the
threadsafe operation we introduced in the Csound 6 API.

========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 14 Apr 2016, at 10:58, Michael Gogins  wrote:
> 
> Obviously what you both say is true, yet equally obviously there absolutely is a problem when I use the same approach, which therefore must not really be the same approach. I have a simple solution that I am trying.
> 
> Best,
> Mike
> 
> On Apr 14, 2016 12:49 PM, "Rory Walsh"  wrote:
> BTW, I'm not using CsoundPerformanceThread at all. 
> 
> On 14 April 2016 at 10:48, Rory Walsh  wrote:
> I use csoundInputMessage quite a lot in Cabbage for generating tables on the fly. I just tested some of my more InputMessage hungry instruments and I'm not seeing any problems. 
> 
> On 14 April 2016 at 09:45, Victor Lazzarini  wrote:
> In fact, I also tried with ScoreEvent(), and it works in a similar way:
> 
> import csnd6
> import time
> 
> cs = csnd6.Csound()
> cs.SetOption('-odac')
> cs.CompileOrc('''
> instr 1
> k1 expon 1,p3,0.001
> a1 oscili p4,cpspch(p5)
>    out a1*k1
> endin
> ''')
> cs.Start()
> perf = csnd6.CsoundPerformanceThread(cs)
> perf.Play()
> i = 0
> arr = csnd6.CsoundMYFLTArray(5)
> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
> while i < 12:
>   arr.SetValue(4, (8+i/100.))
>   cs.ScoreEvent("i", arr.GetPtr(0), 5)
>   print str
>   time.sleep(0.1)
>   i+=1
> time.sleep(1)
> perf.Stop()
> perf.Join()
> 
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
> 
> > On 14 Apr 2016, at 09:29, Victor Lazzarini  wrote:
> >
> > Note that I am not sending events through the PerformanceThread class, but
> > directly to Csound. So it’s not using that mechanism, but plain Csound::InputMessage(),
> > and that is subject to the API lock, from threadsafe.c:
> >
> > void csoundInputMessage(CSOUND *csound, const char *message){
> >    csoundLockMutex(csound->API_lock);
> >    csoundInputMessageInternal(csound, message);
> >    csoundUnlockMutex(csound->API_lock);
> > }
> >
> > Regards
> > ========================
> > Dr Victor Lazzarini
> > Dean of Arts, Celtic Studies and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> >> On 14 Apr 2016, at 09:09, Michael Gogins  wrote:
> >>
> >> My case is not comparable to your test because csound.node does not
> >> use the Csound performance thread class. I may change csound.node to
> >> do so, or I may modify my thread to handle events similarly to the
> >> performance thread class.
> >>
> >> I have proved that for csound.node, if I remove the csound->API_lock
> >> mutex in csoundScoreEvent, it works beautifully, so there is some
> >> thread mixup somewhere.
> >>
> >> Best,
> >> Mike
> >>
> >> -----------------------------------------------------
> >> Michael Gogins
> >> Irreducible Productions
> >> http://michaelgogins.tumblr.com
> >> Michael dot Gogins at gmail dot com
> >>
> >>
> >> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
> >>  wrote:
> >>> I just ran this Python program and could find no issue. It played as expected.
> >>>
> >>> ===================
> >>> import csnd6
> >>> import time
> >>>
> >>> cs = csnd6.Csound()
> >>> cs.SetOption('-odac')
> >>> cs.CompileOrc('''
> >>> instr 1
> >>> k1 expon 1,p3,0.001
> >>> a1 oscili p4,cpspch(p5)
> >>>  out a1*k1
> >>> endin
> >>> ''')
> >>> cs.Start()
> >>> perf = csnd6.CsoundPerformanceThread(cs)
> >>> perf.Play()
> >>> i = 0
> >>> while i < 12:
> >>> str = "i1 0 1 16000 %f " %  (8+i/100.)
> >>> cs.InputMessage(str)
> >>> print str
> >>> time.sleep(0.1)
> >>> i+=1
> >>> time.sleep(1)
> >>> perf.Stop()
> >>> perf.Join()
> >>> =================
> >>>
> >>> Is it something else you’re reporting?
> >>>
> >>> ========================
> >>> Dr Victor Lazzarini
> >>> Dean of Arts, Celtic Studies and Philosophy,
> >>> Maynooth University,
> >>> Maynooth, Co Kildare, Ireland
> >>> Tel: 00 353 7086936
> >>> Fax: 00 353 1 7086952
> >>>
> >>>> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
> >>>>
> >>>> I have found that there is now a big slowdown in csoundScoreEvent as
> >>>> compared to prior versions of Csound.
> >>>>
> >>>> The slowdown shows up for me as I call csoundScoreEvent from
> >>>> csound.node when a JavaScript function inserts Csound "i" statements
> >>>> into a real-time performance. Each event takes many seconds or what
> >>>> seems like a minute or so to insert. I have proved that the slowdown
> >>>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
> >>>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
> >>>> In that case the performance runs smoothly (Csound is still running
> >>>> with the same always on instruments etc. in this case).
> >>>>
> >>>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
> >>>>
> >>>> There is no problem with regular command-line Csound.
> >>>>
> >>>> I will attempt to provide a simple example to reproduce the problem,
> >>>> but I wanted to mention this first. I know that the score handling
> >>>> code in Csound has been changed recently.
> >>>>
> >>>> Regards,
> >>>> Mike
> >>>>
> >>>> -----------------------------------------------------
> >>>> Michael Gogins
> >>>> Irreducible Productions
> >>>> http://michaelgogins.tumblr.com
> >>>> Michael dot Gogins at gmail dot com
> 

I have of course left the API lock in csoundScoreEvent just as it was,
not to worry. I removed it temporarily to see if it was causing a
problem for me, and it was, so I put it back. I have pushed no changes
to Csound code or to Csound interfaces code. The only changes I have
pushed are in csound.node code, where I added some lockfree queues in
jscsound.cpp to get score fragments and score events into the
performance thread routine's perform ksmps loop without depending on
the API_lock to be working properly. This solution works fine and I am
moving on from this issue.

However, I think this demonstrates that there are subtle problems with
threading and the API in Csound. For now I think we just have to keep
our eyes open for similar problems. It might be useful to run valgrind
on this, and when I get back to my Linux computer I may run my piece
with the old code and valgrind to see if there are any data races or
anything. That's assuming of course that this is not Windows-specific.

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Apr 14, 2016 at 1:58 PM, Victor Lazzarini
 wrote:
> If you had a C++ program that showed the issue, we could debug. I am just concerned because the API lock is important for the
> threadsafe operation we introduced in the Csound 6 API.
>
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 14 Apr 2016, at 10:58, Michael Gogins  wrote:
>>
>> Obviously what you both say is true, yet equally obviously there absolutely is a problem when I use the same approach, which therefore must not really be the same approach. I have a simple solution that I am trying.
>>
>> Best,
>> Mike
>>
>> On Apr 14, 2016 12:49 PM, "Rory Walsh"  wrote:
>> BTW, I'm not using CsoundPerformanceThread at all.
>>
>> On 14 April 2016 at 10:48, Rory Walsh  wrote:
>> I use csoundInputMessage quite a lot in Cabbage for generating tables on the fly. I just tested some of my more InputMessage hungry instruments and I'm not seeing any problems.
>>
>> On 14 April 2016 at 09:45, Victor Lazzarini  wrote:
>> In fact, I also tried with ScoreEvent(), and it works in a similar way:
>>
>> import csnd6
>> import time
>>
>> cs = csnd6.Csound()
>> cs.SetOption('-odac')
>> cs.CompileOrc('''
>> instr 1
>> k1 expon 1,p3,0.001
>> a1 oscili p4,cpspch(p5)
>>    out a1*k1
>> endin
>> ''')
>> cs.Start()
>> perf = csnd6.CsoundPerformanceThread(cs)
>> perf.Play()
>> i = 0
>> arr = csnd6.CsoundMYFLTArray(5)
>> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
>> while i < 12:
>>   arr.SetValue(4, (8+i/100.))
>>   cs.ScoreEvent("i", arr.GetPtr(0), 5)
>>   print str
>>   time.sleep(0.1)
>>   i+=1
>> time.sleep(1)
>> perf.Stop()
>> perf.Join()
>>
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>> > On 14 Apr 2016, at 09:29, Victor Lazzarini  wrote:
>> >
>> > Note that I am not sending events through the PerformanceThread class, but
>> > directly to Csound. So it’s not using that mechanism, but plain Csound::InputMessage(),
>> > and that is subject to the API lock, from threadsafe.c:
>> >
>> > void csoundInputMessage(CSOUND *csound, const char *message){
>> >    csoundLockMutex(csound->API_lock);
>> >    csoundInputMessageInternal(csound, message);
>> >    csoundUnlockMutex(csound->API_lock);
>> > }
>> >
>> > Regards
>> > ========================
>> > Dr Victor Lazzarini
>> > Dean of Arts, Celtic Studies and Philosophy,
>> > Maynooth University,
>> > Maynooth, Co Kildare, Ireland
>> > Tel: 00 353 7086936
>> > Fax: 00 353 1 7086952
>> >
>> >> On 14 Apr 2016, at 09:09, Michael Gogins  wrote:
>> >>
>> >> My case is not comparable to your test because csound.node does not
>> >> use the Csound performance thread class. I may change csound.node to
>> >> do so, or I may modify my thread to handle events similarly to the
>> >> performance thread class.
>> >>
>> >> I have proved that for csound.node, if I remove the csound->API_lock
>> >> mutex in csoundScoreEvent, it works beautifully, so there is some
>> >> thread mixup somewhere.
>> >>
>> >> Best,
>> >> Mike
>> >>
>> >> -----------------------------------------------------
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
>> >>  wrote:
>> >>> I just ran this Python program and could find no issue. It played as expected.
>> >>>
>> >>> ===================
>> >>> import csnd6
>> >>> import time
>> >>>
>> >>> cs = csnd6.Csound()
>> >>> cs.SetOption('-odac')
>> >>> cs.CompileOrc('''
>> >>> instr 1
>> >>> k1 expon 1,p3,0.001
>> >>> a1 oscili p4,cpspch(p5)
>> >>>  out a1*k1
>> >>> endin
>> >>> ''')
>> >>> cs.Start()
>> >>> perf = csnd6.CsoundPerformanceThread(cs)
>> >>> perf.Play()
>> >>> i = 0
>> >>> while i < 12:
>> >>> str = "i1 0 1 16000 %f " %  (8+i/100.)
>> >>> cs.InputMessage(str)
>> >>> print str
>> >>> time.sleep(0.1)
>> >>> i+=1
>> >>> time.sleep(1)
>> >>> perf.Stop()
>> >>> perf.Join()
>> >>> =================
>> >>>
>> >>> Is it something else you’re reporting?
>> >>>
>> >>> ========================
>> >>> Dr Victor Lazzarini
>> >>> Dean of Arts, Celtic Studies and Philosophy,
>> >>> Maynooth University,
>> >>> Maynooth, Co Kildare, Ireland
>> >>> Tel: 00 353 7086936
>> >>> Fax: 00 353 1 7086952
>> >>>
>> >>>> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
>> >>>>
>> >>>> I have found that there is now a big slowdown in csoundScoreEvent as
>> >>>> compared to prior versions of Csound.
>> >>>>
>> >>>> The slowdown shows up for me as I call csoundScoreEvent from
>> >>>> csound.node when a JavaScript function inserts Csound "i" statements
>> >>>> into a real-time performance. Each event takes many seconds or what
>> >>>> seems like a minute or so to insert. I have proved that the slowdown
>> >>>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
>> >>>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
>> >>>> In that case the performance runs smoothly (Csound is still running
>> >>>> with the same always on instruments etc. in this case).
>> >>>>
>> >>>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
>> >>>>
>> >>>> There is no problem with regular command-line Csound.
>> >>>>
>> >>>> I will attempt to provide a simple example to reproduce the problem,
>> >>>> but I wanted to mention this first. I know that the score handling
>> >>>> code in Csound has been changed recently.
>> >>>>
>> >>>> Regards,
>> >>>> Mike
>> >>>>
>> >>>> -----------------------------------------------------
>> >>>> Michael Gogins
>> >>>> Irreducible Productions
>> >>>> http://michaelgogins.tumblr.com
>> >>>> Michael dot Gogins at gmail dot com
>>

How can I test this? I have no idea how to run it.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 14 Apr 2016, at 13:34, Tarmo Johannes  wrote:
> 
> Hi,
> 
> I have noticed, too, lags with CsoundQt, Csound64-bit and windows - for example sarting instruments wiht html-button or button widget in CsoundQt -  after click, I see a message in console immediately but the sound comes out about 0.1 seconds later.
> 
> for example:
> 
> 
> 
> 
> 
> 
> 
 My html
> TEST



> 
> 
> 
> 
> instr 1
>   ivalue = p4
>   print ivalue
>   out poscil(0.1,random:i(100,1000))
> endin
> 
> 
> tarmo
> 
> 
> 
> 
> 2016-04-14 14:27 GMT+03:00 Michael Gogins :
> I have of course left the API lock in csoundScoreEvent just as it was,
> not to worry. I removed it temporarily to see if it was causing a
> problem for me, and it was, so I put it back. I have pushed no changes
> to Csound code or to Csound interfaces code. The only changes I have
> pushed are in csound.node code, where I added some lockfree queues in
> jscsound.cpp to get score fragments and score events into the
> performance thread routine's perform ksmps loop without depending on
> the API_lock to be working properly. This solution works fine and I am
> moving on from this issue.
> 
> However, I think this demonstrates that there are subtle problems with
> threading and the API in Csound. For now I think we just have to keep
> our eyes open for similar problems. It might be useful to run valgrind
> on this, and when I get back to my Linux computer I may run my piece
> with the old code and valgrind to see if there are any data races or
> anything. That's assuming of course that this is not Windows-specific.
> 
> Best,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Thu, Apr 14, 2016 at 1:58 PM, Victor Lazzarini
>  wrote:
> > If you had a C++ program that showed the issue, we could debug. I am just concerned because the API lock is important for the
> > threadsafe operation we introduced in the Csound 6 API.
> >
> > ========================
> > Dr Victor Lazzarini
> > Dean of Arts, Celtic Studies and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> >> On 14 Apr 2016, at 10:58, Michael Gogins  wrote:
> >>
> >> Obviously what you both say is true, yet equally obviously there absolutely is a problem when I use the same approach, which therefore must not really be the same approach. I have a simple solution that I am trying.
> >>
> >> Best,
> >> Mike
> >>
> >> On Apr 14, 2016 12:49 PM, "Rory Walsh"  wrote:
> >> BTW, I'm not using CsoundPerformanceThread at all.
> >>
> >> On 14 April 2016 at 10:48, Rory Walsh  wrote:
> >> I use csoundInputMessage quite a lot in Cabbage for generating tables on the fly. I just tested some of my more InputMessage hungry instruments and I'm not seeing any problems.
> >>
> >> On 14 April 2016 at 09:45, Victor Lazzarini  wrote:
> >> In fact, I also tried with ScoreEvent(), and it works in a similar way:
> >>
> >> import csnd6
> >> import time
> >>
> >> cs = csnd6.Csound()
> >> cs.SetOption('-odac')
> >> cs.CompileOrc('''
> >> instr 1
> >> k1 expon 1,p3,0.001
> >> a1 oscili p4,cpspch(p5)
> >>    out a1*k1
> >> endin
> >> ''')
> >> cs.Start()
> >> perf = csnd6.CsoundPerformanceThread(cs)
> >> perf.Play()
> >> i = 0
> >> arr = csnd6.CsoundMYFLTArray(5)
> >> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
> >> while i < 12:
> >>   arr.SetValue(4, (8+i/100.))
> >>   cs.ScoreEvent("i", arr.GetPtr(0), 5)
> >>   print str
> >>   time.sleep(0.1)
> >>   i+=1
> >> time.sleep(1)
> >> perf.Stop()
> >> perf.Join()
> >>
> >> ========================
> >> Dr Victor Lazzarini
> >> Dean of Arts, Celtic Studies and Philosophy,
> >> Maynooth University,
> >> Maynooth, Co Kildare, Ireland
> >> Tel: 00 353 7086936
> >> Fax: 00 353 1 7086952
> >>
> >> > On 14 Apr 2016, at 09:29, Victor Lazzarini  wrote:
> >> >
> >> > Note that I am not sending events through the PerformanceThread class, but
> >> > directly to Csound. So it’s not using that mechanism, but plain Csound::InputMessage(),
> >> > and that is subject to the API lock, from threadsafe.c:
> >> >
> >> > void csoundInputMessage(CSOUND *csound, const char *message){
> >> >    csoundLockMutex(csound->API_lock);
> >> >    csoundInputMessageInternal(csound, message);
> >> >    csoundUnlockMutex(csound->API_lock);
> >> > }
> >> >
> >> > Regards
> >> > ========================
> >> > Dr Victor Lazzarini
> >> > Dean of Arts, Celtic Studies and Philosophy,
> >> > Maynooth University,
> >> > Maynooth, Co Kildare, Ireland
> >> > Tel: 00 353 7086936
> >> > Fax: 00 353 1 7086952
> >> >
> >> >> On 14 Apr 2016, at 09:09, Michael Gogins  wrote:
> >> >>
> >> >> My case is not comparable to your test because csound.node does not
> >> >> use the Csound performance thread class. I may change csound.node to
> >> >> do so, or I may modify my thread to handle events similarly to the
> >> >> performance thread class.
> >> >>
> >> >> I have proved that for csound.node, if I remove the csound->API_lock
> >> >> mutex in csoundScoreEvent, it works beautifully, so there is some
> >> >> thread mixup somewhere.
> >> >>
> >> >> Best,
> >> >> Mike
> >> >>
> >> >> -----------------------------------------------------
> >> >> Michael Gogins
> >> >> Irreducible Productions
> >> >> http://michaelgogins.tumblr.com
> >> >> Michael dot Gogins at gmail dot com
> >> >>
> >> >>
> >> >> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
> >> >>  wrote:
> >> >>> I just ran this Python program and could find no issue. It played as expected.
> >> >>>
> >> >>> ===================
> >> >>> import csnd6
> >> >>> import time
> >> >>>
> >> >>> cs = csnd6.Csound()
> >> >>> cs.SetOption('-odac')
> >> >>> cs.CompileOrc('''
> >> >>> instr 1
> >> >>> k1 expon 1,p3,0.001
> >> >>> a1 oscili p4,cpspch(p5)
> >> >>>  out a1*k1
> >> >>> endin
> >> >>> ''')
> >> >>> cs.Start()
> >> >>> perf = csnd6.CsoundPerformanceThread(cs)
> >> >>> perf.Play()
> >> >>> i = 0
> >> >>> while i < 12:
> >> >>> str = "i1 0 1 16000 %f " %  (8+i/100.)
> >> >>> cs.InputMessage(str)
> >> >>> print str
> >> >>> time.sleep(0.1)
> >> >>> i+=1
> >> >>> time.sleep(1)
> >> >>> perf.Stop()
> >> >>> perf.Join()
> >> >>> =================
> >> >>>
> >> >>> Is it something else you’re reporting?
> >> >>>
> >> >>> ========================
> >> >>> Dr Victor Lazzarini
> >> >>> Dean of Arts, Celtic Studies and Philosophy,
> >> >>> Maynooth University,
> >> >>> Maynooth, Co Kildare, Ireland
> >> >>> Tel: 00 353 7086936
> >> >>> Fax: 00 353 1 7086952
> >> >>>
> >> >>>> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
> >> >>>>
> >> >>>> I have found that there is now a big slowdown in csoundScoreEvent as
> >> >>>> compared to prior versions of Csound.
> >> >>>>
> >> >>>> The slowdown shows up for me as I call csoundScoreEvent from
> >> >>>> csound.node when a JavaScript function inserts Csound "i" statements
> >> >>>> into a real-time performance. Each event takes many seconds or what
> >> >>>> seems like a minute or so to insert. I have proved that the slowdown
> >> >>>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
> >> >>>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
> >> >>>> In that case the performance runs smoothly (Csound is still running
> >> >>>> with the same always on instruments etc. in this case).
> >> >>>>
> >> >>>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
> >> >>>>
> >> >>>> There is no problem with regular command-line Csound.
> >> >>>>
> >> >>>> I will attempt to provide a simple example to reproduce the problem,
> >> >>>> but I wanted to mention this first. I know that the score handling
> >> >>>> code in Csound has been changed recently.
> >> >>>>
> >> >>>> Regards,
> >> >>>> Mike
> >> >>>>
> >> >>>> -----------------------------------------------------
> >> >>>> Michael Gogins
> >> >>>> Irreducible Productions
> >> >>>> http://michaelgogins.tumblr.com
> >> >>>> Michael dot Gogins at gmail dot com
> >>
> >>

On OSX, sound comes out immediately. Did you look at buffer sizes etc on windows? If it’s the MME backend that is being used,
I would not be surprised of this type of latency.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 14 Apr 2016, at 15:10, Tarmo Johannes  wrote:
> 
> Hi,
> 
> html5 support is currently only available for windows. But you can similar thing with attached csd in CsoundQt -  there is one button that triggeres event call (csoundInputMessage or similar in the code, I guess). On linux (and I think on OSX as well)  the sound comes out immediately, on windows with a lag. I will test later with 32-bit build on Windows.
> 
> tarmo
> 
> 2016-04-14 15:59 GMT+03:00 Victor Lazzarini :
> How can I test this? I have no idea how to run it.
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
> 
> > On 14 Apr 2016, at 13:34, Tarmo Johannes  wrote:
> >
> > Hi,
> >
> > I have noticed, too, lags with CsoundQt, Csound64-bit and windows - for example sarting instruments wiht html-button or button widget in CsoundQt -  after click, I see a message in console immediately but the sound comes out about 0.1 seconds later.
> >
> > for example:
> >
> > 
> > 
> > 
> > 
> > 
> > 
 My html
> > TEST



> > 
> > 
> > 
> >
> > instr 1
> >   ivalue = p4
> >   print ivalue
> >   out poscil(0.1,random:i(100,1000))
> > endin
> >
> >
> > tarmo
> >
> >
> >
> >
> > 2016-04-14 14:27 GMT+03:00 Michael Gogins :
> > I have of course left the API lock in csoundScoreEvent just as it was,
> > not to worry. I removed it temporarily to see if it was causing a
> > problem for me, and it was, so I put it back. I have pushed no changes
> > to Csound code or to Csound interfaces code. The only changes I have
> > pushed are in csound.node code, where I added some lockfree queues in
> > jscsound.cpp to get score fragments and score events into the
> > performance thread routine's perform ksmps loop without depending on
> > the API_lock to be working properly. This solution works fine and I am
> > moving on from this issue.
> >
> > However, I think this demonstrates that there are subtle problems with
> > threading and the API in Csound. For now I think we just have to keep
> > our eyes open for similar problems. It might be useful to run valgrind
> > on this, and when I get back to my Linux computer I may run my piece
> > with the old code and valgrind to see if there are any data races or
> > anything. That's assuming of course that this is not Windows-specific.
> >
> > Best,
> > Mike
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> >
> > On Thu, Apr 14, 2016 at 1:58 PM, Victor Lazzarini
> >  wrote:
> > > If you had a C++ program that showed the issue, we could debug. I am just concerned because the API lock is important for the
> > > threadsafe operation we introduced in the Csound 6 API.
> > >
> > > ========================
> > > Dr Victor Lazzarini
> > > Dean of Arts, Celtic Studies and Philosophy,
> > > Maynooth University,
> > > Maynooth, Co Kildare, Ireland
> > > Tel: 00 353 7086936
> > > Fax: 00 353 1 7086952
> > >
> > >> On 14 Apr 2016, at 10:58, Michael Gogins  wrote:
> > >>
> > >> Obviously what you both say is true, yet equally obviously there absolutely is a problem when I use the same approach, which therefore must not really be the same approach. I have a simple solution that I am trying.
> > >>
> > >> Best,
> > >> Mike
> > >>
> > >> On Apr 14, 2016 12:49 PM, "Rory Walsh"  wrote:
> > >> BTW, I'm not using CsoundPerformanceThread at all.
> > >>
> > >> On 14 April 2016 at 10:48, Rory Walsh  wrote:
> > >> I use csoundInputMessage quite a lot in Cabbage for generating tables on the fly. I just tested some of my more InputMessage hungry instruments and I'm not seeing any problems.
> > >>
> > >> On 14 April 2016 at 09:45, Victor Lazzarini  wrote:
> > >> In fact, I also tried with ScoreEvent(), and it works in a similar way:
> > >>
> > >> import csnd6
> > >> import time
> > >>
> > >> cs = csnd6.Csound()
> > >> cs.SetOption('-odac')
> > >> cs.CompileOrc('''
> > >> instr 1
> > >> k1 expon 1,p3,0.001
> > >> a1 oscili p4,cpspch(p5)
> > >>    out a1*k1
> > >> endin
> > >> ''')
> > >> cs.Start()
> > >> perf = csnd6.CsoundPerformanceThread(cs)
> > >> perf.Play()
> > >> i = 0
> > >> arr = csnd6.CsoundMYFLTArray(5)
> > >> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
> > >> while i < 12:
> > >>   arr.SetValue(4, (8+i/100.))
> > >>   cs.ScoreEvent("i", arr.GetPtr(0), 5)
> > >>   print str
> > >>   time.sleep(0.1)
> > >>   i+=1
> > >> time.sleep(1)
> > >> perf.Stop()
> > >> perf.Join()
> > >>
> > >> ========================
> > >> Dr Victor Lazzarini
> > >> Dean of Arts, Celtic Studies and Philosophy,
> > >> Maynooth University,
> > >> Maynooth, Co Kildare, Ireland
> > >> Tel: 00 353 7086936
> > >> Fax: 00 353 1 7086952
> > >>
> > >> > On 14 Apr 2016, at 09:29, Victor Lazzarini  wrote:
> > >> >
> > >> > Note that I am not sending events through the PerformanceThread class, but
> > >> > directly to Csound. So it’s not using that mechanism, but plain Csound::InputMessage(),
> > >> > and that is subject to the API lock, from threadsafe.c:
> > >> >
> > >> > void csoundInputMessage(CSOUND *csound, const char *message){
> > >> >    csoundLockMutex(csound->API_lock);
> > >> >    csoundInputMessageInternal(csound, message);
> > >> >    csoundUnlockMutex(csound->API_lock);
> > >> > }
> > >> >
> > >> > Regards
> > >> > ========================
> > >> > Dr Victor Lazzarini
> > >> > Dean of Arts, Celtic Studies and Philosophy,
> > >> > Maynooth University,
> > >> > Maynooth, Co Kildare, Ireland
> > >> > Tel: 00 353 7086936
> > >> > Fax: 00 353 1 7086952
> > >> >
> > >> >> On 14 Apr 2016, at 09:09, Michael Gogins  wrote:
> > >> >>
> > >> >> My case is not comparable to your test because csound.node does not
> > >> >> use the Csound performance thread class. I may change csound.node to
> > >> >> do so, or I may modify my thread to handle events similarly to the
> > >> >> performance thread class.
> > >> >>
> > >> >> I have proved that for csound.node, if I remove the csound->API_lock
> > >> >> mutex in csoundScoreEvent, it works beautifully, so there is some
> > >> >> thread mixup somewhere.
> > >> >>
> > >> >> Best,
> > >> >> Mike
> > >> >>
> > >> >> -----------------------------------------------------
> > >> >> Michael Gogins
> > >> >> Irreducible Productions
> > >> >> http://michaelgogins.tumblr.com
> > >> >> Michael dot Gogins at gmail dot com
> > >> >>
> > >> >>
> > >> >> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
> > >> >>  wrote:
> > >> >>> I just ran this Python program and could find no issue. It played as expected.
> > >> >>>
> > >> >>> ===================
> > >> >>> import csnd6
> > >> >>> import time
> > >> >>>
> > >> >>> cs = csnd6.Csound()
> > >> >>> cs.SetOption('-odac')
> > >> >>> cs.CompileOrc('''
> > >> >>> instr 1
> > >> >>> k1 expon 1,p3,0.001
> > >> >>> a1 oscili p4,cpspch(p5)
> > >> >>>  out a1*k1
> > >> >>> endin
> > >> >>> ''')
> > >> >>> cs.Start()
> > >> >>> perf = csnd6.CsoundPerformanceThread(cs)
> > >> >>> perf.Play()
> > >> >>> i = 0
> > >> >>> while i < 12:
> > >> >>> str = "i1 0 1 16000 %f " %  (8+i/100.)
> > >> >>> cs.InputMessage(str)
> > >> >>> print str
> > >> >>> time.sleep(0.1)
> > >> >>> i+=1
> > >> >>> time.sleep(1)
> > >> >>> perf.Stop()
> > >> >>> perf.Join()
> > >> >>> =================
> > >> >>>
> > >> >>> Is it something else you’re reporting?
> > >> >>>
> > >> >>> ========================
> > >> >>> Dr Victor Lazzarini
> > >> >>> Dean of Arts, Celtic Studies and Philosophy,
> > >> >>> Maynooth University,
> > >> >>> Maynooth, Co Kildare, Ireland
> > >> >>> Tel: 00 353 7086936
> > >> >>> Fax: 00 353 1 7086952
> > >> >>>
> > >> >>>> On 13 Apr 2016, at 19:49, Michael Gogins  wrote:
> > >> >>>>
> > >> >>>> I have found that there is now a big slowdown in csoundScoreEvent as
> > >> >>>> compared to prior versions of Csound.
> > >> >>>>
> > >> >>>> The slowdown shows up for me as I call csoundScoreEvent from
> > >> >>>> csound.node when a JavaScript function inserts Csound "i" statements
> > >> >>>> into a real-time performance. Each event takes many seconds or what
> > >> >>>> seems like a minute or so to insert. I have proved that the slowdown
> > >> >>>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
> > >> >>>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
> > >> >>>> In that case the performance runs smoothly (Csound is still running
> > >> >>>> with the same always on instruments etc. in this case).
> > >> >>>>
> > >> >>>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
> > >> >>>>
> > >> >>>> There is no problem with regular command-line Csound.
> > >> >>>>
> > >> >>>> I will attempt to provide a simple example to reproduce the problem,
> > >> >>>> but I wanted to mention this first. I know that the score handling
> > >> >>>> code in Csound has been changed recently.
> > >> >>>>
> > >> >>>> Regards,
> > >> >>>> Mike
> > >> >>>>
> > >> >>>> -----------------------------------------------------
> > >> >>>> Michael Gogins
> > >> >>>> Irreducible Productions
> > >> >>>> http://michaelgogins.tumblr.com
> > >> >>>> Michael dot Gogins at gmail dot com
> > >>
> > >>
> >
> 

Tested on Windows (7), CsounQt

- 32-bit build, self built CsoundQt 0.9.2.1 (Csound 6.07beta from mov 2015)

- CsoundQt  0.9.1 (the original one in last official installer),

- CsoundQt 64-bit, Csound 6.07

+ CsoundQt 64-bit 0.9.2.1, Csound 6.07 64-bit installed in another computer under wine.

all the same result - after button press a delay before sound comes out.

I had no other choice for audio driver as portaudio, no special buffer sizes set anywhere.

Anyway, the behaviour is the similar - no difference with older version or 32 bit.

Maybe it is irrelevant to Michaels problem and maybe I am doing something wrong on Windows. Just reported - please ignore if it seems not connected to the Csound -Node issue.

tarmo

2016-04-14 17:10 GMT+03:00 Tarmo Johannes <trmjhnns@gmail.com>:

Hi,

html5 support is currently only available for windows. But you can similar thing with attached csd in CsoundQt -  there is one button that triggeres event call (csoundInputMessage or similar in the code, I guess). On linux (and I think on OSX as well)  the sound comes out immediately, on windows with a lag. I will test later with 32-bit build on Windows.

tarmo

2016-04-14 15:59 GMT+03:00 Victor Lazzarini <Victor.Lazzarini@nuim.ie>:

How can I test this? I have no idea how to run it.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

> On 14 Apr 2016, at 13:34, Tarmo Johannes <trmjhnns@GMAIL.COM> wrote:
>
> Hi,
>
> I have noticed, too, lags with CsoundQt, Csound64-bit and windows - for example sarting instruments wiht html-button or button widget in CsoundQt -  after click, I see a message in console immediately but the sound comes out about 0.1 seconds later.
>
> for example:
>
> <CsHtml5>
> <!DOCTYPE html>
> <html>
> <head></head>
> <body>
> <h1> My html</h1>
> <button onclick='csound.readScore("i 1 0 1 1")'">TEST</button><br><br><br>
> </body>
> </html>
> </CsHtml5>
>
> instr 1
>   ivalue = p4
>   print ivalue
>   out poscil(0.1,random:i(100,1000))
> endin
>
>
> tarmo
>
>
>
>
> 2016-04-14 14:27 GMT+03:00 Michael Gogins <michael.gogins@gmail.com>:
> I have of course left the API lock in csoundScoreEvent just as it was,
> not to worry. I removed it temporarily to see if it was causing a
> problem for me, and it was, so I put it back. I have pushed no changes
> to Csound code or to Csound interfaces code. The only changes I have
> pushed are in csound.node code, where I added some lockfree queues in
> jscsound.cpp to get score fragments and score events into the
> performance thread routine's perform ksmps loop without depending on
> the API_lock to be working properly. This solution works fine and I am
> moving on from this issue.
>
> However, I think this demonstrates that there are subtle problems with
> threading and the API in Csound. For now I think we just have to keep
> our eyes open for similar problems. It might be useful to run valgrind
> on this, and when I get back to my Linux computer I may run my piece
> with the old code and valgrind to see if there are any data races or
> anything. That's assuming of course that this is not Windows-specific.
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Apr 14, 2016 at 1:58 PM, Victor Lazzarini
> <Victor.Lazzarini@nuim.ie> wrote:
> > If you had a C++ program that showed the issue, we could debug. I am just concerned because the API lock is important for the
> > threadsafe operation we introduced in the Csound 6 API.
> >
> > ========================
> > Dr Victor Lazzarini
> > Dean of Arts, Celtic Studies and Philosophy,
> > Maynooth University,
> > Maynooth, Co Kildare, Ireland
> > Tel: 00 353 7086936
> > Fax: 00 353 1 7086952
> >
> >> On 14 Apr 2016, at 10:58, Michael Gogins <michael.gogins@gmail.com> wrote:
> >>
> >> Obviously what you both say is true, yet equally obviously there absolutely is a problem when I use the same approach, which therefore must not really be the same approach. I have a simple solution that I am trying.
> >>
> >> Best,
> >> Mike
> >>
> >> On Apr 14, 2016 12:49 PM, "Rory Walsh" <rorywalsh@ear.ie> wrote:
> >> BTW, I'm not using CsoundPerformanceThread at all.
> >>
> >> On 14 April 2016 at 10:48, Rory Walsh <rorywalsh@ear.ie> wrote:
> >> I use csoundInputMessage quite a lot in Cabbage for generating tables on the fly. I just tested some of my more InputMessage hungry instruments and I'm not seeing any problems.
> >>
> >> On 14 April 2016 at 09:45, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
> >> In fact, I also tried with ScoreEvent(), and it works in a similar way:
> >>
> >> import csnd6
> >> import time
> >>
> >> cs = csnd6.Csound()
> >> cs.SetOption('-odac')
> >> cs.CompileOrc('''
> >> instr 1
> >> k1 expon 1,p3,0.001
> >> a1 oscili p4,cpspch(p5)
> >>    out a1*k1
> >> endin
> >> ''')
> >> cs.Start()
> >> perf = csnd6.CsoundPerformanceThread(cs)
> >> perf.Play()
> >> i = 0
> >> arr = csnd6.CsoundMYFLTArray(5)
> >> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
> >> while i < 12:
> >>   arr.SetValue(4, (8+i/100.))
> >>   cs.ScoreEvent("i", arr.GetPtr(0), 5)
> >>   print str
> >>   time.sleep(0.1)
> >>   i+=1
> >> time.sleep(1)
> >> perf.Stop()
> >> perf.Join()
> >>
> >> ========================
> >> Dr Victor Lazzarini
> >> Dean of Arts, Celtic Studies and Philosophy,
> >> Maynooth University,
> >> Maynooth, Co Kildare, Ireland
> >> Tel: 00 353 7086936
> >> Fax: 00 353 1 7086952
> >>
> >> > On 14 Apr 2016, at 09:29, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
> >> >
> >> > Note that I am not sending events through the PerformanceThread class, but
> >> > directly to Csound. So it’s not using that mechanism, but plain Csound::InputMessage(),
> >> > and that is subject to the API lock, from threadsafe.c:
> >> >
> >> > void csoundInputMessage(CSOUND *csound, const char *message){
> >> >    csoundLockMutex(csound->API_lock);
> >> >    csoundInputMessageInternal(csound, message);
> >> >    csoundUnlockMutex(csound->API_lock);
> >> > }
> >> >
> >> > Regards
> >> > ========================
> >> > Dr Victor Lazzarini
> >> > Dean of Arts, Celtic Studies and Philosophy,
> >> > Maynooth University,
> >> > Maynooth, Co Kildare, Ireland
> >> > Tel: 00 353 7086936
> >> > Fax: 00 353 1 7086952
> >> >
> >> >> On 14 Apr 2016, at 09:09, Michael Gogins <michael.gogins@gmail.com> wrote:
> >> >>
> >> >> My case is not comparable to your test because csound.node does not
> >> >> use the Csound performance thread class. I may change csound.node to
> >> >> do so, or I may modify my thread to handle events similarly to the
> >> >> performance thread class.
> >> >>
> >> >> I have proved that for csound.node, if I remove the csound->API_lock
> >> >> mutex in csoundScoreEvent, it works beautifully, so there is some
> >> >> thread mixup somewhere.
> >> >>
> >> >> Best,
> >> >> Mike
> >> >>
> >> >> -----------------------------------------------------
> >> >> Michael Gogins
> >> >> Irreducible Productions
> >> >> http://michaelgogins.tumblr.com
> >> >> Michael dot Gogins at gmail dot com
> >> >>
> >> >>
> >> >> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
> >> >> <Victor.Lazzarini@nuim.ie> wrote:
> >> >>> I just ran this Python program and could find no issue. It played as expected.
> >> >>>
> >> >>> ===================
> >> >>> import csnd6
> >> >>> import time
> >> >>>
> >> >>> cs = csnd6.Csound()
> >> >>> cs.SetOption('-odac')
> >> >>> cs.CompileOrc('''
> >> >>> instr 1
> >> >>> k1 expon 1,p3,0.001
> >> >>> a1 oscili p4,cpspch(p5)
> >> >>>  out a1*k1
> >> >>> endin
> >> >>> ''')
> >> >>> cs.Start()
> >> >>> perf = csnd6.CsoundPerformanceThread(cs)
> >> >>> perf.Play()
> >> >>> i = 0
> >> >>> while i < 12:
> >> >>> str = "i1 0 1 16000 %f " %  (8+i/100.)
> >> >>> cs.InputMessage(str)
> >> >>> print str
> >> >>> time.sleep(0.1)
> >> >>> i+=1
> >> >>> time.sleep(1)
> >> >>> perf.Stop()
> >> >>> perf.Join()
> >> >>> =================
> >> >>>
> >> >>> Is it something else you’re reporting?
> >> >>>
> >> >>> ========================
> >> >>> Dr Victor Lazzarini
> >> >>> Dean of Arts, Celtic Studies and Philosophy,
> >> >>> Maynooth University,
> >> >>> Maynooth, Co Kildare, Ireland
> >> >>> Tel: 00 353 7086936
> >> >>> Fax: 00 353 1 7086952
> >> >>>
> >> >>>> On 13 Apr 2016, at 19:49, Michael Gogins <michael.gogins@gmail.com> wrote:
> >> >>>>
> >> >>>> I have found that there is now a big slowdown in csoundScoreEvent as
> >> >>>> compared to prior versions of Csound.
> >> >>>>
> >> >>>> The slowdown shows up for me as I call csoundScoreEvent from
> >> >>>> csound.node when a JavaScript function inserts Csound "i" statements
> >> >>>> into a real-time performance. Each event takes many seconds or what
> >> >>>> seems like a minute or so to insert. I have proved that the slowdown
> >> >>>> is not caused by csound.node code in jscsound.cpp or by my JavaScript
> >> >>>> code by commenting out only the csoundScoreEvent call in jscsound.cpp.
> >> >>>> In that case the performance runs smoothly (Csound is still running
> >> >>>> with the same always on instruments etc. in this case).
> >> >>>>
> >> >>>> Similar slowdowns are apparent with csoundReadScore and csoundInputMessage.
> >> >>>>
> >> >>>> There is no problem with regular command-line Csound.
> >> >>>>
> >> >>>> I will attempt to provide a simple example to reproduce the problem,
> >> >>>> but I wanted to mention this first. I know that the score handling
> >> >>>> code in Csound has been changed recently.
> >> >>>>
> >> >>>> Regards,
> >> >>>> Mike
> >> >>>>
> >> >>>> -----------------------------------------------------
> >> >>>> Michael Gogins
> >> >>>> Irreducible Productions
> >> >>>> http://michaelgogins.tumblr.com
> >> >>>> Michael dot Gogins at gmail dot com
> >>
> >>
>

Tarmo may or may not have an issue with the audio driver, but as for
the problem I reported, I have already proved it is not the audio
driver by temporarily removing the API mutex and getting a big
improvement in performance as a result. My solution with lockfree
queues popping events just before csoundPerformKsmps also performs
very well.

Regards,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Apr 14, 2016 at 5:59 PM, Victor Lazzarini
 wrote:
> It could be the audio driver. Depending on the build of portaudio, you might
> have choices, shown as different output numbers.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> On 14 Apr 2016, at 15:55, Tarmo Johannes  wrote:
>
> Tested on Windows (7), CsounQt
>
> - 32-bit build, self built CsoundQt 0.9.2.1 (Csound 6.07beta from mov 2015)
> - CsoundQt  0.9.1 (the original one in last official installer),
> - CsoundQt 64-bit, Csound 6.07
>
> + CsoundQt 64-bit 0.9.2.1, Csound 6.07 64-bit installed in another computer
> under wine.
>
>
> all the same result - after button press a delay before sound comes out.
>
> I had no other choice for audio driver as portaudio, no special buffer sizes
> set anywhere.
>
> Anyway, the behaviour is the similar - no difference with older version or
> 32 bit.
>
> Maybe it is irrelevant to Michaels problem and maybe I am doing something
> wrong on Windows. Just reported - please ignore if it seems not connected to
> the Csound -Node issue.
>
> tarmo
>
>
> 2016-04-14 17:10 GMT+03:00 Tarmo Johannes :
>>
>> Hi,
>>
>> html5 support is currently only available for windows. But you can similar
>> thing with attached csd in CsoundQt -  there is one button that triggeres
>> event call (csoundInputMessage or similar in the code, I guess). On linux
>> (and I think on OSX as well)  the sound comes out immediately, on windows
>> with a lag. I will test later with 32-bit build on Windows.
>>
>> tarmo
>>
>> 2016-04-14 15:59 GMT+03:00 Victor Lazzarini :
>>>
>>> How can I test this? I have no idea how to run it.
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>>
>>> > On 14 Apr 2016, at 13:34, Tarmo Johannes  wrote:
>>> >
>>> > Hi,
>>> >
>>> > I have noticed, too, lags with CsoundQt, Csound64-bit and windows - for
>>> > example sarting instruments wiht html-button or button widget in CsoundQt -
>>> > after click, I see a message in console immediately but the sound comes out
>>> > about 0.1 seconds later.
>>> >
>>> > for example:
>>> >
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
>>> > 
 My html
>>> > TEST



>>> > 
>>> > 
>>> > 
>>> >
>>> > instr 1
>>> >   ivalue = p4
>>> >   print ivalue
>>> >   out poscil(0.1,random:i(100,1000))
>>> > endin
>>> >
>>> >
>>> > tarmo
>>> >
>>> >
>>> >
>>> >
>>> > 2016-04-14 14:27 GMT+03:00 Michael Gogins :
>>> > I have of course left the API lock in csoundScoreEvent just as it was,
>>> > not to worry. I removed it temporarily to see if it was causing a
>>> > problem for me, and it was, so I put it back. I have pushed no changes
>>> > to Csound code or to Csound interfaces code. The only changes I have
>>> > pushed are in csound.node code, where I added some lockfree queues in
>>> > jscsound.cpp to get score fragments and score events into the
>>> > performance thread routine's perform ksmps loop without depending on
>>> > the API_lock to be working properly. This solution works fine and I am
>>> > moving on from this issue.
>>> >
>>> > However, I think this demonstrates that there are subtle problems with
>>> > threading and the API in Csound. For now I think we just have to keep
>>> > our eyes open for similar problems. It might be useful to run valgrind
>>> > on this, and when I get back to my Linux computer I may run my piece
>>> > with the old code and valgrind to see if there are any data races or
>>> > anything. That's assuming of course that this is not Windows-specific.
>>> >
>>> > Best,
>>> > Mike
>>> >
>>> > -----------------------------------------------------
>>> > Michael Gogins
>>> > Irreducible Productions
>>> > http://michaelgogins.tumblr.com
>>> > Michael dot Gogins at gmail dot com
>>> >
>>> >
>>> > On Thu, Apr 14, 2016 at 1:58 PM, Victor Lazzarini
>>> >  wrote:
>>> > > If you had a C++ program that showed the issue, we could debug. I am
>>> > > just concerned because the API lock is important for the
>>> > > threadsafe operation we introduced in the Csound 6 API.
>>> > >
>>> > > ========================
>>> > > Dr Victor Lazzarini
>>> > > Dean of Arts, Celtic Studies and Philosophy,
>>> > > Maynooth University,
>>> > > Maynooth, Co Kildare, Ireland
>>> > > Tel: 00 353 7086936
>>> > > Fax: 00 353 1 7086952
>>> > >
>>> > >> On 14 Apr 2016, at 10:58, Michael Gogins 
>>> > >> wrote:
>>> > >>
>>> > >> Obviously what you both say is true, yet equally obviously there
>>> > >> absolutely is a problem when I use the same approach, which therefore must
>>> > >> not really be the same approach. I have a simple solution that I am trying.
>>> > >>
>>> > >> Best,
>>> > >> Mike
>>> > >>
>>> > >> On Apr 14, 2016 12:49 PM, "Rory Walsh"  wrote:
>>> > >> BTW, I'm not using CsoundPerformanceThread at all.
>>> > >>
>>> > >> On 14 April 2016 at 10:48, Rory Walsh  wrote:
>>> > >> I use csoundInputMessage quite a lot in Cabbage for generating
>>> > >> tables on the fly. I just tested some of my more InputMessage hungry
>>> > >> instruments and I'm not seeing any problems.
>>> > >>
>>> > >> On 14 April 2016 at 09:45, Victor Lazzarini
>>> > >>  wrote:
>>> > >> In fact, I also tried with ScoreEvent(), and it works in a similar
>>> > >> way:
>>> > >>
>>> > >> import csnd6
>>> > >> import time
>>> > >>
>>> > >> cs = csnd6.Csound()
>>> > >> cs.SetOption('-odac')
>>> > >> cs.CompileOrc('''
>>> > >> instr 1
>>> > >> k1 expon 1,p3,0.001
>>> > >> a1 oscili p4,cpspch(p5)
>>> > >>    out a1*k1
>>> > >> endin
>>> > >> ''')
>>> > >> cs.Start()
>>> > >> perf = csnd6.CsoundPerformanceThread(cs)
>>> > >> perf.Play()
>>> > >> i = 0
>>> > >> arr = csnd6.CsoundMYFLTArray(5)
>>> > >> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
>>> > >> while i < 12:
>>> > >>   arr.SetValue(4, (8+i/100.))
>>> > >>   cs.ScoreEvent("i", arr.GetPtr(0), 5)
>>> > >>   print str
>>> > >>   time.sleep(0.1)
>>> > >>   i+=1
>>> > >> time.sleep(1)
>>> > >> perf.Stop()
>>> > >> perf.Join()
>>> > >>
>>> > >> ========================
>>> > >> Dr Victor Lazzarini
>>> > >> Dean of Arts, Celtic Studies and Philosophy,
>>> > >> Maynooth University,
>>> > >> Maynooth, Co Kildare, Ireland
>>> > >> Tel: 00 353 7086936
>>> > >> Fax: 00 353 1 7086952
>>> > >>
>>> > >> > On 14 Apr 2016, at 09:29, Victor Lazzarini
>>> > >> >  wrote:
>>> > >> >
>>> > >> > Note that I am not sending events through the PerformanceThread
>>> > >> > class, but
>>> > >> > directly to Csound. So it’s not using that mechanism, but plain
>>> > >> > Csound::InputMessage(),
>>> > >> > and that is subject to the API lock, from threadsafe.c:
>>> > >> >
>>> > >> > void csoundInputMessage(CSOUND *csound, const char *message){
>>> > >> >    csoundLockMutex(csound->API_lock);
>>> > >> >    csoundInputMessageInternal(csound, message);
>>> > >> >    csoundUnlockMutex(csound->API_lock);
>>> > >> > }
>>> > >> >
>>> > >> > Regards
>>> > >> > ========================
>>> > >> > Dr Victor Lazzarini
>>> > >> > Dean of Arts, Celtic Studies and Philosophy,
>>> > >> > Maynooth University,
>>> > >> > Maynooth, Co Kildare, Ireland
>>> > >> > Tel: 00 353 7086936
>>> > >> > Fax: 00 353 1 7086952
>>> > >> >
>>> > >> >> On 14 Apr 2016, at 09:09, Michael Gogins
>>> > >> >>  wrote:
>>> > >> >>
>>> > >> >> My case is not comparable to your test because csound.node does
>>> > >> >> not
>>> > >> >> use the Csound performance thread class. I may change csound.node
>>> > >> >> to
>>> > >> >> do so, or I may modify my thread to handle events similarly to
>>> > >> >> the
>>> > >> >> performance thread class.
>>> > >> >>
>>> > >> >> I have proved that for csound.node, if I remove the
>>> > >> >> csound->API_lock
>>> > >> >> mutex in csoundScoreEvent, it works beautifully, so there is some
>>> > >> >> thread mixup somewhere.
>>> > >> >>
>>> > >> >> Best,
>>> > >> >> Mike
>>> > >> >>
>>> > >> >> -----------------------------------------------------
>>> > >> >> Michael Gogins
>>> > >> >> Irreducible Productions
>>> > >> >> http://michaelgogins.tumblr.com
>>> > >> >> Michael dot Gogins at gmail dot com
>>> > >> >>
>>> > >> >>
>>> > >> >> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
>>> > >> >>  wrote:
>>> > >> >>> I just ran this Python program and could find no issue. It
>>> > >> >>> played as expected.
>>> > >> >>>
>>> > >> >>> ===================
>>> > >> >>> import csnd6
>>> > >> >>> import time
>>> > >> >>>
>>> > >> >>> cs = csnd6.Csound()
>>> > >> >>> cs.SetOption('-odac')
>>> > >> >>> cs.CompileOrc('''
>>> > >> >>> instr 1
>>> > >> >>> k1 expon 1,p3,0.001
>>> > >> >>> a1 oscili p4,cpspch(p5)
>>> > >> >>>  out a1*k1
>>> > >> >>> endin
>>> > >> >>> ''')
>>> > >> >>> cs.Start()
>>> > >> >>> perf = csnd6.CsoundPerformanceThread(cs)
>>> > >> >>> perf.Play()
>>> > >> >>> i = 0
>>> > >> >>> while i < 12:
>>> > >> >>> str = "i1 0 1 16000 %f " %  (8+i/100.)
>>> > >> >>> cs.InputMessage(str)
>>> > >> >>> print str
>>> > >> >>> time.sleep(0.1)
>>> > >> >>> i+=1
>>> > >> >>> time.sleep(1)
>>> > >> >>> perf.Stop()
>>> > >> >>> perf.Join()
>>> > >> >>> =================
>>> > >> >>>
>>> > >> >>> Is it something else you’re reporting?
>>> > >> >>>
>>> > >> >>> ========================
>>> > >> >>> Dr Victor Lazzarini
>>> > >> >>> Dean of Arts, Celtic Studies and Philosophy,
>>> > >> >>> Maynooth University,
>>> > >> >>> Maynooth, Co Kildare, Ireland
>>> > >> >>> Tel: 00 353 7086936
>>> > >> >>> Fax: 00 353 1 7086952
>>> > >> >>>
>>> > >> >>>> On 13 Apr 2016, at 19:49, Michael Gogins
>>> > >> >>>>  wrote:
>>> > >> >>>>
>>> > >> >>>> I have found that there is now a big slowdown in
>>> > >> >>>> csoundScoreEvent as
>>> > >> >>>> compared to prior versions of Csound.
>>> > >> >>>>
>>> > >> >>>> The slowdown shows up for me as I call csoundScoreEvent from
>>> > >> >>>> csound.node when a JavaScript function inserts Csound "i"
>>> > >> >>>> statements
>>> > >> >>>> into a real-time performance. Each event takes many seconds or
>>> > >> >>>> what
>>> > >> >>>> seems like a minute or so to insert. I have proved that the
>>> > >> >>>> slowdown
>>> > >> >>>> is not caused by csound.node code in jscsound.cpp or by my
>>> > >> >>>> JavaScript
>>> > >> >>>> code by commenting out only the csoundScoreEvent call in
>>> > >> >>>> jscsound.cpp.
>>> > >> >>>> In that case the performance runs smoothly (Csound is still
>>> > >> >>>> running
>>> > >> >>>> with the same always on instruments etc. in this case).
>>> > >> >>>>
>>> > >> >>>> Similar slowdowns are apparent with csoundReadScore and
>>> > >> >>>> csoundInputMessage.
>>> > >> >>>>
>>> > >> >>>> There is no problem with regular command-line Csound.
>>> > >> >>>>
>>> > >> >>>> I will attempt to provide a simple example to reproduce the
>>> > >> >>>> problem,
>>> > >> >>>> but I wanted to mention this first. I know that the score
>>> > >> >>>> handling
>>> > >> >>>> code in Csound has been changed recently.
>>> > >> >>>>
>>> > >> >>>> Regards,
>>> > >> >>>> Mike
>>> > >> >>>>
>>> > >> >>>> -----------------------------------------------------
>>> > >> >>>> Michael Gogins
>>> > >> >>>> Irreducible Productions
>>> > >> >>>> http://michaelgogins.tumblr.com
>>> > >> >>>> Michael dot Gogins at gmail dot com
>>> > >>
>>> > >>
>>> >
>>
>>

I imagine this is a problem local to windows and mutexes.  A search
brought up this stack overflow page:

http://stackoverflow.com/questions/1277627/overhead-of-pthread-mutexes

Moving to pthreads globally might have been a mistake.  We could go
back to separate thread implementations: pthreads, windows native, and
no-op.  That would certainly simplify some aspects of building for
non-threaded systems like Emscripten. A lock-free transfer queue
sounds interesting too.

What I'm curious about: is this mutex lock a new thing?  I haven't
followed the code changes too closely the past few months and I guess
I missed its introduction.

On Thu, Apr 14, 2016 at 11:22 AM, Michael Gogins
 wrote:
> Tarmo may or may not have an issue with the audio driver, but as for
> the problem I reported, I have already proved it is not the audio
> driver by temporarily removing the API mutex and getting a big
> improvement in performance as a result. My solution with lockfree
> queues popping events just before csoundPerformKsmps also performs
> very well.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Apr 14, 2016 at 5:59 PM, Victor Lazzarini
>  wrote:
>> It could be the audio driver. Depending on the build of portaudio, you might
>> have choices, shown as different output numbers.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 14 Apr 2016, at 15:55, Tarmo Johannes  wrote:
>>
>> Tested on Windows (7), CsounQt
>>
>> - 32-bit build, self built CsoundQt 0.9.2.1 (Csound 6.07beta from mov 2015)
>> - CsoundQt  0.9.1 (the original one in last official installer),
>> - CsoundQt 64-bit, Csound 6.07
>>
>> + CsoundQt 64-bit 0.9.2.1, Csound 6.07 64-bit installed in another computer
>> under wine.
>>
>>
>> all the same result - after button press a delay before sound comes out.
>>
>> I had no other choice for audio driver as portaudio, no special buffer sizes
>> set anywhere.
>>
>> Anyway, the behaviour is the similar - no difference with older version or
>> 32 bit.
>>
>> Maybe it is irrelevant to Michaels problem and maybe I am doing something
>> wrong on Windows. Just reported - please ignore if it seems not connected to
>> the Csound -Node issue.
>>
>> tarmo
>>
>>
>> 2016-04-14 17:10 GMT+03:00 Tarmo Johannes :
>>>
>>> Hi,
>>>
>>> html5 support is currently only available for windows. But you can similar
>>> thing with attached csd in CsoundQt -  there is one button that triggeres
>>> event call (csoundInputMessage or similar in the code, I guess). On linux
>>> (and I think on OSX as well)  the sound comes out immediately, on windows
>>> with a lag. I will test later with 32-bit build on Windows.
>>>
>>> tarmo
>>>
>>> 2016-04-14 15:59 GMT+03:00 Victor Lazzarini :
>>>>
>>>> How can I test this? I have no idea how to run it.
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>>
>>>> > On 14 Apr 2016, at 13:34, Tarmo Johannes  wrote:
>>>> >
>>>> > Hi,
>>>> >
>>>> > I have noticed, too, lags with CsoundQt, Csound64-bit and windows - for
>>>> > example sarting instruments wiht html-button or button widget in CsoundQt -
>>>> > after click, I see a message in console immediately but the sound comes out
>>>> > about 0.1 seconds later.
>>>> >
>>>> > for example:
>>>> >
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
 My html
>>>> > TEST



>>>> > 
>>>> > 
>>>> > 
>>>> >
>>>> > instr 1
>>>> >   ivalue = p4
>>>> >   print ivalue
>>>> >   out poscil(0.1,random:i(100,1000))
>>>> > endin
>>>> >
>>>> >
>>>> > tarmo
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > 2016-04-14 14:27 GMT+03:00 Michael Gogins :
>>>> > I have of course left the API lock in csoundScoreEvent just as it was,
>>>> > not to worry. I removed it temporarily to see if it was causing a
>>>> > problem for me, and it was, so I put it back. I have pushed no changes
>>>> > to Csound code or to Csound interfaces code. The only changes I have
>>>> > pushed are in csound.node code, where I added some lockfree queues in
>>>> > jscsound.cpp to get score fragments and score events into the
>>>> > performance thread routine's perform ksmps loop without depending on
>>>> > the API_lock to be working properly. This solution works fine and I am
>>>> > moving on from this issue.
>>>> >
>>>> > However, I think this demonstrates that there are subtle problems with
>>>> > threading and the API in Csound. For now I think we just have to keep
>>>> > our eyes open for similar problems. It might be useful to run valgrind
>>>> > on this, and when I get back to my Linux computer I may run my piece
>>>> > with the old code and valgrind to see if there are any data races or
>>>> > anything. That's assuming of course that this is not Windows-specific.
>>>> >
>>>> > Best,
>>>> > Mike
>>>> >
>>>> > -----------------------------------------------------
>>>> > Michael Gogins
>>>> > Irreducible Productions
>>>> > http://michaelgogins.tumblr.com
>>>> > Michael dot Gogins at gmail dot com
>>>> >
>>>> >
>>>> > On Thu, Apr 14, 2016 at 1:58 PM, Victor Lazzarini
>>>> >  wrote:
>>>> > > If you had a C++ program that showed the issue, we could debug. I am
>>>> > > just concerned because the API lock is important for the
>>>> > > threadsafe operation we introduced in the Csound 6 API.
>>>> > >
>>>> > > ========================
>>>> > > Dr Victor Lazzarini
>>>> > > Dean of Arts, Celtic Studies and Philosophy,
>>>> > > Maynooth University,
>>>> > > Maynooth, Co Kildare, Ireland
>>>> > > Tel: 00 353 7086936
>>>> > > Fax: 00 353 1 7086952
>>>> > >
>>>> > >> On 14 Apr 2016, at 10:58, Michael Gogins 
>>>> > >> wrote:
>>>> > >>
>>>> > >> Obviously what you both say is true, yet equally obviously there
>>>> > >> absolutely is a problem when I use the same approach, which therefore must
>>>> > >> not really be the same approach. I have a simple solution that I am trying.
>>>> > >>
>>>> > >> Best,
>>>> > >> Mike
>>>> > >>
>>>> > >> On Apr 14, 2016 12:49 PM, "Rory Walsh"  wrote:
>>>> > >> BTW, I'm not using CsoundPerformanceThread at all.
>>>> > >>
>>>> > >> On 14 April 2016 at 10:48, Rory Walsh  wrote:
>>>> > >> I use csoundInputMessage quite a lot in Cabbage for generating
>>>> > >> tables on the fly. I just tested some of my more InputMessage hungry
>>>> > >> instruments and I'm not seeing any problems.
>>>> > >>
>>>> > >> On 14 April 2016 at 09:45, Victor Lazzarini
>>>> > >>  wrote:
>>>> > >> In fact, I also tried with ScoreEvent(), and it works in a similar
>>>> > >> way:
>>>> > >>
>>>> > >> import csnd6
>>>> > >> import time
>>>> > >>
>>>> > >> cs = csnd6.Csound()
>>>> > >> cs.SetOption('-odac')
>>>> > >> cs.CompileOrc('''
>>>> > >> instr 1
>>>> > >> k1 expon 1,p3,0.001
>>>> > >> a1 oscili p4,cpspch(p5)
>>>> > >>    out a1*k1
>>>> > >> endin
>>>> > >> ''')
>>>> > >> cs.Start()
>>>> > >> perf = csnd6.CsoundPerformanceThread(cs)
>>>> > >> perf.Play()
>>>> > >> i = 0
>>>> > >> arr = csnd6.CsoundMYFLTArray(5)
>>>> > >> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
>>>> > >> while i < 12:
>>>> > >>   arr.SetValue(4, (8+i/100.))
>>>> > >>   cs.ScoreEvent("i", arr.GetPtr(0), 5)
>>>> > >>   print str
>>>> > >>   time.sleep(0.1)
>>>> > >>   i+=1
>>>> > >> time.sleep(1)
>>>> > >> perf.Stop()
>>>> > >> perf.Join()
>>>> > >>
>>>> > >> ========================
>>>> > >> Dr Victor Lazzarini
>>>> > >> Dean of Arts, Celtic Studies and Philosophy,
>>>> > >> Maynooth University,
>>>> > >> Maynooth, Co Kildare, Ireland
>>>> > >> Tel: 00 353 7086936
>>>> > >> Fax: 00 353 1 7086952
>>>> > >>
>>>> > >> > On 14 Apr 2016, at 09:29, Victor Lazzarini
>>>> > >> >  wrote:
>>>> > >> >
>>>> > >> > Note that I am not sending events through the PerformanceThread
>>>> > >> > class, but
>>>> > >> > directly to Csound. So it’s not using that mechanism, but plain
>>>> > >> > Csound::InputMessage(),
>>>> > >> > and that is subject to the API lock, from threadsafe.c:
>>>> > >> >
>>>> > >> > void csoundInputMessage(CSOUND *csound, const char *message){
>>>> > >> >    csoundLockMutex(csound->API_lock);
>>>> > >> >    csoundInputMessageInternal(csound, message);
>>>> > >> >    csoundUnlockMutex(csound->API_lock);
>>>> > >> > }
>>>> > >> >
>>>> > >> > Regards
>>>> > >> > ========================
>>>> > >> > Dr Victor Lazzarini
>>>> > >> > Dean of Arts, Celtic Studies and Philosophy,
>>>> > >> > Maynooth University,
>>>> > >> > Maynooth, Co Kildare, Ireland
>>>> > >> > Tel: 00 353 7086936
>>>> > >> > Fax: 00 353 1 7086952
>>>> > >> >
>>>> > >> >> On 14 Apr 2016, at 09:09, Michael Gogins
>>>> > >> >>  wrote:
>>>> > >> >>
>>>> > >> >> My case is not comparable to your test because csound.node does
>>>> > >> >> not
>>>> > >> >> use the Csound performance thread class. I may change csound.node
>>>> > >> >> to
>>>> > >> >> do so, or I may modify my thread to handle events similarly to
>>>> > >> >> the
>>>> > >> >> performance thread class.
>>>> > >> >>
>>>> > >> >> I have proved that for csound.node, if I remove the
>>>> > >> >> csound->API_lock
>>>> > >> >> mutex in csoundScoreEvent, it works beautifully, so there is some
>>>> > >> >> thread mixup somewhere.
>>>> > >> >>
>>>> > >> >> Best,
>>>> > >> >> Mike
>>>> > >> >>
>>>> > >> >> -----------------------------------------------------
>>>> > >> >> Michael Gogins
>>>> > >> >> Irreducible Productions
>>>> > >> >> http://michaelgogins.tumblr.com
>>>> > >> >> Michael dot Gogins at gmail dot com
>>>> > >> >>
>>>> > >> >>
>>>> > >> >> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
>>>> > >> >>  wrote:
>>>> > >> >>> I just ran this Python program and could find no issue. It
>>>> > >> >>> played as expected.
>>>> > >> >>>
>>>> > >> >>> ===================
>>>> > >> >>> import csnd6
>>>> > >> >>> import time
>>>> > >> >>>
>>>> > >> >>> cs = csnd6.Csound()
>>>> > >> >>> cs.SetOption('-odac')
>>>> > >> >>> cs.CompileOrc('''
>>>> > >> >>> instr 1
>>>> > >> >>> k1 expon 1,p3,0.001
>>>> > >> >>> a1 oscili p4,cpspch(p5)
>>>> > >> >>>  out a1*k1
>>>> > >> >>> endin
>>>> > >> >>> ''')
>>>> > >> >>> cs.Start()
>>>> > >> >>> perf = csnd6.CsoundPerformanceThread(cs)
>>>> > >> >>> perf.Play()
>>>> > >> >>> i = 0
>>>> > >> >>> while i < 12:
>>>> > >> >>> str = "i1 0 1 16000 %f " %  (8+i/100.)
>>>> > >> >>> cs.InputMessage(str)
>>>> > >> >>> print str
>>>> > >> >>> time.sleep(0.1)
>>>> > >> >>> i+=1
>>>> > >> >>> time.sleep(1)
>>>> > >> >>> perf.Stop()
>>>> > >> >>> perf.Join()
>>>> > >> >>> =================
>>>> > >> >>>
>>>> > >> >>> Is it something else you’re reporting?
>>>> > >> >>>
>>>> > >> >>> ========================
>>>> > >> >>> Dr Victor Lazzarini
>>>> > >> >>> Dean of Arts, Celtic Studies and Philosophy,
>>>> > >> >>> Maynooth University,
>>>> > >> >>> Maynooth, Co Kildare, Ireland
>>>> > >> >>> Tel: 00 353 7086936
>>>> > >> >>> Fax: 00 353 1 7086952
>>>> > >> >>>
>>>> > >> >>>> On 13 Apr 2016, at 19:49, Michael Gogins
>>>> > >> >>>>  wrote:
>>>> > >> >>>>
>>>> > >> >>>> I have found that there is now a big slowdown in
>>>> > >> >>>> csoundScoreEvent as
>>>> > >> >>>> compared to prior versions of Csound.
>>>> > >> >>>>
>>>> > >> >>>> The slowdown shows up for me as I call csoundScoreEvent from
>>>> > >> >>>> csound.node when a JavaScript function inserts Csound "i"
>>>> > >> >>>> statements
>>>> > >> >>>> into a real-time performance. Each event takes many seconds or
>>>> > >> >>>> what
>>>> > >> >>>> seems like a minute or so to insert. I have proved that the
>>>> > >> >>>> slowdown
>>>> > >> >>>> is not caused by csound.node code in jscsound.cpp or by my
>>>> > >> >>>> JavaScript
>>>> > >> >>>> code by commenting out only the csoundScoreEvent call in
>>>> > >> >>>> jscsound.cpp.
>>>> > >> >>>> In that case the performance runs smoothly (Csound is still
>>>> > >> >>>> running
>>>> > >> >>>> with the same always on instruments etc. in this case).
>>>> > >> >>>>
>>>> > >> >>>> Similar slowdowns are apparent with csoundReadScore and
>>>> > >> >>>> csoundInputMessage.
>>>> > >> >>>>
>>>> > >> >>>> There is no problem with regular command-line Csound.
>>>> > >> >>>>
>>>> > >> >>>> I will attempt to provide a simple example to reproduce the
>>>> > >> >>>> problem,
>>>> > >> >>>> but I wanted to mention this first. I know that the score
>>>> > >> >>>> handling
>>>> > >> >>>> code in Csound has been changed recently.
>>>> > >> >>>>
>>>> > >> >>>> Regards,
>>>> > >> >>>> Mike
>>>> > >> >>>>
>>>> > >> >>>> -----------------------------------------------------
>>>> > >> >>>> Michael Gogins
>>>> > >> >>>> Irreducible Productions
>>>> > >> >>>> http://michaelgogins.tumblr.com
>>>> > >> >>>> Michael dot Gogins at gmail dot com
>>>> > >>
>>>> > >>
>>>> >
>>>
>>>

It's bern there since we made all API calls thread safe in 6

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 14 Apr 2016, at 17:18, Steven Yi  wrote:
> 
> I imagine this is a problem local to windows and mutexes.  A search
> brought up this stack overflow page:
> 
> http://stackoverflow.com/questions/1277627/overhead-of-pthread-mutexes
> 
> Moving to pthreads globally might have been a mistake.  We could go
> back to separate thread implementations: pthreads, windows native, and
> no-op.  That would certainly simplify some aspects of building for
> non-threaded systems like Emscripten. A lock-free transfer queue
> sounds interesting too.
> 
> What I'm curious about: is this mutex lock a new thing?  I haven't
> followed the code changes too closely the past few months and I guess
> I missed its introduction.
> 
> On Thu, Apr 14, 2016 at 11:22 AM, Michael Gogins
>  wrote:
>> Tarmo may or may not have an issue with the audio driver, but as for
>> the problem I reported, I have already proved it is not the audio
>> driver by temporarily removing the API mutex and getting a big
>> improvement in performance as a result. My solution with lockfree
>> queues popping events just before csoundPerformKsmps also performs
>> very well.
>> 
>> Regards,
>> Mike
>> 
>> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>> 
>> 
>> On Thu, Apr 14, 2016 at 5:59 PM, Victor Lazzarini
>>  wrote:
>>> It could be the audio driver. Depending on the build of portaudio, you might
>>> have choices, shown as different output numbers.
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>> On 14 Apr 2016, at 15:55, Tarmo Johannes  wrote:
>>> 
>>> Tested on Windows (7), CsounQt
>>> 
>>> - 32-bit build, self built CsoundQt 0.9.2.1 (Csound 6.07beta from mov 2015)
>>> - CsoundQt  0.9.1 (the original one in last official installer),
>>> - CsoundQt 64-bit, Csound 6.07
>>> 
>>> + CsoundQt 64-bit 0.9.2.1, Csound 6.07 64-bit installed in another computer
>>> under wine.
>>> 
>>> 
>>> all the same result - after button press a delay before sound comes out.
>>> 
>>> I had no other choice for audio driver as portaudio, no special buffer sizes
>>> set anywhere.
>>> 
>>> Anyway, the behaviour is the similar - no difference with older version or
>>> 32 bit.
>>> 
>>> Maybe it is irrelevant to Michaels problem and maybe I am doing something
>>> wrong on Windows. Just reported - please ignore if it seems not connected to
>>> the Csound -Node issue.
>>> 
>>> tarmo
>>> 
>>> 
>>> 2016-04-14 17:10 GMT+03:00 Tarmo Johannes :
>>>> 
>>>> Hi,
>>>> 
>>>> html5 support is currently only available for windows. But you can similar
>>>> thing with attached csd in CsoundQt -  there is one button that triggeres
>>>> event call (csoundInputMessage or similar in the code, I guess). On linux
>>>> (and I think on OSX as well)  the sound comes out immediately, on windows
>>>> with a lag. I will test later with 32-bit build on Windows.
>>>> 
>>>> tarmo
>>>> 
>>>> 2016-04-14 15:59 GMT+03:00 Victor Lazzarini :
>>>>> 
>>>>> How can I test this? I have no idea how to run it.
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952
>>>>> 
>>>>>> On 14 Apr 2016, at 13:34, Tarmo Johannes  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I have noticed, too, lags with CsoundQt, Csound64-bit and windows - for
>>>>>> example sarting instruments wiht html-button or button widget in CsoundQt -
>>>>>> after click, I see a message in console immediately but the sound comes out
>>>>>> about 0.1 seconds later.
>>>>>> 
>>>>>> for example:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
 My html
>>>>>> TEST



>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> instr 1
>>>>>>  ivalue = p4
>>>>>>  print ivalue
>>>>>>  out poscil(0.1,random:i(100,1000))
>>>>>> endin
>>>>>> 
>>>>>> 
>>>>>> tarmo
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2016-04-14 14:27 GMT+03:00 Michael Gogins :
>>>>>> I have of course left the API lock in csoundScoreEvent just as it was,
>>>>>> not to worry. I removed it temporarily to see if it was causing a
>>>>>> problem for me, and it was, so I put it back. I have pushed no changes
>>>>>> to Csound code or to Csound interfaces code. The only changes I have
>>>>>> pushed are in csound.node code, where I added some lockfree queues in
>>>>>> jscsound.cpp to get score fragments and score events into the
>>>>>> performance thread routine's perform ksmps loop without depending on
>>>>>> the API_lock to be working properly. This solution works fine and I am
>>>>>> moving on from this issue.
>>>>>> 
>>>>>> However, I think this demonstrates that there are subtle problems with
>>>>>> threading and the API in Csound. For now I think we just have to keep
>>>>>> our eyes open for similar problems. It might be useful to run valgrind
>>>>>> on this, and when I get back to my Linux computer I may run my piece
>>>>>> with the old code and valgrind to see if there are any data races or
>>>>>> anything. That's assuming of course that this is not Windows-specific.
>>>>>> 
>>>>>> Best,
>>>>>> Mike
>>>>>> 
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>> 
>>>>>> 
>>>>>> On Thu, Apr 14, 2016 at 1:58 PM, Victor Lazzarini
>>>>>>  wrote:
>>>>>>> If you had a C++ program that showed the issue, we could debug. I am
>>>>>>> just concerned because the API lock is important for the
>>>>>>> threadsafe operation we introduced in the Csound 6 API.
>>>>>>> 
>>>>>>> ========================
>>>>>>> Dr Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>> 
>>>>>>>> On 14 Apr 2016, at 10:58, Michael Gogins 
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Obviously what you both say is true, yet equally obviously there
>>>>>>>> absolutely is a problem when I use the same approach, which therefore must
>>>>>>>> not really be the same approach. I have a simple solution that I am trying.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> Mike
>>>>>>>> 
>>>>>>>> On Apr 14, 2016 12:49 PM, "Rory Walsh"  wrote:
>>>>>>>> BTW, I'm not using CsoundPerformanceThread at all.
>>>>>>>> 
>>>>>>>> On 14 April 2016 at 10:48, Rory Walsh  wrote:
>>>>>>>> I use csoundInputMessage quite a lot in Cabbage for generating
>>>>>>>> tables on the fly. I just tested some of my more InputMessage hungry
>>>>>>>> instruments and I'm not seeing any problems.
>>>>>>>> 
>>>>>>>> On 14 April 2016 at 09:45, Victor Lazzarini
>>>>>>>>  wrote:
>>>>>>>> In fact, I also tried with ScoreEvent(), and it works in a similar
>>>>>>>> way:
>>>>>>>> 
>>>>>>>> import csnd6
>>>>>>>> import time
>>>>>>>> 
>>>>>>>> cs = csnd6.Csound()
>>>>>>>> cs.SetOption('-odac')
>>>>>>>> cs.CompileOrc('''
>>>>>>>> instr 1
>>>>>>>> k1 expon 1,p3,0.001
>>>>>>>> a1 oscili p4,cpspch(p5)
>>>>>>>>   out a1*k1
>>>>>>>> endin
>>>>>>>> ''')
>>>>>>>> cs.Start()
>>>>>>>> perf = csnd6.CsoundPerformanceThread(cs)
>>>>>>>> perf.Play()
>>>>>>>> i = 0
>>>>>>>> arr = csnd6.CsoundMYFLTArray(5)
>>>>>>>> arr.SetValues(0, 1.0, 0, 1.0, 16000.)
>>>>>>>> while i < 12:
>>>>>>>>  arr.SetValue(4, (8+i/100.))
>>>>>>>>  cs.ScoreEvent("i", arr.GetPtr(0), 5)
>>>>>>>>  print str
>>>>>>>>  time.sleep(0.1)
>>>>>>>>  i+=1
>>>>>>>> time.sleep(1)
>>>>>>>> perf.Stop()
>>>>>>>> perf.Join()
>>>>>>>> 
>>>>>>>> ========================
>>>>>>>> Dr Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>> 
>>>>>>>>> On 14 Apr 2016, at 09:29, Victor Lazzarini
>>>>>>>>>  wrote:
>>>>>>>>> 
>>>>>>>>> Note that I am not sending events through the PerformanceThread
>>>>>>>>> class, but
>>>>>>>>> directly to Csound. So it’s not using that mechanism, but plain
>>>>>>>>> Csound::InputMessage(),
>>>>>>>>> and that is subject to the API lock, from threadsafe.c:
>>>>>>>>> 
>>>>>>>>> void csoundInputMessage(CSOUND *csound, const char *message){
>>>>>>>>>   csoundLockMutex(csound->API_lock);
>>>>>>>>>   csoundInputMessageInternal(csound, message);
>>>>>>>>>   csoundUnlockMutex(csound->API_lock);
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> Regards
>>>>>>>>> ========================
>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>>>> Maynooth University,
>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>> 
>>>>>>>>>> On 14 Apr 2016, at 09:09, Michael Gogins
>>>>>>>>>>  wrote:
>>>>>>>>>> 
>>>>>>>>>> My case is not comparable to your test because csound.node does
>>>>>>>>>> not
>>>>>>>>>> use the Csound performance thread class. I may change csound.node
>>>>>>>>>> to
>>>>>>>>>> do so, or I may modify my thread to handle events similarly to
>>>>>>>>>> the
>>>>>>>>>> performance thread class.
>>>>>>>>>> 
>>>>>>>>>> I have proved that for csound.node, if I remove the
>>>>>>>>>> csound->API_lock
>>>>>>>>>> mutex in csoundScoreEvent, it works beautifully, so there is some
>>>>>>>>>> thread mixup somewhere.
>>>>>>>>>> 
>>>>>>>>>> Best,
>>>>>>>>>> Mike
>>>>>>>>>> 
>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>> Michael Gogins
>>>>>>>>>> Irreducible Productions
>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Apr 13, 2016 at 10:11 PM, Victor Lazzarini
>>>>>>>>>>  wrote:
>>>>>>>>>>> I just ran this Python program and could find no issue. It
>>>>>>>>>>> played as expected.
>>>>>>>>>>> 
>>>>>>>>>>> ===================
>>>>>>>>>>> import csnd6
>>>>>>>>>>> import time
>>>>>>>>>>> 
>>>>>>>>>>> cs = csnd6.Csound()
>>>>>>>>>>> cs.SetOption('-odac')
>>>>>>>>>>> cs.CompileOrc('''
>>>>>>>>>>> instr 1
>>>>>>>>>>> k1 expon 1,p3,0.001
>>>>>>>>>>> a1 oscili p4,cpspch(p5)
>>>>>>>>>>> out a1*k1
>>>>>>>>>>> endin
>>>>>>>>>>> ''')
>>>>>>>>>>> cs.Start()
>>>>>>>>>>> perf = csnd6.CsoundPerformanceThread(cs)
>>>>>>>>>>> perf.Play()
>>>>>>>>>>> i = 0
>>>>>>>>>>> while i < 12:
>>>>>>>>>>> str = "i1 0 1 16000 %f " %  (8+i/100.)
>>>>>>>>>>> cs.InputMessage(str)
>>>>>>>>>>> print str
>>>>>>>>>>> time.sleep(0.1)
>>>>>>>>>>> i+=1
>>>>>>>>>>> time.sleep(1)
>>>>>>>>>>> perf.Stop()
>>>>>>>>>>> perf.Join()
>>>>>>>>>>> =================
>>>>>>>>>>> 
>>>>>>>>>>> Is it something else you’re reporting?
>>>>>>>>>>> 
>>>>>>>>>>> ========================
>>>>>>>>>>> Dr Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>>>>>> Maynooth University,
>>>>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>>>>> Tel: 00 353 7086936
>>>>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>>>> 
>>>>>>>>>>>> On 13 Apr 2016, at 19:49, Michael Gogins
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> I have found that there is now a big slowdown in
>>>>>>>>>>>> csoundScoreEvent as
>>>>>>>>>>>> compared to prior versions of Csound.
>>>>>>>>>>>> 
>>>>>>>>>>>> The slowdown shows up for me as I call csoundScoreEvent from
>>>>>>>>>>>> csound.node when a JavaScript function inserts Csound "i"
>>>>>>>>>>>> statements
>>>>>>>>>>>> into a real-time performance. Each event takes many seconds or
>>>>>>>>>>>> what
>>>>>>>>>>>> seems like a minute or so to insert. I have proved that the
>>>>>>>>>>>> slowdown
>>>>>>>>>>>> is not caused by csound.node code in jscsound.cpp or by my
>>>>>>>>>>>> JavaScript
>>>>>>>>>>>> code by commenting out only the csoundScoreEvent call in
>>>>>>>>>>>> jscsound.cpp.
>>>>>>>>>>>> In that case the performance runs smoothly (Csound is still
>>>>>>>>>>>> running
>>>>>>>>>>>> with the same always on instruments etc. in this case).
>>>>>>>>>>>> 
>>>>>>>>>>>> Similar slowdowns are apparent with csoundReadScore and
>>>>>>>>>>>> csoundInputMessage.
>>>>>>>>>>>> 
>>>>>>>>>>>> There is no problem with regular command-line Csound.
>>>>>>>>>>>> 
>>>>>>>>>>>> I will attempt to provide a simple example to reproduce the
>>>>>>>>>>>> problem,
>>>>>>>>>>>> but I wanted to mention this first. I know that the score
>>>>>>>>>>>> handling
>>>>>>>>>>>> code in Csound has been changed recently.
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Mike
>>>>>>>>>>>> 
>>>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>>>> Michael Gogins
>>>>>>>>>>>> Irreducible Productions
>>>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>>>> Michael dot Gogins at gmail dot com