Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:3720] Re: POLLing in Csound5

Date2003-12-08 16:09
From"gogins@pipeline.com"
Subject[CSOUND-DEV:3720] Re: POLLing in Csound5
To exit from the process, that would be fine.

But I think John meant, exit from rendering without exiting the process, as
in CsoundVST or wxCsound which call directly into the Csound API for
repeated renderings.

Original Message:
-----------------
From: Gabriel Maldonado g.maldonado@inwind.it
Date: Mon, 08 Dec 2003 15:24:48 +0100
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3717] Re: POLLing in Csound5


What about a simple exit() call, called in the main thread after an 
eventual cleanup? It seems to have no drawbacks, at least under winzoz.

Gabriel

John ffitch wrote:
> For Linux, Unix and OSX there is no need.  My only concern was that an 
> opcode may like to have an early exit if for exampel a stop button was 
> pressed.  Or is there some other API stuff about that?
> ==John
> 
> 


-- 
Gabriel Maldonado
http://csounds.com/maldonado
--


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Date2003-12-08 16:19
Fromramsdell@mitre.org (John D. Ramsdell)
Subject[CSOUND-DEV:3721] Re: POLLing in Csound5
"gogins@pipeline.com"  writes:

> But I think John meant, exit from rendering without exiting the process, as
> in CsoundVST or wxCsound which call directly into the Csound API for
> repeated renderings.

wxCsound uses polling to gracefully abort a rendering.  When a user
asks for an abort, the GUI thread sets a mutex controlled flag, one
that the worker thread repeatedly checks during each call to
POLL_EVENTS.  When the flag is set, POLL_EVENTS returns 0, and the
rendering halts.  This graceful form of exits lets the Csound engine
clean up and make itself ready for the next run.

John

Date2003-12-08 17:17
Fromramsdell@mitre.org (John D. Ramsdell)
Subject[CSOUND-DEV:3722] Re: POLLing in Csound5
ramsdell@mitre.org (John D. Ramsdell) writes:

> wxCsound uses polling to gracefully abort a rendering.  

To be a little more precise, wxCsound registers a polling function using the
Csound API function csoundSetYieldCallback.  It never mentions
POLL_EVENTS.  This is why I compile libcsound with -DUSE_CSOUND_YIELD,
so I know that polling API works on all platforms.

John

Date2003-12-08 20:29
Fromramsdell@mitre.org (John D. Ramsdell)
Subject[CSOUND-DEV:3724] Re: csound4 - configure.ac, main.c
So is it now building for you once again?

John

steven  writes:

> Hi all,
> 
> I changed the setting on configure.ac to binary so that it will
> maintain it's unix endlines.  Also, I've changed main.c to #ifdef for
> SIGALRM as mentioned in a previous email. Thanks,
> steven

Date2003-12-08 20:39
Fromsteven
Subject[CSOUND-DEV:3723] csound4 - configure.ac, main.c
Hi all,

I changed the setting on configure.ac to binary so that it will maintain 
it's unix endlines.  Also, I've changed main.c to #ifdef for SIGALRM as 
mentioned in a previous email. 

Thanks,
steven

Date2003-12-08 21:10
Fromsteven
Subject[CSOUND-DEV:3726] Re: csound4 - configure.ac, main.c
Almost.  But it's an unrelated error:

libcsound.a(winFLTK.o)(.text+0x11): In function `Graphable_':
/cygdrive/f/eclipse/workspace/csound4/csound/winFLTK.c:44: undefined 
reference t
o `_XOpenDisplay'

Don't know much about this one.  I'm going to disable graphics and fltk 
and give it another whirl in a second.

steven

John D. Ramsdell wrote:

>So is it now building for you once again?
>
>John
>
>steven  writes:
>
>  
>
>>Hi all,
>>
>>I changed the setting on configure.ac to binary so that it will
>>maintain it's unix endlines.  Also, I've changed main.c to #ifdef for
>>SIGALRM as mentioned in a previous email. Thanks,
>>steven
>>    
>>
>
>
>
>  
>

Date2003-12-08 22:39
Fromramsdell@mitre.org (John D. Ramsdell)
Subject[CSOUND-DEV:3729] Re: csound4 - configure.ac, main.c
steven  writes:

> Almost.  But it's an unrelated error:
> 
> libcsound.a(winFLTK.o)(.text+0x11): In function `Graphable_':
> /cygdrive/f/eclipse/workspace/csound4/csound/winFLTK.c:44: undefined
> reference t
> o `_XOpenDisplay'

This is the problem I reported with the subject line with winFLTK.c in
it.  I looked in the FLTK documentation, and I did not see any FLTK
only way to ask if a FLTK display is available.  I'm stumped.

I hacked Graphable_ so it simply returns 1, and linking succeeds, but
csound.exe exits immediately when invoked.  I did not try running it
under gdb.  If Cygwin has strace, maybe that will help too.

But the good news is, the configure.ac script if fixed again for
Cgywin CVS users.  Thanks again.  I was so worried.

John

Date2003-12-08 23:53
Fromsteven
Subject[CSOUND-DEV:3730] Re: csound4 - configure.ac, main.c
Yeah, I was a bit stumped on the Cygwin CVS issue and I'm really glad it 
was a simple solution in the end.  I'm glad that the configure script is 
working as it's the only way I've personally ever gotten csound compiled 
on windows which helps me a lot. 

I've also set configure.in in Csound5 to binary as the same issue occurs 
with that. 

So I got sucked into looking at winFLTK and editing Graphable_  to 
return 1 as well and it just dies.  Strangely enough, putting printf's 
even at the beginning of main in ccsound.c doesn't print.  So... no clue 
here on that yet.

steven



John D. Ramsdell wrote:

>steven  writes:
>
>  
>
>>Almost.  But it's an unrelated error:
>>
>>libcsound.a(winFLTK.o)(.text+0x11): In function `Graphable_':
>>/cygdrive/f/eclipse/workspace/csound4/csound/winFLTK.c:44: undefined
>>reference t
>>o `_XOpenDisplay'
>>    
>>
>
>This is the problem I reported with the subject line with winFLTK.c in
>it.  I looked in the FLTK documentation, and I did not see any FLTK
>only way to ask if a FLTK display is available.  I'm stumped.
>
>I hacked Graphable_ so it simply returns 1, and linking succeeds, but
>csound.exe exits immediately when invoked.  I did not try running it
>under gdb.  If Cygwin has strace, maybe that will help too.
>
>But the good news is, the configure.ac script if fixed again for
>Cgywin CVS users.  Thanks again.  I was so worried.
>
>John
>
>
>
>  
>