>From the Csound manual for the -L flag:

Read line-oriented real-time score events from device DEVICE. The name stdin 
will permit score events to be typed at your terminal, or piped from another 
process. Each line-event is terminated by a carriage-return. Events are 
coded just like those in a standard numeric score, except that an event with 
p2=0 will be performed immediately, and an event with p2=T will be performed 
T seconds after arrival. Events can arrive at any time, and in any order. 
The score carry feature is legal here, as are held notes (p3 negative) and 
string arguments, but ramps and pp or np references are not.

In other words, p2=0 means perform the event at the current time, "now". 
This is what we should do in your new code.

If the current code isn't complete, I would like to do a file release that 
is more finished fairly soon -- I also need to do more work on the Loris 
opcodes. But it has been months since a Windows file release. The things 
that I usually test did work: standard file rendering, real-time audio, VST 
performance, Python performance.

I think it would be a good idea to create an RPM package similar to the 
Windows installer.


----- Original Message ----- 
From: "Istvan Varga" 
To: 
Sent: Tuesday, March 08, 2005 8:01 AM
Subject: Re: [Cs-dev] New file release for Csound 5 and CsoundVST on Windows


> Oeyvind Brandtsegg wrote:
>
>> using -Lstdin now leads to an error,
>> but seemingly, python can send messages to csound even
> > when -L is not enabled. Is this supposed to work this way ?
> > Have the method of sending events from Python to Csound changed ?
>
> Yes, -L is no longer needed for anything other than actual
> line events. I have created a function that allows inserting
> events without any -L hacks, and I am changing code to use
> this single function.
>
>> On a related subject, I seem to get very short duration for
> > the events that Python sends to Csound. Even if the p3 parameter
> > is correctly interpreted by csound. If I use xtratim, I can
> > extend the event's duration so one can hear the instrument play,
> > briefly.
>
> Hmm, I have a question to Michael Gogins: how is the csoundScoreEvent
> function supposed to handle p2 ? I have assumed that it is the time
> in seconds since the beginning of the current section, but I may have
> been wrong...
> Unfortunately there is no documentation on this subject.
>
> The main problem is that the file release was made in the middle of
> major code changes, and I did not know about it (was now announced),
> and as such had no chance of extensive testing before the release.
>
>
> -------------------------------------------------------
> 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

Michael Gogins wrote:

> Read line-oriented real-time score events from device DEVICE. The name 
> stdin will permit score events to be typed at your terminal, or piped 
> from another process. Each line-event is terminated by a 
> carriage-return. Events are coded just like those in a standard numeric 
> score, except that an event with p2=0 will be performed immediately, and 
> an event with p2=T will be performed T seconds after arrival. Events can 
> arrive at any time, and in any order. The score carry feature is legal 
> here, as are held notes (p3 negative) and string arguments, but ramps 
> and pp or np references are not.

OK, I know that, but I was asking about csoundScoreEvent(), not -L
(by the way, should -L stdin be allowed under Windows ?).
So, the questions are:
   1. from when should it count the time ?
   2. should it allow the carry feature ? If yes, that is bad news
      because I will then need to revert to using line events for
      this particular function. Although, as far as I know, it did
      not support the carry feature earlier (at least reading the
      (now removed) newevent() function on which csoundScoreEvent()
      was based).

Here is the new function on which now most "create a new event"
type features are based (note: it does not support carry):

/* Schedule new score event to be played. 'time_ofs' is the amount of */
/* time in seconds to add to evt->p[2] to get the actual start time   */
/* of the event (measured from the beginning of performance, and not  */
/* section) in seconds.                                               */
/* If 'allow_now' is non-zero and event type is 'f', the function     */
/* table may be created immediately depending on start time.          */
/* Required parameters in 'evt':                                      */
/*   char   *strarg   string argument of event (NULL if none)         */
/*   char   opcod     event opcode (a, e, f, i, l, q, s)              */
/*   short  pcnt      number of p-fields (>=3 for q, i, a; >=4 for f) */
/*   MYFLT  p[]       array of p-fields, p[1]..p[pcnt] should be set  */
/*  p2orig and p3orig are calculated from p[2] and p[3].              */
/* The contents of 'evt', including the string argument, need not be  */
/* preserved after calling this function, as a copy of the event is   */
/* made.                                                              */
/* Return value is zero on success.                                   */

int insert_score_event(ENVIRON *csound, EVTBLK *evt, double time_ofs,
                        int allow_now);

This function will eventually be part of the API (maybe with a
different name), once I am sure that it does not need further
changes that may break compatibility.

Here is the current state of csoundScoreEvent() in Top/csound.c:

   PUBLIC int csoundScoreEvent(void *csound, char type,
                               MYFLT *pfields, long numFields)
   {
     EVTBLK        evt;
     int           i;

     evt.strarg = NULL;
     evt.opcod = type;
     evt.pcnt = (short) numFields;
     for (i = 0; i < (int) numFields; i++)
       evt.p[i + 1] = pfields[i];
     return
       insert_score_event((ENVIRON*) csound, &evt,
                          ((ENVIRON*) csound)->sensEvents_state.timeOffs, 0);
   }

((ENVIRON*) csound)->sensEvents_state.timeOffs is the start time of the
current section, in seconds. If you want times relative to current time,
replace it with ((ENVIRON*) csound)->sensEvents_state.curTime.


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

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

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
> 

Oeyvind Brandtsegg wrote:

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

Your example worked fine with my current build, other than the fact
that the -b and -B settings in the CSD made Csound hang, so I had
to set more usable values on the command line. But xtratim was OK,
and the note did turn off at 2.6 seconds.



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

ok. that's good news.
Sorry for reporting bugs that have been fixed.
Looking forward to the next release.

Oeyvind


> From: Istvan Varga [istvan@csounds.com]
> 
> Your example worked fine with my current build, other than the fact
> that the -b and -B settings in the CSD made Csound hang, so I had
> to set more usable values on the command line. But xtratim was OK,
> and the note did turn off at 2.6 seconds.
> 

Oeyvind Brandtsegg wrote:

> ok. that's good news.
> Sorry for reporting bugs that have been fixed.
> Looking forward to the next release.

This is really strange. I have just tested the CSD with csound.exe
(from the Win32 file release) using WINE, and it worked. Did you
use the same release ?


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

Funny, I tested it with the (March 7)  release again this morning,
and it works.
I must have been very tired and mixed up what version I was testing on,
sorry once more, it won't happen again.
Oeyvind

> From: Istvan Varga [istvan@csounds.com]
> Sent: 2005-03-08 20:50:54 CET
> To: csound-devel@lists.sourceforge.net
> Subject: Re: More event issues (was Re: [Cs-dev] New file release for Csound 5 and CsoundVST on Windows)
> 
> Oeyvind Brandtsegg wrote:
> 
> > ok. that's good news.
> > Sorry for reporting bugs that have been fixed.
> > Looking forward to the next release.
> 
> This is really strange. I have just tested the CSD with csound.exe
> (from the Win32 file release) using WINE, and it worked. Did you
> use the same release ?
> 
> 
> -------------------------------------------------------
> 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
>