Yes, I'd say if you're trying to use PmPoll() to check
if there is input, then a midi msg is 
only there if it returns true. Did you try 
changing the code?

Victor
> 
> Hi John and all,
> 
> Thanks for adding the listing of portmidi devices.  I'm
> using (I  believe) the correct device number now (-M 1)
> and things seem to be  opening correctly, but when running
> , all I get is the following error:
> 
> sensMIDI: retval errno 11
> 
> I tried calling Pm_GetErrorText on the number but got an
> invalid error  number.
> 
> I added some code  to check if the Pm_OpenInput returned 
a
> non-zero  (commited the code to CVS), but there is no
> error being reported, so the  stream seems to be opening
> alright. 
> 
> I'm not sure the following is correct in pmidi.c:
> 
>  if ((retval=Pm_Poll(midistream))) {
>         if (retval<0) printf(Str(X_1185,"sensMIDI: retval
> errno %d\n"),  errno);
>         if (retval == 0) {
>           long n = Pm_Read(midistream, bufp, MBUFSIZ);
>           bufp = mbuf;
>           endatp = mbuf + n;
>           return n;
>         }
>         else {
>           printf(Str(X_1185,"sensMIDI: retval errno %d\n")
> ,errno);
>         }
>       }
>       return 0;
> 
> it seems to me that it should check if retval == 1, as the
> docs for  Pm_Poll say it returns TRUE, FALSE, or and error
> number, and TRUE is set  to 1.  Am I incorrect?
> 
> Thanks,
> steven
> 

Hi Victor,

I did try changing to test for 1.  I didn't get the the errno messages, 
but neither did I get any midi input.  Will try out some more later tonight.

steven

Victor Lazzarini wrote:

>Yes, I'd say if you're trying to use PmPoll() to check
>if there is input, then a midi msg is 
>only there if it returns true. Did you try 
>changing the code?
>
>Victor
>  
>
>>Hi John and all,
>>
>>Thanks for adding the listing of portmidi devices.  I'm
>>using (I  believe) the correct device number now (-M 1)
>>and things seem to be  opening correctly, but when running
>>, all I get is the following error:
>>
>>sensMIDI: retval errno 11
>>
>>I tried calling Pm_GetErrorText on the number but got an
>>invalid error  number.
>>
>>I added some code  to check if the Pm_OpenInput returned 
>>    
>>
>a
>  
>
>>non-zero  (commited the code to CVS), but there is no
>>error being reported, so the  stream seems to be opening
>>alright. 
>>
>>I'm not sure the following is correct in pmidi.c:
>>
>> if ((retval=Pm_Poll(midistream))) {
>>        if (retval<0) printf(Str(X_1185,"sensMIDI: retval
>>errno %d\n"),  errno);
>>        if (retval == 0) {
>>          long n = Pm_Read(midistream, bufp, MBUFSIZ);
>>          bufp = mbuf;
>>          endatp = mbuf + n;
>>          return n;
>>        }
>>        else {
>>          printf(Str(X_1185,"sensMIDI: retval errno %d\n")
>>,errno);
>>        }
>>      }
>>      return 0;
>>
>>it seems to me that it should check if retval == 1, as the
>>docs for  Pm_Poll say it returns TRUE, FALSE, or and error
>>number, and TRUE is set  to 1.  Am I incorrect?
>>
>>Thanks,
>>steven
>>
>>    
>>
>
>
>
>  
>

I have added more diagnostics to pmidi.c
I totally misread the results of Pm_Poll -- still seems counter intuitive.
==John ffitch

Hi John,

Thanks for the diagnostic info.  I'm still in the same boat that I'm not 
getting any sound from my CSD.  It does seem that the MIDI info is 
coming in though, as I'm moving four knobs around and the number of MIDI 
events read changes (fluctuates between 1 and 3 or 4 it seems, it went 
by quickly).  I'm turning in for the night, so will try again tomorrow!

steven


jpff@codemist.co.uk wrote:

>I have added more diagnostics to pmidi.c
>I totally misread the results of Pm_Poll -- still seems counter intuitive.
>==John ffitch
>
>
>
>  
>

John Ffitch, Steven Yi and all,

I think I've nailed the bug:

portmidi uses the structure PmEvent to pass the received MIDI events. The code
in pmidi.c expects midi messages to be an array of unsigned characters. So when
SensMidi tries to parse the message, it only reads the first byte, the 
status byte
and never starts a note on csound or sends a control message in, as it does not
retrieve the remaining bytes of the message.

solutions:

(a) change sensMidi(). This is possibly the more complicated solution, I 
tried it,
but it requires quite a lot of debugging. At the moment, it seems to sense the
notes in/out (plus some other garbage), but it doesn't seem to pass on the 
midi note
and/or velocities. I'm not very sure of the gotos in this function (in fact 
I had to get
rid of them), so something else might have got messed up in the process.

(b) change GetMidi(): I suppose this is simpler. What needs to be done is 
change
the global pointers )mbuf etc) to u_char from PmEvent (as in 
midirecv/middevice.c), and add
a little code to copy the PmEvent message into three bytes of mbuf at a time.

I think I'll give up on the (a) for the moment and try (b) later on today 
after some
teaching duties (synthesis!). Unless someone's already done it (please let 
me know!)

Victor

At 07:37 06/12/2004, you wrote:
>Hi John,
>
>Thanks for the diagnostic info.  I'm still in the same boat that I'm not 
>getting any sound from my CSD.  It does seem that the MIDI info is coming 
>in though, as I'm moving four knobs around and the number of MIDI events 
>read changes (fluctuates between 1 and 3 or 4 it seems, it went by 
>quickly).  I'm turning in for the night, so will try again tomorrow!
>
>steven
>
>
>jpff@codemist.co.uk wrote:
>
>>I have added more diagnostics to pmidi.c
>>I totally misread the results of Pm_Poll -- still seems counter intuitive.
>>==John ffitch
>>
>>
>>
>>

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Dear all,

The problem now seems to be fixed.  Took less time than previously
thought.

Runs OK here on Windows under MSVC. I'll try Linux (redhat) later.

These were the changes in pmidi.c (I can't do CVS, so I'll ask someone
else to do them for me):

(1) line 38:

#ifdef MSVC  /* VL MSVC fix */
#      define  u_char  unsigned char
#      define  u_short unsigned short
#      define  u_int   unsigned int
#      define  u_long  unsigned long
#endif

u_char *mbuf, *bufp, *bufend, *endatp;  /* VL dec 2004 changed back u_char 
pointers */
static u_char *sexbuf, *sexp, *sexend;

(2) GetMidiData function:

long GetMIDIData(void)
{
     int n,i,j;
     extern int  csoundIsExternalMidiEnabled(void*);
     extern long csoundExternalMidiRead(void*, u_char *, int);
     PmEvent event[MBUFSIZ];

     /*
      * Reads from user-defined MIDI input.
      */
     if (csoundIsExternalMidiEnabled(&cenviron)) {
       n = csoundExternalMidiRead(&cenviron, mbuf, MBUFSIZ);
       if (n == 0) return 0;
       bufp = mbuf;
       endatp = mbuf + n;
       return n;
     }
     else {
       int retval = Pm_Poll(midistream);
       if (retval<0) {
         printf(Str(X_1185,"sensMIDI: retval errno %d\n"),errno);
       }
       else if (retval) {           /* Pm_Poll return TRUE, FALSE of error!! */
         long n = Pm_Read(midistream, event, MBUFSIZ);
         if (n<0) {
           printf("**** read error %d\n", n);
           return 0;
         }
         printf("**** %ld events read\n", n);
                 /* copies a PmEvent into the midi buffer VL dec 2004 */
         for(i=0,j=0; i < n; i++){
          mbuf[j++] = Pm_MessageStatus(event[i].message);
          mbuf[j++] = Pm_MessageData1(event[i].message);
          mbuf[j++] = Pm_MessageData2(event[i].message);
                 }
         bufp = mbuf;
         endatp = mbuf + j;
         return n;
       }
     }
     return 0;
}

(c) MidiOpen()


void MidiOpen(void)   /* open a Midi event stream for reading, alloc bufs */
{                     /*     callable once from main.c                    */
     /* First set up buffers. */
     int i;
     Midevtblk = (MEVENT *) mcalloc((long)sizeof(MEVENT));
     mbuf = (u_char *) mcalloc((long)MBUFSIZ); /* mbuf is u_char array VL 
dec 2004 */
     bufend = mbuf + MBUFSIZ;
     bufp = endatp = mbuf;
     sexbuf = (u_char *) mcalloc((long)MBUFSIZ); /* sexbuf is u_char array 
VL dec 2004 */
     sexend = sexbuf + MBUFSIZ;
     sexp = NULL;
     for (i=0; i= endatp) {
       if (!GetMIDIData())
         return (0);
     }

     if ((c = *bufp++) & 0x80) { /* STATUS byte:      */
       type = c & 0xF0;
       if (type == SYSTEM_TYPE) {
         short lo3 = (c & 0x07);
         if (c & 0x08)                    /* sys_realtime:     */
           switch (lo3) {                 /*   dispatch now    */
           case 0: m_clktim++;
             goto nxtchr;
           case 2: m_start();
             goto nxtchr;
           case 3: m_contin();
             goto nxtchr;
           case 4: m_stop();
             goto nxtchr;
           case 6: m_sensing = 1;
             goto nxtchr;
           case 7: m_sysReset();
             goto nxtchr;
           default: printf(Str(X_1316,"undefined sys-realtime msg %x\n"),c);
             goto nxtchr;
           }
         else {                           /* sys_non-realtime status:   */
           if (sexp != NULL) {            /* implies           */
             m_sysex(sexbuf,sexp);        /*   sys_exclus end  */
             sexp = NULL;
           }
           switch (lo3) {                 /* dispatch on lo3:  */
           case 7: goto nxtchr;           /* EOX: already done */
           case 0: sexp = sexbuf;         /* sys_ex begin:     */
             goto nxtchr;                 /*   goto copy data  */
           case 1:                        /* sys_common:       */
           case 3: datreq = 1;            /*   need some data  */
             break;
           case 2: datreq = 2;            /*   (so build evt)  */
             break;
           case 6: m_tuneReq();           /*   this do immed   */
             goto nxtchr;
           default: printf(Str(X_1317,"undefined sys_common msg %x\n"), c);
             datreq = 32767; /* waste any data following */
             datcnt = 0;
             goto nxtchr;
           }
         }
         mep->type = type;               /* begin sys_com event  */
         mep->chan = lo3;                /* holding code in chan */
         datcnt = 0;
         goto nxtchr;
       }
       else {                            /* other status types:  */
         short chan;
         if (sexp != NULL) {             /* also implies      */
           m_sysex(sexbuf,sexp);         /*   sys_exclus end  */
           sexp = NULL;
         }
         chan = c & 0xF;
         if (M_CHNBP[chan] == NULL)      /* chk chnl exists   */
           m_chn_init(mep, chan);
         mep->type = type;               /* & begin new event */
         mep->chan = chan;
         datreq = datbyts[(type>>4) & 0x7];
         datcnt = 0;
         goto nxtchr;
       }
     }
     if (sexp != NULL) {                 /* NON-STATUS byte:      */
       if (sexp < sexend) {              /* if sys_excl           */
         *sexp  = c;              /*    special data sav   */
         sexp++;
       }
       else printf(Str(X_1262,"system exclusive buffer overflow\n"));
       goto nxtchr;
     }
     if (datcnt == 0)
       mep->dat1 = c;                    /* else normal data      */
     else mep->dat2 = c;
     if (++datcnt < datreq)              /* if msg incomplete     */
       goto nxtchr;                      /*   get next char       */
     /*
      *  Enter the input event into a buffer used by 'midiin'.
      *  This is a horrible hack that emulates what DirectCsound does,
      *  in an attempt to make 'midiin' work.  It might be usable
      *  by other OSes than BeOS, but it should be cleaned up first.
      *
      *                  jjk 09262000
      */
     /* IV - Nov 30 2002: should work on other systems too */
     if (mep->type != SYSTEM_TYPE) {
       unsigned char *pMessage = &(MIDIINbuffer2[MIDIINbufIndex++].bData[0]);
       MIDIINbufIndex &= MIDIINBUFMSK;
       *pMessage++ = mep->type | mep->chan;
       *pMessage++ = (unsigned char)mep->dat1;
       *pMessage = (datreq < 2 ? (unsigned char) 0 : mep->dat2);
     }
     datcnt = 0;                         /* else allow a repeat   */
     /* NB:  this allows repeat in syscom 1,2,3 too */
     if (mep->type > NOTEON_TYPE) {      /* if control or syscom  */
       m_chanmsg(mep);                   /*   handle from here    */
       goto nxtchr;                      /*   & go look for more  */
     }
     return(2);                          /* else it's note_on/off */
}
void MidiClose(void)
{
     if (csoundIsExternalMidiEnabled(&cenviron)) {
       csoundExternalMidiDeviceClose(&cenviron);
     }
     else {
       Pm_Close(midistream);
     }
}



Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Another thing: I used fmidi.c to provide midifile support, because if you
use pmidi.c you can't use midirecv.c and the midifile functions are there.
This seemed the right thing to me (I am guessing, since I'm not using
scons I can't just sat usePortMidi=1), is that right?

Now if that's right, there are three functions that are defined in both
files and they conflict when linked (in MSVC). So I made them static:

static void midNotesOff()
static void m_chanmsg(MEVENT *mep)
static void m_chn_init(MEVENT *mep, short chan)

But the code seems to be the same (is it?). Shouldn't we have only one
copy of these functions somewhere in the code?

Victor



Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Your code is out of date.  I fixed that last week, and yes tyou have 
pmidi+fmidi or midirecv
==John ff

Oh. I got the new one of the CVS via the browser.

Could you add this at the top (before any u_char?) to fmidi.c?
I don't want to keep having to do it every time I get a new one.

#ifdef MSVC  /* VL MSVC fix */
#      define  u_char  unsigned char
#      define  u_short unsigned short
#      define  u_int   unsigned int
#      define  u_long  unsigned long
#endif


Thanks.


At 14:03 06/12/2004, you wrote:
>Your code is out of date.  I fixed that last week, and yes tyou have
>pmidi+fmidi or midirecv
>==John ff

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

...but that seems backwards!  PortMIDI carefully constructs structures
for events, and it is these events that should pass about.  fmidi
should create them as well.  Otherwise much of the advantage of using
a library just goes.  I thought I had migrated the Pm_ structures into
musmon.c and friends.  Did I lose that or is my mind playing up again?
==John ffitch

I partly agree with you that it's backwards; if you want to use PmEvents
then sensMidi has to be rewritten completely, and the consequences
have to propagate to other parts of the code. So we can substitute
MEVENT for it. However, if we are to keep MEVENT, then I don't see
any problems in keeping the code as it is, since we are only using
PmEvent 'internally' in pmidi.c to pass things from GetMidi... to
sensMidi.

The existing code mixes the old and new ways together and that's why
it wasn't working. At first, I thought the migration to PmEvents had been
done, because you were using Pm_MessageStatus to get the status
byte in sensMidi, but then I saw that as the code looped round to
get the next byte, it actually fetched the next PmEvent, which is why
it wasn't working.

Victor

At 16:23 06/12/2004, you wrote:
>...but that seems backwards!  PortMIDI carefully constructs structures
>for events, and it is these events that should pass about.  fmidi
>should create them as well.  Otherwise much of the advantage of using
>a library just goes.  I thought I had migrated the Pm_ structures into
>musmon.c and friends.  Did I lose that or is my mind playing up again?
>==John ffitch

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Dear all,

I have tested csound5 in my Linux (red-hat 9.) with alsa drivers and the
'proprietary midi' does not work.

I built portmidi and then csound5 with my changes to pmidi.c and it works!
However, the latency is ridiculous. I suspect it can be changed with some
edits to the portaudio-device-output source code. I think now it's the time
to reconsider -b and -B as a way of defining/suggesting latency to portaudio.

That'll mean that they will have to be different to ksmps. I don't know where
are all the code bits that need to be changed, so I'd suggest some more
knowlegeable to do it. I can try, but I'll have first to learn what needs 
to be done,
so it'll take me a longer while.

But at least MIDI input works, which is a gain from not working. I suppose 
it previously
worked OK with OSS, but I think alsa support is very important. In 
addition, making sure
that csound works *completely* (MIDI, audio, FLTK)
on the planet-ccrma setup is also good, because a lot of people
use that set-up straight out of the box. That'll help csound with the more 
novice users
in Linux.

Victor



Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Is it possible to make a nightly/weekly tarball of csound 5 available
somewhere?

Victor


Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

Hi Victor,

I don't believe there is.  There's no SCons target for it currently to 
create a src tarball, and doing an automated CVS grab and zip would be 
unfruitful due to all the binaries that are in the CVS (I guess a script 
could be written to do that, but it'd be just as easy or hard to create 
the scons target to do it).

steven


Victor Lazzarini wrote:

> Is it possible to make a nightly/weekly tarball of csound 5 available
> somewhere?
>
> Victor
>
>
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
>
>

Creating scons code to produce a src tarball would be reasonably
trivial.  The question seems to me more what should be in it.  All
Loris?  All csoundVST? OSC? Portaudio? where does one stop?
==John ffitch

Perhaps it should include all 'original' csound code, everything you
need to build csound bar the external libs (portaudio, libsndfile, portmidi),
more or less what Michael Gogins packages in his distribution (and
there is already a target for zipping isn't there?), except binaries.

Victor

At 11:30 08/12/2004, you wrote:
>Creating scons code to produce a src tarball would be reasonably
>trivial.  The question seems to me more what should be in it.  All
>Loris?  All csoundVST? OSC? Portaudio? where does one stop?
>==John ffitch

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

OK; unless someone gets there first I will do tonight
==John ffitch
>>>>> "Victor" == Victor Lazzarini  writes:

 Victor> Perhaps it should include all 'original' csound code, everything you
 Victor> need to build csound bar the external libs (portaudio, libsndfile, portmidi),
 Victor> more or less what Michael Gogins packages in his distribution (and
 Victor> there is already a target for zipping isn't there?), except binaries.

 Victor> Victor

Great! Where will you make it available?
Thanks a lot, that'll save me a lot of grief.

Victor

At 16:23 08/12/2004, you wrote:
>OK; unless someone gets there first I will do tonight
>==John ffitch
> >>>>> "Victor" == Victor Lazzarini  writes:
>
>  Victor> Perhaps it should include all 'original' csound code, everything you
>  Victor> need to build csound bar the external libs (portaudio, 
> libsndfile, portmidi),
>  Victor> more or less what Michael Gogins packages in his distribution (and
>  Victor> there is already a target for zipping isn't there?), except 
> binaries.
>
>  Victor> Victor

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth