| Periodic calls to csoundYield that does nothing will not be prohibitive if
only done once per ksmps. This can be accomplished by putting such a
csoundYield call in the main performance loop, and removing all other POLL
calls.
============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================
----- Original Message -----
From: "John D. Ramsdell"
To: "Csound Developers Discussion List"
Sent: Sunday, December 14, 2003 8:20 AM
Subject: [CSOUND-DEV:3752] Re: POLLing in Csound5
> John ffitch writes:
>
> > Does that not suggest that the POLL_EVENTS call should be textually
> > CsoundYeild (or whatever it is called)? The other question that arises
is
> > the granularity of the yeilding. Should opcodes call it, or only the
> > engine?
>
> I'm suggesting that POLL_EVENTS must be defined to be csoundYield
> whenever one is producing a library that implements the Csound API.
> When building the sources for some other purpose, one might want to
> define POLL_EVENTS() to be (1). I'm not sure how useful this
> flexibility is, unless periodic calls to a csoundYield that does nothing
> proves expensive.
>
> For wxCsound, it needs to poll just often enough so that when a user
> requests an abort of a rendering, the abort happens within a user's
> view of a reasonable delay. For this purpose, the granularity of the
> calls to csoundYield can be quite coarse, I would expect. Other
> applications may have different needs.
>
> John
> |