You could use the CsoundPerformanceThread class:

Csound *cs =new Csound;
CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);

cs.Compile(argc, argv);

perf.Play();   // starts performance
perf.Pause();  // pauses
perf.Stop(); // stops
perf.Join();  // join and finish perf thread

delete perf;
delete cs;

Victor


On 30 Nov 2011, at 14:31, Anders Genell wrote:

> Hi again!
> 
> Instead of continuing in the thread I stole, I thought I'd start a new one, as is right and proper.
> I am sorry for repeating some of my questions, but I still haven't wrapped my head around the workings of the API, probably because I don't know enough to ask the right questions of to interpret the answers...
> 
> So,
> 
> there is the startup delay I keep raving about.
> 
> Is there a proper way to use the (C++) API to start a thread with a new instance of csound running a csd that has a dummy score (our needs to run for hours, just to make sure sound doesn't suddenly stop mid experiment) and stopping it again before reaching end of score?
> Why would one call Perform() and not PerformKsmps() or vice versa?
> 
> As I've said, we have csound listening for OSC messages and send audio back through socksend (again, thank you John!).
> I seems that when starting a new performance there is OSC/audio buffered while csound is (slowly) being started. 
> The audio output starts after ca 8 seconds, and there is then a constant 8 second latency until we call Stop(), wait 8 seconds for audio to stop, and then call Perform() again.
> If starting our software without our csound plugin, but with the receiver for socksend udp packets running, and starting csound from the command line using the same csd file as in the above example, we do not have this delay.
> It's been suggested the delayed start could be due to the need for loading libs into RAM at start, but why is there then such a difference between command line and API start?
> 
> Since the command line is just a simple program calling the API, I assume it has to do with how we use the API - hence my questions above...
> 
> Regards,
> Anders
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor is right.

You can do as you ask.

Perform is for if you don't need to do anything in between Csound
rendering one buffer and the next, PerformKsmps is if you need to do
something synchronously between Csound rendering one buffer and the
next.

FWIW, I suspect the delay is due to the Csound orchestra compiler
loading all the plugin opcodes and other modules. I haven't checked
this.

Why use OSC rather than the API to control Csound? If you use
PerformKsmps you can feed events from your app into Csound with
minimal latency this way.

Regards,
Mike



On Wed, Nov 30, 2011 at 9:49 AM, Victor Lazzarini
 wrote:
> You could use the CsoundPerformanceThread class:
>
> Csound *cs =new Csound;
> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>
> cs.Compile(argc, argv);
>
> perf.Play();   // starts performance
> perf.Pause();  // pauses
> perf.Stop(); // stops
> perf.Join();  // join and finish perf thread
>
> delete perf;
> delete cs;
>
> Victor
>
>
> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>
>> Hi again!
>>
>> Instead of continuing in the thread I stole, I thought I'd start a new one, as is right and proper.
>> I am sorry for repeating some of my questions, but I still haven't wrapped my head around the workings of the API, probably because I don't know enough to ask the right questions of to interpret the answers...
>>
>> So,
>>
>> there is the startup delay I keep raving about.
>>
>> Is there a proper way to use the (C++) API to start a thread with a new instance of csound running a csd that has a dummy score (our needs to run for hours, just to make sure sound doesn't suddenly stop mid experiment) and stopping it again before reaching end of score?
>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>
>> As I've said, we have csound listening for OSC messages and send audio back through socksend (again, thank you John!).
>> I seems that when starting a new performance there is OSC/audio buffered while csound is (slowly) being started.
>> The audio output starts after ca 8 seconds, and there is then a constant 8 second latency until we call Stop(), wait 8 seconds for audio to stop, and then call Perform() again.
>> If starting our software without our csound plugin, but with the receiver for socksend udp packets running, and starting csound from the command line using the same csd file as in the above example, we do not have this delay.
>> It's been suggested the delayed start could be due to the need for loading libs into RAM at start, but why is there then such a difference between command line and API start?
>>
>> Since the command line is just a simple program calling the API, I assume it has to do with how we use the API - hence my questions above...
>>
>> Regards,
>> Anders
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

You can use any number of API channel functions to send data straight
from your app directly to an instrument in Csound.

http://www.google.ie/search?hl=en&client=firefox-a&hs=8en&rls=org.mozilla%3Aen-US%3Aofficial&q=csound+api+floss+manuals&oq=csound+api+floss+manuals&aq=f&aqi=&aql=&gs_sm=e&gs_upl=2189l4585l0l4736l14l13l0l12l0l0l22l22l1l1l0

http://www.google.ie/url?sa=t&rct=j&q=csound+api&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fwww.csounds.com%2Farticles%2FRoryWalsh_CsoundAPI.pdf&ei=mlPWTsmkIciWhQe777l_&usg=AFQjCNFUbtenBABj_z8nitjsh4Ey6HzZnA

On 30 November 2011 15:54, Anders Genell  wrote:
> The app we have is for generating sound for engine, tyre/road, wind etc in
> driving simulators. Some of our associates prefer other sound rendering
> solutions (why I can't imagine*) but still want to use our interface to the
> vehicle simulator and to OpenAL spatialization, so we needed something
> fairly standardized to keep our app modular enough. If we can say "your
> sound renderer needs to accept OSC and needs to feed back audio over UDP"
> then we don't need to concern ourselves with what others use. Our current
> use of the API is due to our wishes to have csound starting automatically
> from our app, instead of needing to start it manually.
> Another thing is that in some setups it is useful to run the sound rendering
> and the sound management (our app) on different machines (one placed with
> the sound hardware on the motion platform, the other being the machine
> running the real-time computational vehicle models).
>
> That being said, we have three simulators ourselves and nothing prevents us
> from using the API on those.
> Is there a direct way of changing values of (global) variables through the
> API, or do we need to do something else to vary frequencies and amplitudes
> in realtime?
> Could even PerformBuffer() be used to access the audio directly, pushing it
> to the OpenAL buffers? I'd hate to omit the use of socksend after all the
> generous support from John, but it might be a more elegant solution when
> running csound on the same machine as our app...
>
> Regards,
> /Anders
>
> * Regarding alternatives, I just wanted to say I am getting more and more
> impressed by csound the more I immerse myself in it! It's like with Linux
> anytime I come to think of something that needs to be done (e.g. automated
> audio recording and analysis to count number and type of passing vehicles on
> a road) I think "Isn't there a way to do a script for this?", and the answer
> is always "Yes, and someone else has beat you to it using cron, arecord and
> sox, and posted it on the NN forum". The same goes for csound - "Isn't there
> a way to generate rpm, torque and velocity dependent sound in real time?"
> "Yes there is, and bunch of skilled computer wizzes beat you to it some 25
> years ago". I am awed.
>
> On Wed, Nov 30, 2011 at 3:58 PM, Michael Gogins 
> wrote:
>>
>> Victor is right.
>>
>> You can do as you ask.
>>
>> Perform is for if you don't need to do anything in between Csound
>> rendering one buffer and the next, PerformKsmps is if you need to do
>> something synchronously between Csound rendering one buffer and the
>> next.
>>
>> FWIW, I suspect the delay is due to the Csound orchestra compiler
>> loading all the plugin opcodes and other modules. I haven't checked
>> this.
>>
>> Why use OSC rather than the API to control Csound? If you use
>> PerformKsmps you can feed events from your app into Csound with
>> minimal latency this way.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On Wed, Nov 30, 2011 at 9:49 AM, Victor Lazzarini
>>  wrote:
>> > You could use the CsoundPerformanceThread class:
>> >
>> > Csound *cs =new Csound;
>> > CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>> >
>> > cs.Compile(argc, argv);
>> >
>> > perf.Play();   // starts performance
>> > perf.Pause();  // pauses
>> > perf.Stop(); // stops
>> > perf.Join();  // join and finish perf thread
>> >
>> > delete perf;
>> > delete cs;
>> >
>> > Victor
>> >
>> >
>> > On 30 Nov 2011, at 14:31, Anders Genell wrote:
>> >
>> >> Hi again!
>> >>
>> >> Instead of continuing in the thread I stole, I thought I'd start a new
>> >> one, as is right and proper.
>> >> I am sorry for repeating some of my questions, but I still haven't
>> >> wrapped my head around the workings of the API, probably because I don't
>> >> know enough to ask the right questions of to interpret the answers...
>> >>
>> >> So,
>> >>
>> >> there is the startup delay I keep raving about.
>> >>
>> >> Is there a proper way to use the (C++) API to start a thread with a new
>> >> instance of csound running a csd that has a dummy score (our needs to run
>> >> for hours, just to make sure sound doesn't suddenly stop mid experiment) and
>> >> stopping it again before reaching end of score?
>> >> Why would one call Perform() and not PerformKsmps() or vice versa?
>> >>
>> >> As I've said, we have csound listening for OSC messages and send audio
>> >> back through socksend (again, thank you John!).
>> >> I seems that when starting a new performance there is OSC/audio
>> >> buffered while csound is (slowly) being started.
>> >> The audio output starts after ca 8 seconds, and there is then a
>> >> constant 8 second latency until we call Stop(), wait 8 seconds for audio to
>> >> stop, and then call Perform() again.
>> >> If starting our software without our csound plugin, but with the
>> >> receiver for socksend udp packets running, and starting csound from the
>> >> command line using the same csd file as in the above example, we do not have
>> >> this delay.
>> >> It's been suggested the delayed start could be due to the need for
>> >> loading libs into RAM at start, but why is there then such a difference
>> >> between command line and API start?
>> >>
>> >> Since the command line is just a simple program calling the API, I
>> >> assume it has to do with how we use the API - hence my questions above...
>> >>
>> >> Regards,
>> >> Anders
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> All the data continuously generated in your IT infrastructure
>> >> contains a definitive record of customers, application performance,
>> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> data and makes sense of it. IT sense. And common sense.
>> >>
>> >> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> > Dr Victor Lazzarini
>> > Senior Lecturer
>> > Dept. of Music
>> > NUI Maynooth Ireland
>> > tel.: +353 1 708 3545
>> > Victor dot Lazzarini AT nuim dot ie
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes you can change global variables in real time using the API, you
can send score events in real time, and more.

PerformBuffer and PerformKsmps are similar, differ mainly in level of
granularity (Csound internal buffer for PerformKsmps, audio device
buffer for PerformBuffer).

Regards,
Mike

On Wed, Nov 30, 2011 at 10:54 AM, Anders Genell  wrote:
> The app we have is for generating sound for engine, tyre/road, wind etc in
> driving simulators. Some of our associates prefer other sound rendering
> solutions (why I can't imagine*) but still want to use our interface to the
> vehicle simulator and to OpenAL spatialization, so we needed something
> fairly standardized to keep our app modular enough. If we can say "your
> sound renderer needs to accept OSC and needs to feed back audio over UDP"
> then we don't need to concern ourselves with what others use. Our current
> use of the API is due to our wishes to have csound starting automatically
> from our app, instead of needing to start it manually.
> Another thing is that in some setups it is useful to run the sound rendering
> and the sound management (our app) on different machines (one placed with
> the sound hardware on the motion platform, the other being the machine
> running the real-time computational vehicle models).
>
> That being said, we have three simulators ourselves and nothing prevents us
> from using the API on those.
> Is there a direct way of changing values of (global) variables through the
> API, or do we need to do something else to vary frequencies and amplitudes
> in realtime?
> Could even PerformBuffer() be used to access the audio directly, pushing it
> to the OpenAL buffers? I'd hate to omit the use of socksend after all the
> generous support from John, but it might be a more elegant solution when
> running csound on the same machine as our app...
>
> Regards,
> /Anders
>
> * Regarding alternatives, I just wanted to say I am getting more and more
> impressed by csound the more I immerse myself in it! It's like with Linux
> anytime I come to think of something that needs to be done (e.g. automated
> audio recording and analysis to count number and type of passing vehicles on
> a road) I think "Isn't there a way to do a script for this?", and the answer
> is always "Yes, and someone else has beat you to it using cron, arecord and
> sox, and posted it on the NN forum". The same goes for csound - "Isn't there
> a way to generate rpm, torque and velocity dependent sound in real time?"
> "Yes there is, and bunch of skilled computer wizzes beat you to it some 25
> years ago". I am awed.
>
>
> On Wed, Nov 30, 2011 at 3:58 PM, Michael Gogins 
> wrote:
>>
>> Victor is right.
>>
>> You can do as you ask.
>>
>> Perform is for if you don't need to do anything in between Csound
>> rendering one buffer and the next, PerformKsmps is if you need to do
>> something synchronously between Csound rendering one buffer and the
>> next.
>>
>> FWIW, I suspect the delay is due to the Csound orchestra compiler
>> loading all the plugin opcodes and other modules. I haven't checked
>> this.
>>
>> Why use OSC rather than the API to control Csound? If you use
>> PerformKsmps you can feed events from your app into Csound with
>> minimal latency this way.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On Wed, Nov 30, 2011 at 9:49 AM, Victor Lazzarini
>>  wrote:
>> > You could use the CsoundPerformanceThread class:
>> >
>> > Csound *cs =new Csound;
>> > CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>> >
>> > cs.Compile(argc, argv);
>> >
>> > perf.Play();   // starts performance
>> > perf.Pause();  // pauses
>> > perf.Stop(); // stops
>> > perf.Join();  // join and finish perf thread
>> >
>> > delete perf;
>> > delete cs;
>> >
>> > Victor
>> >
>> >
>> > On 30 Nov 2011, at 14:31, Anders Genell wrote:
>> >
>> >> Hi again!
>> >>
>> >> Instead of continuing in the thread I stole, I thought I'd start a new
>> >> one, as is right and proper.
>> >> I am sorry for repeating some of my questions, but I still haven't
>> >> wrapped my head around the workings of the API, probably because I don't
>> >> know enough to ask the right questions of to interpret the answers...
>> >>
>> >> So,
>> >>
>> >> there is the startup delay I keep raving about.
>> >>
>> >> Is there a proper way to use the (C++) API to start a thread with a new
>> >> instance of csound running a csd that has a dummy score (our needs to run
>> >> for hours, just to make sure sound doesn't suddenly stop mid experiment) and
>> >> stopping it again before reaching end of score?
>> >> Why would one call Perform() and not PerformKsmps() or vice versa?
>> >>
>> >> As I've said, we have csound listening for OSC messages and send audio
>> >> back through socksend (again, thank you John!).
>> >> I seems that when starting a new performance there is OSC/audio
>> >> buffered while csound is (slowly) being started.
>> >> The audio output starts after ca 8 seconds, and there is then a
>> >> constant 8 second latency until we call Stop(), wait 8 seconds for audio to
>> >> stop, and then call Perform() again.
>> >> If starting our software without our csound plugin, but with the
>> >> receiver for socksend udp packets running, and starting csound from the
>> >> command line using the same csd file as in the above example, we do not have
>> >> this delay.
>> >> It's been suggested the delayed start could be due to the need for
>> >> loading libs into RAM at start, but why is there then such a difference
>> >> between command line and API start?
>> >>
>> >> Since the command line is just a simple program calling the API, I
>> >> assume it has to do with how we use the API - hence my questions above...
>> >>
>> >> Regards,
>> >> Anders
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> All the data continuously generated in your IT infrastructure
>> >> contains a definitive record of customers, application performance,
>> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> data and makes sense of it. IT sense. And common sense.
>> >>
>> >> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> > Dr Victor Lazzarini
>> > Senior Lecturer
>> > Dept. of Music
>> > NUI Maynooth Ireland
>> > tel.: +353 1 708 3545
>> > Victor dot Lazzarini AT nuim dot ie
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

When using CsoundPerformanceThread, do I need to include some
additional header or so?
CsoundPerformanceThread does not seem to be declared in csound.hpp or
csound.h...

Regards,
/Anders

On 11/30/11, Victor Lazzarini  wrote:
> You could use the CsoundPerformanceThread class:
>
> Csound *cs =new Csound;
> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>
> cs.Compile(argc, argv);
>
> perf.Play();   // starts performance
> perf.Pause();  // pauses
> perf.Stop(); // stops
> perf.Join();  // join and finish perf thread
>
> delete perf;
> delete cs;
>
> Victor
>
>
> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>
>> Hi again!
>>
>> Instead of continuing in the thread I stole, I thought I'd start a new
>> one, as is right and proper.
>> I am sorry for repeating some of my questions, but I still haven't wrapped
>> my head around the workings of the API, probably because I don't know
>> enough to ask the right questions of to interpret the answers...
>>
>> So,
>>
>> there is the startup delay I keep raving about.
>>
>> Is there a proper way to use the (C++) API to start a thread with a new
>> instance of csound running a csd that has a dummy score (our needs to run
>> for hours, just to make sure sound doesn't suddenly stop mid experiment)
>> and stopping it again before reaching end of score?
>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>
>> As I've said, we have csound listening for OSC messages and send audio
>> back through socksend (again, thank you John!).
>> I seems that when starting a new performance there is OSC/audio buffered
>> while csound is (slowly) being started.
>> The audio output starts after ca 8 seconds, and there is then a constant 8
>> second latency until we call Stop(), wait 8 seconds for audio to stop, and
>> then call Perform() again.
>> If starting our software without our csound plugin, but with the receiver
>> for socksend udp packets running, and starting csound from the command
>> line using the same csd file as in the above example, we do not have this
>> delay.
>> It's been suggested the delayed start could be due to the need for loading
>> libs into RAM at start, but why is there then such a difference between
>> command line and API start?
>>
>> Since the command line is just a simple program calling the API, I assume
>> it has to do with how we use the API - hence my questions above...
>>
>> Regards,
>> Anders
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

CsPerfThread.hpp.

Victor
On 1 Dec 2011, at 10:15, Anders Genell wrote:

> When using CsoundPerformanceThread, do I need to include some
> additional header or so?
> CsoundPerformanceThread does not seem to be declared in csound.hpp or
> csound.h...
> 
> Regards,
> /Anders
> 
> On 11/30/11, Victor Lazzarini  wrote:
>> You could use the CsoundPerformanceThread class:
>> 
>> Csound *cs =new Csound;
>> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>> 
>> cs.Compile(argc, argv);
>> 
>> perf.Play();   // starts performance
>> perf.Pause();  // pauses
>> perf.Stop(); // stops
>> perf.Join();  // join and finish perf thread
>> 
>> delete perf;
>> delete cs;
>> 
>> Victor
>> 
>> 
>> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>> 
>>> Hi again!
>>> 
>>> Instead of continuing in the thread I stole, I thought I'd start a new
>>> one, as is right and proper.
>>> I am sorry for repeating some of my questions, but I still haven't wrapped
>>> my head around the workings of the API, probably because I don't know
>>> enough to ask the right questions of to interpret the answers...
>>> 
>>> So,
>>> 
>>> there is the startup delay I keep raving about.
>>> 
>>> Is there a proper way to use the (C++) API to start a thread with a new
>>> instance of csound running a csd that has a dummy score (our needs to run
>>> for hours, just to make sure sound doesn't suddenly stop mid experiment)
>>> and stopping it again before reaching end of score?
>>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>> 
>>> As I've said, we have csound listening for OSC messages and send audio
>>> back through socksend (again, thank you John!).
>>> I seems that when starting a new performance there is OSC/audio buffered
>>> while csound is (slowly) being started.
>>> The audio output starts after ca 8 seconds, and there is then a constant 8
>>> second latency until we call Stop(), wait 8 seconds for audio to stop, and
>>> then call Perform() again.
>>> If starting our software without our csound plugin, but with the receiver
>>> for socksend udp packets running, and starting csound from the command
>>> line using the same csd file as in the above example, we do not have this
>>> delay.
>>> It's been suggested the delayed start could be due to the need for loading
>>> libs into RAM at start, but why is there then such a difference between
>>> command line and API start?
>>> 
>>> Since the command line is just a simple program calling the API, I assume
>>> it has to do with how we use the API - hence my questions above...
>>> 
>>> Regards,
>>> Anders
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Ah!
I can't seem to find that header file anywhere, though...

/Anders

On 12/1/11, Victor Lazzarini  wrote:
> CsPerfThread.hpp.
>
> Victor
> On 1 Dec 2011, at 10:15, Anders Genell wrote:
>
>> When using CsoundPerformanceThread, do I need to include some
>> additional header or so?
>> CsoundPerformanceThread does not seem to be declared in csound.hpp or
>> csound.h...
>>
>> Regards,
>> /Anders
>>
>> On 11/30/11, Victor Lazzarini  wrote:
>>> You could use the CsoundPerformanceThread class:
>>>
>>> Csound *cs =new Csound;
>>> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>>>
>>> cs.Compile(argc, argv);
>>>
>>> perf.Play();   // starts performance
>>> perf.Pause();  // pauses
>>> perf.Stop(); // stops
>>> perf.Join();  // join and finish perf thread
>>>
>>> delete perf;
>>> delete cs;
>>>
>>> Victor
>>>
>>>
>>> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>>>
>>>> Hi again!
>>>>
>>>> Instead of continuing in the thread I stole, I thought I'd start a new
>>>> one, as is right and proper.
>>>> I am sorry for repeating some of my questions, but I still haven't
>>>> wrapped
>>>> my head around the workings of the API, probably because I don't know
>>>> enough to ask the right questions of to interpret the answers...
>>>>
>>>> So,
>>>>
>>>> there is the startup delay I keep raving about.
>>>>
>>>> Is there a proper way to use the (C++) API to start a thread with a new
>>>> instance of csound running a csd that has a dummy score (our needs to
>>>> run
>>>> for hours, just to make sure sound doesn't suddenly stop mid experiment)
>>>> and stopping it again before reaching end of score?
>>>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>>>
>>>> As I've said, we have csound listening for OSC messages and send audio
>>>> back through socksend (again, thank you John!).
>>>> I seems that when starting a new performance there is OSC/audio buffered
>>>> while csound is (slowly) being started.
>>>> The audio output starts after ca 8 seconds, and there is then a constant
>>>> 8
>>>> second latency until we call Stop(), wait 8 seconds for audio to stop,
>>>> and
>>>> then call Perform() again.
>>>> If starting our software without our csound plugin, but with the
>>>> receiver
>>>> for socksend udp packets running, and starting csound from the command
>>>> line using the same csd file as in the above example, we do not have
>>>> this
>>>> delay.
>>>> It's been suggested the delayed start could be due to the need for
>>>> loading
>>>> libs into RAM at start, but why is there then such a difference between
>>>> command line and API start?
>>>>
>>>> Since the command line is just a simple program calling the API, I
>>>> assume
>>>> it has to do with how we use the API - hence my questions above...
>>>>
>>>> Regards,
>>>> Anders
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a definitive record of customers, application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Oh, wait, I found it...


On 12/1/11, Anders Genell  wrote:
> Ah!
> I can't seem to find that header file anywhere, though...
>
> /Anders
>
> On 12/1/11, Victor Lazzarini  wrote:
>> CsPerfThread.hpp.
>>
>> Victor
>> On 1 Dec 2011, at 10:15, Anders Genell wrote:
>>
>>> When using CsoundPerformanceThread, do I need to include some
>>> additional header or so?
>>> CsoundPerformanceThread does not seem to be declared in csound.hpp or
>>> csound.h...
>>>
>>> Regards,
>>> /Anders
>>>
>>> On 11/30/11, Victor Lazzarini  wrote:
>>>> You could use the CsoundPerformanceThread class:
>>>>
>>>> Csound *cs =new Csound;
>>>> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>>>>
>>>> cs.Compile(argc, argv);
>>>>
>>>> perf.Play();   // starts performance
>>>> perf.Pause();  // pauses
>>>> perf.Stop(); // stops
>>>> perf.Join();  // join and finish perf thread
>>>>
>>>> delete perf;
>>>> delete cs;
>>>>
>>>> Victor
>>>>
>>>>
>>>> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>>>>
>>>>> Hi again!
>>>>>
>>>>> Instead of continuing in the thread I stole, I thought I'd start a new
>>>>> one, as is right and proper.
>>>>> I am sorry for repeating some of my questions, but I still haven't
>>>>> wrapped
>>>>> my head around the workings of the API, probably because I don't know
>>>>> enough to ask the right questions of to interpret the answers...
>>>>>
>>>>> So,
>>>>>
>>>>> there is the startup delay I keep raving about.
>>>>>
>>>>> Is there a proper way to use the (C++) API to start a thread with a
>>>>> new
>>>>> instance of csound running a csd that has a dummy score (our needs to
>>>>> run
>>>>> for hours, just to make sure sound doesn't suddenly stop mid
>>>>> experiment)
>>>>> and stopping it again before reaching end of score?
>>>>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>>>>
>>>>> As I've said, we have csound listening for OSC messages and send audio
>>>>> back through socksend (again, thank you John!).
>>>>> I seems that when starting a new performance there is OSC/audio
>>>>> buffered
>>>>> while csound is (slowly) being started.
>>>>> The audio output starts after ca 8 seconds, and there is then a
>>>>> constant
>>>>> 8
>>>>> second latency until we call Stop(), wait 8 seconds for audio to stop,
>>>>> and
>>>>> then call Perform() again.
>>>>> If starting our software without our csound plugin, but with the
>>>>> receiver
>>>>> for socksend udp packets running, and starting csound from the command
>>>>> line using the same csd file as in the above example, we do not have
>>>>> this
>>>>> delay.
>>>>> It's been suggested the delayed start could be due to the need for
>>>>> loading
>>>>> libs into RAM at start, but why is there then such a difference
>>>>> between
>>>>> command line and API start?
>>>>>
>>>>> Since the command line is just a simple program calling the API, I
>>>>> assume
>>>>> it has to do with how we use the API - hence my questions above...
>>>>>
>>>>> Regards,
>>>>> Anders
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a definitive record of customers, application performance,
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a definitive record of customers, application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-novd2d
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Under /interfaces in the csound sources. Also you will need to link to libcsnd as well as libcsound.
On 1 Dec 2011, at 11:36, Anders Genell wrote:

> Ah!
> I can't seem to find that header file anywhere, though...
> 
> /Anders
> 
> On 12/1/11, Victor Lazzarini  wrote:
>> CsPerfThread.hpp.
>> 
>> Victor
>> On 1 Dec 2011, at 10:15, Anders Genell wrote:
>> 
>>> When using CsoundPerformanceThread, do I need to include some
>>> additional header or so?
>>> CsoundPerformanceThread does not seem to be declared in csound.hpp or
>>> csound.h...
>>> 
>>> Regards,
>>> /Anders
>>> 
>>> On 11/30/11, Victor Lazzarini  wrote:
>>>> You could use the CsoundPerformanceThread class:
>>>> 
>>>> Csound *cs =new Csound;
>>>> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>>>> 
>>>> cs.Compile(argc, argv);
>>>> 
>>>> perf.Play();   // starts performance
>>>> perf.Pause();  // pauses
>>>> perf.Stop(); // stops
>>>> perf.Join();  // join and finish perf thread
>>>> 
>>>> delete perf;
>>>> delete cs;
>>>> 
>>>> Victor
>>>> 
>>>> 
>>>> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>>>> 
>>>>> Hi again!
>>>>> 
>>>>> Instead of continuing in the thread I stole, I thought I'd start a new
>>>>> one, as is right and proper.
>>>>> I am sorry for repeating some of my questions, but I still haven't
>>>>> wrapped
>>>>> my head around the workings of the API, probably because I don't know
>>>>> enough to ask the right questions of to interpret the answers...
>>>>> 
>>>>> So,
>>>>> 
>>>>> there is the startup delay I keep raving about.
>>>>> 
>>>>> Is there a proper way to use the (C++) API to start a thread with a new
>>>>> instance of csound running a csd that has a dummy score (our needs to
>>>>> run
>>>>> for hours, just to make sure sound doesn't suddenly stop mid experiment)
>>>>> and stopping it again before reaching end of score?
>>>>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>>>> 
>>>>> As I've said, we have csound listening for OSC messages and send audio
>>>>> back through socksend (again, thank you John!).
>>>>> I seems that when starting a new performance there is OSC/audio buffered
>>>>> while csound is (slowly) being started.
>>>>> The audio output starts after ca 8 seconds, and there is then a constant
>>>>> 8
>>>>> second latency until we call Stop(), wait 8 seconds for audio to stop,
>>>>> and
>>>>> then call Perform() again.
>>>>> If starting our software without our csound plugin, but with the
>>>>> receiver
>>>>> for socksend udp packets running, and starting csound from the command
>>>>> line using the same csd file as in the above example, we do not have
>>>>> this
>>>>> delay.
>>>>> It's been suggested the delayed start could be due to the need for
>>>>> loading
>>>>> libs into RAM at start, but why is there then such a difference between
>>>>> command line and API start?
>>>>> 
>>>>> Since the command line is just a simple program calling the API, I
>>>>> assume
>>>>> it has to do with how we use the API - hence my questions above...
>>>>> 
>>>>> Regards,
>>>>> Anders
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a definitive record of customers, application performance,
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a definitive record of customers, application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-novd2d
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Is csound actually computing (do you get the stdout messages of new alloc for instr x etc) and finishing up? Or is it stuck?

On 1 Dec 2011, at 14:42, Anders Genell wrote:

Ah! Thanks!

Well, doing -L/usr/lib -lcsnd and -lcsound in our Makefile and trying the code below starts csound (or so it seems - we at least get the stdout/err blarb), but we get no sound.

<code>
CsoundThread::CsoundThread(std::string path) :
  m_path(path), m_csound(new Csound()), perf(new CsoundPerformanceThread(m_csound))
{

}

void CsoundThread::run()
{
  m_csound->Compile((char*)m_path.c_str());
  //  m_csound->Perform();                                                                                                                    
  perf->Play();

}

int CsoundThread::quit() {
  //  m_csound->Stop();                                                                                                                       
  perf->Stop();
  //perf->Join();                                                                                                                             
  //delete perf;
  return 0;
}
</code>


Using  mcsound->Perform() and ->Stop() respectively, as in the commented lines, works, but with the aforementioned 8 second delay at first call to ::run(). If we call ::quit(), wait for sound to stop and then call ::run() again, the delay is gone, but at random occasions our csound thread freezes using 100% CPU (for that kernel) and the sound stops.

The rest of the code for our csound plugin can be found here:
http://dl.dropbox.com/u/32567399/csoundinterface.cpp
http://dl.dropbox.com/u/32567399/csoundinterface.h

Regards,
/Anders

On Thu, Dec 1, 2011 at 12:45 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

Under /interfaces in the csound sources. Also you will need to link to libcsnd as well as libcsound.

On 1 Dec 2011, at 11:36, Anders Genell wrote:

> Ah!
> I can't seem to find that header file anywhere, though...
>
> /Anders
>
> On 12/1/11, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
>> CsPerfThread.hpp.
>>
>> Victor
>> On 1 Dec 2011, at 10:15, Anders Genell wrote:
>>
>>> When using CsoundPerformanceThread, do I need to include some
>>> additional header or so?
>>> CsoundPerformanceThread does not seem to be declared in csound.hpp or
>>> csound.h...
>>>
>>> Regards,
>>> /Anders
>>>
>>> On 11/30/11, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
>>>> You could use the CsoundPerformanceThread class:
>>>>
>>>> Csound *cs =new Csound;
>>>> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>>>>
>>>> cs.Compile(argc, argv);
>>>>
>>>> perf.Play();   // starts performance
>>>> perf.Pause();  // pauses
>>>> perf.Stop(); // stops
>>>> perf.Join();  // join and finish perf thread
>>>>
>>>> delete perf;
>>>> delete cs;
>>>>
>>>> Victor
>>>>
>>>>
>>>> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>>>>
>>>>> Hi again!
>>>>>
>>>>> Instead of continuing in the thread I stole, I thought I'd start a new
>>>>> one, as is right and proper.
>>>>> I am sorry for repeating some of my questions, but I still haven't
>>>>> wrapped
>>>>> my head around the workings of the API, probably because I don't know
>>>>> enough to ask the right questions of to interpret the answers...
>>>>>
>>>>> So,
>>>>>
>>>>> there is the startup delay I keep raving about.
>>>>>
>>>>> Is there a proper way to use the (C++) API to start a thread with a new
>>>>> instance of csound running a csd that has a dummy score (our needs to
>>>>> run
>>>>> for hours, just to make sure sound doesn't suddenly stop mid experiment)
>>>>> and stopping it again before reaching end of score?
>>>>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>>>>
>>>>> As I've said, we have csound listening for OSC messages and send audio
>>>>> back through socksend (again, thank you John!).
>>>>> I seems that when starting a new performance there is OSC/audio buffered
>>>>> while csound is (slowly) being started.
>>>>> The audio output starts after ca 8 seconds, and there is then a constant
>>>>> 8
>>>>> second latency until we call Stop(), wait 8 seconds for audio to stop,
>>>>> and
>>>>> then call Perform() again.
>>>>> If starting our software without our csound plugin, but with the
>>>>> receiver
>>>>> for socksend udp packets running, and starting csound from the command
>>>>> line using the same csd file as in the above example, we do not have
>>>>> this
>>>>> delay.
>>>>> It's been suggested the delayed start could be due to the need for
>>>>> loading
>>>>> libs into RAM at start, but why is there then such a difference between
>>>>> command line and API start?
>>>>>
>>>>> Since the command line is just a simple program calling the API, I
>>>>> assume
>>>>> it has to do with how we use the API - hence my questions above...
>>>>>
>>>>> Regards,
>>>>> Anders
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a definitive record of customers, application performance,
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a definitive record of customers, application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-novd2d
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

So somehow csperf.Play() is not starting a new thread and running performKsmps in it.

By the way, I don't think your other way of working is good because interrrupting csoundPeform() may cause problems.

Call csoundPerformKsmps in a loop and stop the loop when you call quit().

On 1 Dec 2011, at 15:09, Anders Genell wrote:

No, it ends with SECTION 1: so it seems to be stuck...

1 dec 2011 kl. 15:53 skrev Victor Lazzarini <Victor.Lazzarini@nuim.ie>:

Is csound actually computing (do you get the stdout messages of new alloc for instr x etc) and finishing up? Or is it stuck?

On 1 Dec 2011, at 14:42, Anders Genell wrote:

Ah! Thanks!

Well, doing -L/usr/lib -lcsnd and -lcsound in our Makefile and trying the code below starts csound (or so it seems - we at least get the stdout/err blarb), but we get no sound.

<code>
CsoundThread::CsoundThread(std::string path) :
  m_path(path), m_csound(new Csound()), perf(new CsoundPerformanceThread(m_csound))
{

}

void CsoundThread::run()
{
  m_csound->Compile((char*)m_path.c_str());
  //  m_csound->Perform();                                                                                                                    
  perf->Play();

}

int CsoundThread::quit() {
  //  m_csound->Stop();                                                                                                                       
  perf->Stop();
  //perf->Join();                                                                                                                             
  //delete perf;
  return 0;
}
</code>


Using  mcsound->Perform() and ->Stop() respectively, as in the commented lines, works, but with the aforementioned 8 second delay at first call to ::run(). If we call ::quit(), wait for sound to stop and then call ::run() again, the delay is gone, but at random occasions our csound thread freezes using 100% CPU (for that kernel) and the sound stops.

The rest of the code for our csound plugin can be found here:
http://dl.dropbox.com/u/32567399/csoundinterface.cpp
http://dl.dropbox.com/u/32567399/csoundinterface.h

Regards,
/Anders

On Thu, Dec 1, 2011 at 12:45 PM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

Under /interfaces in the csound sources. Also you will need to link to libcsnd as well as libcsound.

On 1 Dec 2011, at 11:36, Anders Genell wrote:

> Ah!
> I can't seem to find that header file anywhere, though...
>
> /Anders
>
> On 12/1/11, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
>> CsPerfThread.hpp.
>>
>> Victor
>> On 1 Dec 2011, at 10:15, Anders Genell wrote:
>>
>>> When using CsoundPerformanceThread, do I need to include some
>>> additional header or so?
>>> CsoundPerformanceThread does not seem to be declared in csound.hpp or
>>> csound.h...
>>>
>>> Regards,
>>> /Anders
>>>
>>> On 11/30/11, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
>>>> You could use the CsoundPerformanceThread class:
>>>>
>>>> Csound *cs =new Csound;
>>>> CsoundPerformanceThread *perf = new CsoundPerformanceThread(cs);
>>>>
>>>> cs.Compile(argc, argv);
>>>>
>>>> perf.Play();   // starts performance
>>>> perf.Pause();  // pauses
>>>> perf.Stop(); // stops
>>>> perf.Join();  // join and finish perf thread
>>>>
>>>> delete perf;
>>>> delete cs;
>>>>
>>>> Victor
>>>>
>>>>
>>>> On 30 Nov 2011, at 14:31, Anders Genell wrote:
>>>>
>>>>> Hi again!
>>>>>
>>>>> Instead of continuing in the thread I stole, I thought I'd start a new
>>>>> one, as is right and proper.
>>>>> I am sorry for repeating some of my questions, but I still haven't
>>>>> wrapped
>>>>> my head around the workings of the API, probably because I don't know
>>>>> enough to ask the right questions of to interpret the answers...
>>>>>
>>>>> So,
>>>>>
>>>>> there is the startup delay I keep raving about.
>>>>>
>>>>> Is there a proper way to use the (C++) API to start a thread with a new
>>>>> instance of csound running a csd that has a dummy score (our needs to
>>>>> run
>>>>> for hours, just to make sure sound doesn't suddenly stop mid experiment)
>>>>> and stopping it again before reaching end of score?
>>>>> Why would one call Perform() and not PerformKsmps() or vice versa?
>>>>>
>>>>> As I've said, we have csound listening for OSC messages and send audio
>>>>> back through socksend (again, thank you John!).
>>>>> I seems that when starting a new performance there is OSC/audio buffered
>>>>> while csound is (slowly) being started.
>>>>> The audio output starts after ca 8 seconds, and there is then a constant
>>>>> 8
>>>>> second latency until we call Stop(), wait 8 seconds for audio to stop,
>>>>> and
>>>>> then call Perform() again.
>>>>> If starting our software without our csound plugin, but with the
>>>>> receiver
>>>>> for socksend udp packets running, and starting csound from the command
>>>>> line using the same csd file as in the above example, we do not have
>>>>> this
>>>>> delay.
>>>>> It's been suggested the delayed start could be due to the need for
>>>>> loading
>>>>> libs into RAM at start, but why is there then such a difference between
>>>>> command line and API start?
>>>>>
>>>>> Since the command line is just a simple program calling the API, I
>>>>> assume
>>>>> it has to do with how we use the API - hence my questions above...
>>>>>
>>>>> Regards,
>>>>> Anders
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a definitive record of customers, application performance,
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-novd2d_______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a definitive record of customers, application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-novd2d
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel