Thanks for opening this discussion. I don't use the real-time note input
facilities much so I'm not the best source for suggestions. I hope others
who do use them will chime in.

Basically, I am most concerned about order of instrument performance from
the standpoint of orchestras that route audio. In other words, in my
orchestras instruments feed other instruments which feed effects, and both
effects and instruments then feed a mixer. If this will continue to work
with real-time events, that is wonderful. I'm not sure of the impact of out
of order i-time calls, but in my orchestras, the i-time calls that need to
be in order would probably be the effects and mixers which are controlled
by the score, so that probably doesn't matter as much.

The schedule and subinstrument opcodes offer important possibilities for
more extensive real-time control of Csound. Again I don't do much of this
and so I lack experience, but perhaps I can help focus on desirable
functionality. It should be possible to have scheduled events and
subinstruments acting the same way in a score-driven performance as in a
real-time driven performance. Backward compatibility is important -- but in
my view, getting this to happen is more important. 

The use case I have in mind here is a performer who uses a keyboard to
trigger an instrument in real time, and that instrument then triggers a lot
of other things inside Csound.


Original Message:
-----------------
From: Istvan Varga istvan@csounds.com
Date: Tue, 08 Mar 2005 15:40:40 +0100
To: csound-devel@lists.sourceforge.net
Subject: More event issues (was Re: [Cs-dev] New file release for Csound
5and 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

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .




-------------------------------------------------------
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_ide95&alloc_id396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

For what it's worth, when this is sorted, we have code that will test 
these scenarios with event. In my gig ensemble I have layers of notes 
getting 'evented' from real time playing, from another instrument ( 
sequencer ) and regular score calls.

Just let me know when I should recompile csound5 and test that.
iain

gogins@pipeline.com wrote:
> Thanks for opening this discussion. I don't use the real-time note input
> facilities much so I'm not the best source for suggestions. I hope others
> who do use them will chime in.
> 
> Basically, I am most concerned about order of instrument performance from
> the standpoint of orchestras that route audio. In other words, in my
> orchestras instruments feed other instruments which feed effects, and both
> effects and instruments then feed a mixer. If this will continue to work
> with real-time events, that is wonderful. I'm not sure of the impact of out
> of order i-time calls, but in my orchestras, the i-time calls that need to
> be in order would probably be the effects and mixers which are controlled
> by the score, so that probably doesn't matter as much.
> 
> The schedule and subinstrument opcodes offer important possibilities for
> more extensive real-time control of Csound. Again I don't do much of this
> and so I lack experience, but perhaps I can help focus on desirable
> functionality. It should be possible to have scheduled events and
> subinstruments acting the same way in a score-driven performance as in a
> real-time driven performance. Backward compatibility is important -- but in
> my view, getting this to happen is more important. 
> 
> The use case I have in mind here is a performer who uses a keyboard to
> trigger an instrument in real time, and that instrument then triggers a lot
> of other things inside Csound.
> 
> 
> Original Message:
> -----------------
> From: Istvan Varga istvan@csounds.com
> Date: Tue, 08 Mar 2005 15:40:40 +0100
> To: csound-devel@lists.sourceforge.net
> Subject: More event issues (was Re: [Cs-dev] New file release for Csound
> 5and 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
> 
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> 
> -------------------------------------------------------
> 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_ide95&alloc_id396&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

Iain Duncan wrote:

> For what it's worth, when this is sorted, we have code that will test 
> these scenarios with event. In my gig ensemble I have layers of notes 
> getting 'evented' from real time playing, from another instrument ( 
> sequencer ) and regular score calls.
> 
> Just let me know when I should recompile csound5 and test that.
> iain

The latest fixes are already in the public CVS, and there are
surely enough changes in many areas to be worth testing.


-------------------------------------------------------
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