David Ratajczak wrote:

> I have been trying to make use of the realtime MIDI input feature
> ("-M" I believe) but there seems to be a problem (I can give more
> specific information to anyone interested).  I have looked through the
> source and have some idea as to where the problem is, but I was hoping
> to first find out if anyone else out there has encountered this
> problem and found an easy (or at least feasible) way around it.

David's message is timely. I've been trying to fix whatever was broken
in 3.47 MIDI input, but I'm not having any good luck. midirecv.c was
changed considerably from 3.46 to 3.47, and unfortunately the changes
are undocumented.

However, the real problem may not lie with Csound at all. According to
Laszlo Vecsey, the Linux kernel sound driver blocks MIDI input when
-odevaudio is called. The offending code is found in the sound driver's
midibuf.c, and Laszlo has offered a quick fix. Unfortunately again, I
had a near-disastrous kernel recompile which left me with no sound
module and no fix for the MIDI input problem. Laszlo states that even
with the kernel fix MIDI input is not as robust as it was in 3.46. He
also states that the kernel fix is necessary, not optional.

So: David, please send me your notes regarding your MIDI input attempts.
Fellow Csounders, if you're using Linux please let me know whether & how
you have MIDI input working for you, in as much detail as you like. I
want to get Linux Csound working in every respect.

> I would also be interested to know what sort of applications and setup
> (hardware and software) other linux users out there are using.  I have
> been very impressed with csound's synthesizing capabilities but have
> yet to find a feasible way to compose music for it.  Is there a
> Cakewalk for linux out there?

I use Jazz++ for native Linux sequencing, though more typically I'll
fire up DOSemu and use Sequencer Plus there. For Csound work, I use a
combination of hand-written orc/sco files, files generated by C routines
I write myself, and various soundfile editors and signal processing
software.

Be on the lookout for Cecilia for Linux, you may find it's just what
you're looking for. Many other sound tools exist for Linux, you should
check out my Linux sound apps page (address below).

== Dave Phillips

       http://www.bright.net/~dlphilp/index.html
   http://www.bright.net/~dlphilp/linux_soundapps.html

I will try to describe the high-level behavior I've been noticing:

1) My keyboard works and is correctly stuffing information into
/dev/midi (i.e. I have verified that csound is able to see the correct
information from the MIDI port)

2) If I pipe raw midi data into a file ("cat /dev/midi > junk.mid")
and then run csound with the -F option ("csound -o devaudio -F
junk.mid foo.orc bar.sco") it works reasonably well - as well as can
be expected with no timing information.  (i.e.  The problem is either
a difference in the way csound handles the MIDI information when it is
coming from a file rather than from a stream, or perhaps due to
blocking errors when you open "/dev/midi")

3) If I use the MIDI streams but output to a file ("csound -W -M
/dev/midi foo.orc bar.sco"), it still doesn't work.  This, combined
with the fact that /dev/midi still yields the right data even when I'm
using -odevaudio, implies that the problem I'm seeing is not with the
sound driver, but rather csound's handling of the MIDI stream input.

4) The main call to read in data from the MIDI port in midirecv.c 

Line 990: if ((n = read(rtfd, (char *)mbuf, MBUFSIZ)) > 0) {

never returns a number <=0.  In other words, the MIDI port is not
opened with non-blocking correctly.  So at this point, when you should
be counting the amount of time that has elapsed by returning instantly
from this call (with return value -1 and errno=EAGAIN) instead it is
always yielding some input.  I believe the result is that the time is
never incremented and no sound is produced because csound eternally
thinks that it is reading events for time T=0.0

That's my current take on the situation.  Like I say, I am fairly sure
that this is a problem with csound, though I could be wrong.  I will
let you know if I find anything else.

As an aside... I've noticed that Jazz++ and Rosegarden don't play back
any sound in realtime (by this I mean I bang away on my MIDI keyboard
but no sound comes out unless I record a track and then play it back
afterward).  Should they?  Is this perhaps the problem you were
referring to?  It seems a little difficult to compose anything without
this feature.

> However, the real problem may not lie with Csound at all. According to
> Laszlo Vecsey, the Linux kernel sound driver blocks MIDI input when
> -odevaudio is called. The offending code is found in the sound driver's
> midibuf.c, and Laszlo has offered a quick fix. Unfortunately again, I
> had a near-disastrous kernel recompile which left me with no sound
> module and no fix for the MIDI input problem. Laszlo states that even
> with the kernel fix MIDI input is not as robust as it was in 3.46. He
> also states that the kernel fix is necessary, not optional.
> 
> So: David, please send me your notes regarding your MIDI input attempts.
> Fellow Csounders, if you're using Linux please let me know whether & how
> you have MIDI input working for you, in as much detail as you like. I
> want to get Linux Csound working in every respect.
> 

Me too :)

__________________________________________________________________________
David Ratajczak 
Web:    http://web.mit.edu/dratajcz/
E-mail: dratajcz@mit.edu

> Well, no sound is produced because csound is blocked!
> 

Yes, you are right.  I just found the following from some on-line
documentation for the OSS sound driver.

"Reading from the device waits until there are at least one byte in the
receive buffer. When the first byte is received, the driver will not
wait for additional characters."

So this is the problem, and this would explain precisely the behavior
I've been seeing.

However, there is some hope since /dev/midi apparantly is accessible
via select calls.  I will see if this works and inform you of the
result.

Thanks.

> Did you check whether csound is using O_NODELAY (or O_NONBLOCK ) when
> opening the MIDI input? Assuming this much is correct,  than you probably
> just need to update your OSS. At one point there was a bug in OSS where
> the O_NONBLOCK did not work.
> 
> Even after this bug was fixed, there was a problem where the O_NONDELAY
> still waited for a minimum, till the next kernel tick, which since on
> intel is only 100Hz, made the OSS Midi driver unusable for real-time
> stuff. However, this bug as well was supposedly very recently (last month)
> fixed.
> 
> Let me know if this is what the problem is.
> 
> Larry
> 
> 
> --  Larry Troxler  --  lt@westnet.com  --  Patterson, NY USA  --
>   
> 

__________________________________________________________________________
David Ratajczak 
Web:    http://web.mit.edu/dratajcz/
E-mail: dratajcz@mit.edu

On Wed, 4 Feb 1998, David Ratajczak wrote:
> blocking errors when you open "/dev/midi")
> 
> 3) If I use the MIDI streams but output to a file ("csound -W -M
> /dev/midi foo.orc bar.sco"), it still doesn't work.  This, combined
> with the fact that /dev/midi still yields the right data even when I'm
> using -odevaudio, implies that the problem I'm seeing is not with the
> sound driver, but rather csound's handling of the MIDI stream input.
> 
> 4) The main call to read in data from the MIDI port in midirecv.c 
> 
> Line 990: if ((n = read(rtfd, (char *)mbuf, MBUFSIZ)) > 0) {
> 
> never returns a number <=0.  In other words, the MIDI port is not
> opened with non-blocking correctly.  So at this point, when you should
> be counting the amount of time that has elapsed by returning instantly
> from this call (with return value -1 and errno=EAGAIN) instead it is
> always yielding some input.  I believe the result is that the time is
> never incremented and no sound is produced because csound eternally
> thinks that it is reading events for time T=0.0

Well, no sound is produced because csound is blocked!

Did you check whether csound is using O_NODELAY (or O_NONBLOCK ) when
opening the MIDI input? Assuming this much is correct,  than you probably
just need to update your OSS. At one point there was a bug in OSS where
the O_NONBLOCK did not work.

Even after this bug was fixed, there was a problem where the O_NONDELAY
still waited for a minimum, till the next kernel tick, which since on
intel is only 100Hz, made the OSS Midi driver unusable for real-time
stuff. However, this bug as well was supposedly very recently (last month)
fixed.

Let me know if this is what the problem is.

Larry


--  Larry Troxler  --  lt@westnet.com  --  Patterson, NY USA  --
  

On Wed, 4 Feb 1998, David Ratajczak wrote:

> 
> > Well, no sound is produced because csound is blocked!
> > 
> 
> Yes, you are right.  I just found the following from some on-line
> documentation for the OSS sound driver.
> 
> "Reading from the device waits until there are at least one byte in the
> receive buffer. When the first byte is received, the driver will not
> wait for additional characters."
> 

The documentation is probably out of date then, since non-blocking mode
does now work, and read() does sometimes return 0 (or E_AGAIN, I forgot
wchich).


> So this is the problem, and this would explain precisely the behavior
> I've been seeing.
> 
> However, there is some hope since /dev/midi apparantly is accessible
> via select calls.  I will see if this works and inform you of the
> result.
> 
But if you just update your OSS, you won't need to use select(), and may
not have to touch the code at all.

Larry

--  Larry Troxler  --  lt@westnet.com  --  Patterson, NY USA  --