Sorry to keep harping on this string - please become a developer on Csound
SourceForge CVS? Then you won't have to send us these emails, and we won't
have to remember to do as you suggest.

============================================
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: "Matt J. Ingalls" 
To: "Csound Developers Discussion List" 
Sent: Monday, November 24, 2003 2:36 PM
Subject: [CSOUND-DEV:3494] Re: Musmon, cleanup(), csoundCleanup()


>
> if performances are interrupted "cleanly" they should call cleanup() -
> the setjmp works pretty good this way, ive had very little problems not
> cleaning up properly as long as i check the return of every
> performBuffer/perormKsmps call, and then call cleanup() in the api.  only
> times that there is not a proper
> cleanup is a crash.
>
> also i should mention my previous response, i had a typo and in musmon()
> the cleanup() is called when !runincomponents - the actual code is:
>
>     if (runincomponents) {
>       if (frsturnon != NULL)           /* if something in turnon list  */
>         kturnon();                     /*   turnon now                 */
>       return 0;                        /* we exit here playevents later*/
>     }
>     playevents();                      /* play all events in the score */
>     return cleanup();
>
> and  it looks like in csound5,  msumon() is used for running in
> components(reentrant via api) and musmon2 is used for oldstyle straight
> through, which is why musmon2() calls cleanup() and musmon() doesnt?
>
> -m
>
>
>
>
> On Mon, 24 Nov 2003, Michael Gogins wrote:
>
> > If all performances ended normally, it would only be necessary to call
reset
> > after performing. But if a performance is interrupted, I thought it
might be
> > necessary to call reset before performing again. I also found that
putting a
> > call to reset before performing helped me catch some bugs in other reset
> > code (not setting pointers to null at the very beginning, failing to
check
> > for null pointers in other reset calls, etc.).
> >
> > It would be simpler to all reset ONLY before performing, but then if
Csound
> > allocates a huge heap of memory during performance, that remains locked
up
> > and unavailable after performance and until the next performance.
> >
> > So I think calling reset both before and after performing is actually
best.
> > If that's not the order you found in your graph, then the order should
be
> > changed.
> >
> > ============================================
> > 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: "stevenyi" 
> > To: "Csound Developers Discussion List" 
> > Sent: Sunday, November 23, 2003 1:07 AM
> > Subject: [CSOUND-DEV:3463] Musmon, cleanup(), csoundCleanup()
> >
> >
> > > Hi all,
> > >
> > > I noticed in the call graph I generated from running csound4, if using
> > > ccsound.c and csound.c, reset() gets called twice in a run, once at
the
> > > end of musmon(), and again when calling csoundCleanup().
> > >
> > > Looking at csound5 cvs, musmon2 calls reset as well, and maybe there's
a
> > > potential for calling reset() twice here as well if csoundCleanup() is
> > > called.
> > >
> > > I think this would happen only if using the csound host API to run,
but
> > > not if using jpff_glue.c.  Don't know if it's a problem to run
cleanup()
> > > twice in a run, but seemed strange so I thought I'd mention it.
> > >
> > > Thanks,
> > > steven
> > >
> > >
> >
> >
>

i am as of last week.

anyway, im not suggesting to do anything - other than make sure any
csoundlib host calls csoundCleanup() when a performance is
terminated (prematurely with errors, or not)

as for the code i included, it came directly from canonical sources.
sorry for my inability to write coherently --

-m

On Mon, 24 Nov 2003, Michael Gogins wrote:

> Sorry to keep harping on this string - please become a developer on Csound
> SourceForge CVS? Then you won't have to send us these emails, and we won't
> have to remember to do as you suggest.
>
> ============================================
> 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: "Matt J. Ingalls" 
> To: "Csound Developers Discussion List" 
> Sent: Monday, November 24, 2003 2:36 PM
> Subject: [CSOUND-DEV:3494] Re: Musmon, cleanup(), csoundCleanup()
>
>
> >
> > if performances are interrupted "cleanly" they should call cleanup() -
> > the setjmp works pretty good this way, ive had very little problems not
> > cleaning up properly as long as i check the return of every
> > performBuffer/perormKsmps call, and then call cleanup() in the api.  only
> > times that there is not a proper
> > cleanup is a crash.
> >
> > also i should mention my previous response, i had a typo and in musmon()
> > the cleanup() is called when !runincomponents - the actual code is:
> >
> >     if (runincomponents) {
> >       if (frsturnon != NULL)           /* if something in turnon list  */
> >         kturnon();                     /*   turnon now                 */
> >       return 0;                        /* we exit here playevents later*/
> >     }
> >     playevents();                      /* play all events in the score */
> >     return cleanup();
> >
> > and  it looks like in csound5,  msumon() is used for running in
> > components(reentrant via api) and musmon2 is used for oldstyle straight
> > through, which is why musmon2() calls cleanup() and musmon() doesnt?
> >
> > -m
> >
> >
> >
> >
> > On Mon, 24 Nov 2003, Michael Gogins wrote:
> >
> > > If all performances ended normally, it would only be necessary to call
> reset
> > > after performing. But if a performance is interrupted, I thought it
> might be
> > > necessary to call reset before performing again. I also found that
> putting a
> > > call to reset before performing helped me catch some bugs in other reset
> > > code (not setting pointers to null at the very beginning, failing to
> check
> > > for null pointers in other reset calls, etc.).
> > >
> > > It would be simpler to all reset ONLY before performing, but then if
> Csound
> > > allocates a huge heap of memory during performance, that remains locked
> up
> > > and unavailable after performance and until the next performance.
> > >
> > > So I think calling reset both before and after performing is actually
> best.
> > > If that's not the order you found in your graph, then the order should
> be
> > > changed.
> > >
> > > ============================================
> > > 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: "stevenyi" 
> > > To: "Csound Developers Discussion List" 
> > > Sent: Sunday, November 23, 2003 1:07 AM
> > > Subject: [CSOUND-DEV:3463] Musmon, cleanup(), csoundCleanup()
> > >
> > >
> > > > Hi all,
> > > >
> > > > I noticed in the call graph I generated from running csound4, if using
> > > > ccsound.c and csound.c, reset() gets called twice in a run, once at
> the
> > > > end of musmon(), and again when calling csoundCleanup().
> > > >
> > > > Looking at csound5 cvs, musmon2 calls reset as well, and maybe there's
> a
> > > > potential for calling reset() twice here as well if csoundCleanup() is
> > > > called.
> > > >
> > > > I think this would happen only if using the csound host API to run,
> but
> > > > not if using jpff_glue.c.  Don't know if it's a problem to run
> cleanup()
> > > > twice in a run, but seemed strange so I thought I'd mention it.
> > > >
> > > > Thanks,
> > > > steven
> > > >
> > > >
> > >
> > >
> >
>
>

OK How do I do that?
I'm ready to join. I could not figure how.
I already have an account at Sourceforge.
Robert

-----Original Message-----
From: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu]On Behalf Of Michael Gogins
Sent: Monday, November 24, 2003 7:22 PM
To: Csound Developers Discussion List
Subject: [CSOUND-DEV:3495] Re: Musmon, cleanup(), csoundCleanup()


Sorry to keep harping on this string - please become a developer on Csound
SourceForge CVS? Then you won't have to send us these emails, and we won't
have to remember to do as you suggest.

============================================
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: "Matt J. Ingalls" 
To: "Csound Developers Discussion List" 
Sent: Monday, November 24, 2003 2:36 PM
Subject: [CSOUND-DEV:3494] Re: Musmon, cleanup(), csoundCleanup()


>
> if performances are interrupted "cleanly" they should call cleanup() -
> the setjmp works pretty good this way, ive had very little problems not
> cleaning up properly as long as i check the return of every
> performBuffer/perormKsmps call, and then call cleanup() in the api.  only
> times that there is not a proper
> cleanup is a crash.
>
> also i should mention my previous response, i had a typo and in musmon()
> the cleanup() is called when !runincomponents - the actual code is:
>
>     if (runincomponents) {
>       if (frsturnon != NULL)           /* if something in turnon list  */
>         kturnon();                     /*   turnon now                 */
>       return 0;                        /* we exit here playevents later*/
>     }
>     playevents();                      /* play all events in the score */
>     return cleanup();
>
> and  it looks like in csound5,  msumon() is used for running in
> components(reentrant via api) and musmon2 is used for oldstyle straight
> through, which is why musmon2() calls cleanup() and musmon() doesnt?
>
> -m
>
>
>
>
> On Mon, 24 Nov 2003, Michael Gogins wrote:
>
> > If all performances ended normally, it would only be necessary to call
reset
> > after performing. But if a performance is interrupted, I thought it
might be
> > necessary to call reset before performing again. I also found that
putting a
> > call to reset before performing helped me catch some bugs in other reset
> > code (not setting pointers to null at the very beginning, failing to
check
> > for null pointers in other reset calls, etc.).
> >
> > It would be simpler to all reset ONLY before performing, but then if
Csound
> > allocates a huge heap of memory during performance, that remains locked
up
> > and unavailable after performance and until the next performance.
> >
> > So I think calling reset both before and after performing is actually
best.
> > If that's not the order you found in your graph, then the order should
be
> > changed.
> >
> > ============================================
> > 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: "stevenyi" 
> > To: "Csound Developers Discussion List" 
> > Sent: Sunday, November 23, 2003 1:07 AM
> > Subject: [CSOUND-DEV:3463] Musmon, cleanup(), csoundCleanup()
> >
> >
> > > Hi all,
> > >
> > > I noticed in the call graph I generated from running csound4, if using
> > > ccsound.c and csound.c, reset() gets called twice in a run, once at
the
> > > end of musmon(), and again when calling csoundCleanup().
> > >
> > > Looking at csound5 cvs, musmon2 calls reset as well, and maybe there's
a
> > > potential for calling reset() twice here as well if csoundCleanup() is
> > > called.
> > >
> > > I think this would happen only if using the csound host API to run,
but
> > > not if using jpff_glue.c.  Don't know if it's a problem to run
cleanup()
> > > twice in a run, but seemed strange so I thought I'd mention it.
> > >
> > > Thanks,
> > > steven
> > >
> > >
> >
> >
>

On Mon, 24 Nov 2003, Michael Gogins wrote:

> Sorry to keep harping on this string - please become a developer on Csound
> SourceForge CVS? Then you won't have to send us these emails, and we won't
> have to remember to do as you suggest.
> 
matt is a developer, and has been for some days
==John ff