I've run into the same issue on Windows using, as I recall, a variety of
Csounds.

I was able to work around it. I think it was turnoff that didn't work, while
using fractional instrs with schedkwhen did work - or something like that.
On at least one occasion, xtratim was also involved.

I do recall that much time and creativity was spent in finding a solution.
It would be very helpful if fractional instruments could be investigated to
assure they are performing as they should - particularly as indefinitely
held instruments triggered via MIDI, and how they are paired with
continuations.

Art Hunkins

P.W. Thanks, Oeyvind. You were the person who first led me to schedkwhen.
I've used it in *every* piece I've written since - especially since "event"
hasn't yet made it into CsoundAV.

----- Original Message -----
From: "Oeyvind Brandtsegg" 
To: "Istvan Varga" 
Cc: 
Sent: Tuesday, March 08, 2005 11:29 AM
Subject: re: More event issues (was Re: [Cs-dev] New file release for Csound
5 and CsoundVST on Windows)


> This looks correct,
> I chime in because Michael said he do not use real time events that much,
and wanted input from those who do use them.
>
> I also do have one more thing to mention that might need fixing.
> This might seem rather exotic at first, but there's a number of scenarios
where it would be very useful (e.g. for a combination of midi driven and
algorithmic performance):
>
> I'm using xtratim to extend the life of an infinite duration event,
> giving it time to execute e.g. a release stage envelope.
> This works if I use integers for instrument numbers.
> But, If I use fractional instr numbers, the instrument does not stop when
receiving a corresponding negative instr number event.
> I've attached a simple example.
>
> best
> Oeyvind
>
>
> > From: Istvan Varga [istvan@csounds.com]
> > Sent: 2005-03-08 15:40:40 CET
> > To: csound-devel@lists.sourceforge.net
> > Subject: More event issues (was Re: [Cs-dev] New file release for Csound
5 and CsoundVST on Windows)
> >
> > The current issues related to event handling to be solved are:
> >
> >    * Order of executing initialization pass of instrument events
> >      that arrive within the same k-period.
> >      This is currently as follows:
> >        1. all "normal" score notes (that is, what you can find in
> >           .sco and .csd files), sorted by instrument number.
> >        2. all real time events created by insert_score_event(),
> >           sorted by order of receiving events (that is the one
> >           that comes first will be served first), but *not* by
> >           instrument number.
> >        3. all real time MIDI events (device and file mixed), same
> >           rules apply as to 2.
> >        4. all line events (this category no longer includes anything
> >           other than actual text that is entered when -L stdin
> >           is turned on), exact order is not known, but not sorted
> >           by instrument number).
> >      It is important to note that the performance pass of all notes
> >      is correctly sorted by instrument number, regardless of how
> >      the note was created. The question is whether i-time calls of
> >      real time events should also be sorted by instrument number
> >      (there are some issues that can make this difficult to implement),
> >      or should the rule be "standard score notes are initialized
> >      first (in sorted order), and real time events later (in undefined
> >      order)", as it already has been ?
> >
> >    * schedule and schedwhen opcodes.
> >      These opcodes have features that are not supported by
> >      insert_score_event(), and are somewhat similar to subinstruments
> >      and user defined opcodes, just not as well implemented:
> >        * calling the scheduled instrument immediately at i-time as
> >          if it was a subinstrument and then returning to the context
> >          of the parent instrument. This depends on the function
> >          insert_event() in insert.c, which could be removed (having
> >          three different "insert" functions to maintain is a pain)
> >          in case the feature is not found to be useful.
> >        * passing MIDI parameters to the newly turned on note,
> >          also done by insert_event()
> >        * turning off the created note if it has indefinite duration
> >          when the parent note is turned off; this is implemented
> >          with some rather ugly hacks that often do not work correctly,
> >          and if the start time is not zero, do not work at all.
> >      All the above are possible with subinstruments and user defined
> >      opcodes, but, for compatibility, need to exist in schedule even
> >      with all the quirks and difficult to fix bugs.
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net