It seems to me that the API means that there should be no reason to
poll the interface from inside csound, and this would be left to the
user interface, probably running on a separate thread.  Is this
really the case?  Can I remove all POLL_EVENTS code?  It would simplify
a great deal.

Also, in a similar vein, winX11 winFLTK etc should be removed.  Any
thoughts?

I now have a csound5 compiling on OSX, but not tested.

==John ffitch

i do currently use the POLL_EVENTS as a way for my
host to signal to csound to terminate [and cleanup properly] - if
you have a better solution to do this please implement it.

the only place i have found the REAL need to use POLL_EVENTS is in the
analysis utilities [for the grahic displays] - as those processes are not
reentrant, but if the were made so, then poll_events could go away there
too..

thanks,
-m






On Mon, 8 Dec 2003 jpff@codemist.co.uk wrote:

> It seems to me that the API means that there should be no reason to
> poll the interface from inside csound, and this would be left to the
> user interface, probably running on a separate thread.  Is this
> really the case?  Can I remove all POLL_EVENTS code?  It would simplify
> a great deal.
>
> Also, in a similar vein, winX11 winFLTK etc should be removed.  Any
> thoughts?
>
> I now have a csound5 compiling on OSX, but not tested.
>
> ==John ffitch
>
>

On 12/8/03 10:20 AM, gogins@pipeline.com etched in
stone:

> For Csound5, I think your idea is best. Csound internally should not poll.
> But I don't know the code well enough to say that nothing will break if
> POLL is removed.
> 
> Clients could either poll in a separate thread, or they could render one
> ksmps at a time and then poll in the same thread.

This would seem to be fine for rendering ordinary orch/score pairs.  The
only concern for the Legacy Mac version is if it takes too long to render a
ksmps on a slower machine, the computer will appear non-responsive to the
user.

On 12/8/03 3:29 PM, Matt J. Ingalls etched in stone:

> 
> the only place i have found the REAL need to use POLL_EVENTS is in the
> analysis utilities [for the grahic displays] - as those processes are not
> reentrant, but if the were made so, then poll_events could go away there
> too..

I must second the need right now for POLL_EVENTS in the utilities.  If I
understand correctly, they must currently be run in "one pass."  If the code
does not call the POLL_EVENTS macro or the YieldCallback funtion set by the
host, then NO user activity will get through on the Legacy Mac until the
analysis finishes.

Cooperative multitasking sucks :(

Anthony Kozar
anthony.kozar@utoledo.edu

Next time you update your sandbox for the csound module, be sure to
specify the -d switch.

John

Anthony Kozar  writes:

> I must second the need right now for POLL_EVENTS in the utilities.  If I
> understand correctly, they must currently be run in "one pass."  If the code
> does not call the POLL_EVENTS macro or the YieldCallback funtion set by the
> host, then NO user activity will get through on the Legacy Mac until the
> analysis finishes.
> 
> Cooperative multitasking sucks :(

Anthony,

Even on machines that support preemptive multitasking, it is important
to retain the code that periodically calls POLL_EVENTS, and to always
define POLL_EVENTS to be csoundYield when compiling the code to be
used to build a library that implements the Csound API.  Otherwise,
the csoundYieldCallback routine will fail to fulfill its contract, and
applications that want to perform actions in the rending thread
periodically will be unable to do so.

John

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?
==John ff

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

I vote for the engine; in the worst case, it can be called every 
k-cycle, which is most unlikely to be too slow; and the engine can take 
responsibility for it where the orch itself is very slow. I don't think 
opcodes need, nor should have, any interest in polling host events at 
all. Calling in opcodes relies on opcode authors playing ball, and 
raises the prospect of range between hardly any to a ludicrous number of 
calls, in excess of once per sample. It seems more appropriate for the 
host to call (hypothetically) POLL_ORCH() periodically to find out where 
it is, if that is ever likely to be necessary.


Richard Dobson


John ffitch wrote:
> 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?
> ==John ff
> 
>