Hi Martijn, Igor, et al
It looks like Martijn has a wider base of experience than I do, that’s for
sure. My user experience is limited to Deluxe Music I & II, and Dr. T’s Tiger
Cub. For programming, I only looked at Alsa 0.5 and 0.9, but not too closely
yet, and there seem to be big differences between those two. Martijn, are the
beos and sgi midi docs available over the net for us to read? I think the MacOS
stuff is available, if we can just find the right place to look…
My own preference for an Alsa api stems purely from the availability of open
source code to port to RTOS. Of course a dependency on a particular windowing
library, or even X11 itself, might mean those Linux derived projects are not
good choices anyway. Still, the core algorithms should be usable.
Since I am between projects at the moment (aside from my accountant wanting
my books asap), I volunteer to produce a comparison of those api’s I can find by
the end of September. I’ll start with Alsa 0.5 and 0.9, and add in any others I
can find (Amiga?), or which get sent to me.
Just for history’s sake, I point out that the very first_real thread in this
group was about midi, although it had not much of use.
More useful was Igor’s conversation with Audio Support back in August, so with
apologies for not asking either of them, I will paste the relevant parts here:
IK:>> > 5. What are plans wrt midi/timer/sequencer stuff? I believe the whole
point of ALSA was to provide that (and better mixer) functionality
since it was missed in OSS. Also why /proc/asound is not supported?
AS:
Long term plans are to examine midi, but no timetable has
been set yet.
IK:> It would not be too hard to let io-audio to create all standard ALSA
devices in /dev/snd and leave implementation to driver writers. As of
now I simply can not support midi even if I wanted to. Unless I turn my
driver into resmgr, or course…
AS:> Igor, we are not ALSA. That is very important to remember. We didn’t
express
that strongly enough in our first few cuts of the audio DDK and SDK. Our
similarities to ALSA seem to have become an impediment to understanding. We
completely reworked the internals to automate/commonize as much of the
driver writing experience as possible. You are 100% correct. You cannot
support MIDI at this time unless you do it all yourself.
IK:Yes, DDK part is not ALSA, but SDK has ALSA-compatible interface, more
or less. You are free to implement internals in whatever way you like,
but client interface must be as compatible with ALSA as possible,
otherwise it will all be an excercise in futility. That means if ALSA
client interface includes MIDI/sequencer/timers then your DDK in one way
or another should provide at least theoretical capability to support
those.
IK:I did not ask you to follow ALSA drivers implementation. What I suggest
is to make the DDK flexible enough to allow driver writers to add
functionality missing in the framework. Is that too much to ask? ALSA
does not provide all possible devices for all possible cards either, but
they do have concept of ‘hardware dependent device’ so particular
drivers may choose to create and handle specific devices. If you had
something similar, it would allow to treat MIDI as ‘hardware dependent
device’ for now, until you make up your mind about supporting it.
Thanks,
- Igor
End of August thread------------
someone asked “Where are the archives?” - they’re filling up my hard drive 
I agree with Igor about the desirability of having applications to test
against, and I’m also willing to believe Martijn and Audio Support that maybe
the Alsa api isn’t the best way to go. Even if we end up with the Alsa api,
there’s still the problem of the gtk or Qt libraries before we can have Brahms
or Rosegarden on QNX6.x (x >= 1?); that’s why I don’t mind trying to get the api
right - or at least different.
Phil Olynyk
martijn sipkema wrote:
i am not familiar with the midi part of alsa, but this is iirc a low level
driver
for midi io. alsa is not a framework for ipc midi. also it does not support
timestamping i think. i am looking at beos midi2 and sgi irix midi and
possibly
macos x coreaudio midi for ideas.
–martijn
Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote in message
news:> 3BA78446.18F7FFD6@motorola.com> …
I would start with MIDI part of ALSA API, as I already suggested once.
It is better than to start with nothing, it would be more or less
consistent with rest of sound API and there would be applications
available to test the API against.
I don’t have experience with MIDI, unfortunately or I’d have done it
already when ported ESS drivers.
martijn sipkema wrote:
who would be interested in designing a midi api for qnx? it is not easy
to get right, but it’s not impossible either. i have some experience in
midi
programming and i have also written a driver for the beos midi2 kit
once.
designing the api in a team will probably make it a better one than i
could
think up myself.
–martijn
Chris McKillop <> cdm@qnx.com> > wrote in message
news:9o6sq3$rb7$> 2@nntp.qnx.com> …
Make one up and post it here. The reality is that audio drivers can
easily
create their own midi interface by starting a thread to do MIDI
services
and
talk to the driver. If you come up with something I am sure that the
people within QNX would be happy to comment (I know I would). Igor
and
I have actually talked about this before - coming up with a driver
library
to add in midi functionality and designing an application API.
chris
Phil Olynyk <> pholynyk@home.com> > wrote:
My two cents:
Since low latency is all that the Linux midi people complain
about
and ended up writing a kernel patch for low latency, it seem to me
that
the inherent low latency of Neutrino makes it a natural for midi
work.
If QSSL can’t/won’t do it all, how about adding hooks and an API so
that
others can add the required common code and chip specific code? As I
recall, Igor expressed interest in midi, and I’m certainly
interested,
so there’s three. I’ve not yet studied any sequencer code, so I’m
not
sure of the requirements, but I would like to have a reasonably good
sequencer for Photon, especially on a qPaq, or even my laptop…
Phil Olynyk
Hardware Support Account wrote:
Hi Martijn,
At this time QSSL has no plans for implementing a MIDI
system for QNX 6.1. However if demand increases for it
then it may get reconsidered.
It would be nice to see midi though >
Erick.
martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
is there currently a midi subsytem for qnx? if not:
it would be nice to have a system where drivers and
different midi application can connect. somewhat like
the midi2 kit that came with beos 5, allthough this supports
merging, i.e. more than one ‘producer’ connecting to a
single ‘consumer’ and i don’t think that can be done
without problems. would others be interested in helping me
program this and discussing how it should be implemented?
it would be nice to have an os where midi was done right.
– martijn
\
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL