Hi Matt,

I'd rather have it as Victor mentioned and have a flag to turn on
indefinite rendering rather than break what is the current behavior
and have it turned on automatically.  I can understand the troubles of
indefinite realtime usage and having to make sure everything is set
up, but I think that adding the flag Victor mentioned would be the
ideal way to go, maybe it just makes more sense in my head that way
and would seem to solve the problem.

As for Instrument 0, I'm a little confused as to what happens.  At the
end of oload, it calls init0 in insert.c, which allocates an instance
of instr0 and runs all itime code, which I assume makes it also a part
of the active list.  That means that even as it is now, it runs
through all OPDS entries on each kperf to look for k- or a-rate opcode
functions, which in instr 0 as it is now, will always be NULL.  Seems
inefficient, especially for orchestras with very large instr 0 code.
(This is a separate issue, and also one in which I might be
misunderstanding.)

Now, if instrument 0 is made to allow for non i-time code, I think the
only thing that would need to be done is to remove that one check in
oload:

    while (bp != (OPTXT *) NULL && (bp = bp->nxtop) != NULL) {
      /* chk instr 0 for illegal perfs */
      int thread, opnum = bp->t.opnum;
      if (opnum == ENDIN) break;
      if (opnum == LABEL) continue;
      if ((thread = csound->opcodlst[opnum].thread) & 06 ||
          (!thread && bp->t.pftype != 'b'))
        synterr(csound, Str("perf-pass statements illegal in header blk"));
    }

That could lead to interesting techniques, i.e. an always-on
oscillator for mono-synths, lfo's.  There must be a rational for why
there is all the checking and restrictions for instrument 0, but what
they are I don't know.  Perhaps it is to encourage a certain
programming style, or to prevent other bugs from happening.

Going back to the indefinite render mode, it seems that it might be
possible to simply change the very last line of code in sensevents (in
musmon.c) to look at the csound->oparms for an indefinite flag (would
need to add that) to see whether to return a 2 or a 0.  Not sure
though what else if anything would be required.

steven


On 9/18/06, matt ingalls <matt@sfsound.org> wrote:
>
> On Sep 17, 2006, at 3:00 PM, Steven Yi wrote:
>
> > Hi matt,
> >
> > For the check for allowable opcodes in instr0, there's one in otran
> > (you can search for "thread" to find it).  I am planning for the new
> > parser to parse instrument 0 space like any other instrument, but then
> > do the same verification and have restrictions as in the past.
>
> ok. but my question is: why have restrictions?  [ especially if instr0
> is like any other instr except only one instance with infinite dur ]
>
> >
> > For my own working method, for having an implicit option in real-time
> > render to be always on, are you implying that if you render in
> > realtime it should always just stay on regardless of if the score ends
> > or not?
>
> yes
>
> >   If so, I can understand that if you're doing real-time
> > performance, but for the use-case of people like me who are mostly not
> > concerned with real-time performance but am interested in real-time
> > auditioning of a piece, this would not work.
>
> well that is why i said add a commandline flag (like -T or just
> modify -T itself)
>   to terminate real-time performance at the end of the score.
>
> Victor suggested the opposite, which is OK with
> me [ i'll just have my front-end automatically add it ] but i was
> thinking
> that we already have occasional questions from people asking why they
> can't render in real-time because they don't know/remember to add
> an f0 in their score.  if we made a commandline option, the problem
> would
> still remain the same, if we make it automatic then the problem would
> go away.
>
> Would it make other problems?  i don't know - i guess i could see issues
> with accumulating processes that never end, or issues with cleaning up
> when you ctrl-c out of a render or things like that..  if these are
> potential
> problems then certainly just add an "endless" commandline flag.
>
> -m
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net