[openbeos-midi] Re: activity/status?
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos-midi@xxxxxxxxxxxxx
- Date: Mon, 08 Apr 2002 20:49:46 -0400
>> My understanding of this topic comes from reading the MIDI file spec
>(well, skimming it)
>> and looking at the MIDI (1) kit. The API looked very sensible and easy to
>use.
>> I don't understand why you (and others) don't like it. Again, though, I
>have no real
>> knowledge of MIDI, though, to make a judgement.
>
>The MIDI Kit is easy to use, but not very flexible. It does not allow for
>IPC. It also
>get unnecesarilly difficult to use when needing to output to more than one
>port.
I can understand this. It seems like MIDI2 fixes that, but loses the easy to
use.
>> It seems like it is just a message passer and replicator (sprayer).
>> IOW, if I want to write an app that, say, plays MIDI songs, I have to
>parse the midi file myself,
>> create a BMidiProducer, and feed it events.
>Correct.
I (personally) think that this is sub-optimal. It seems like MIDI + MIDI2 is
the right thing
to do. Designed such that people can use MIDI1 or the harder but more powerful
MIDI2.
>Well, I did not mean to say that every programmer has to parse the standard
>MIDI files
>himself, just that we should focus on getting the MIDI kit core
I wasn't thinking of you, as much as Be's choices in this.
>functionality, i.e. input/output
>of MIDI to interfaces/applications, working. I guess adding MIDI file
>parsing/playback
>wouldn't be that difficult and would indeed make life easier for game
>developers.
Cool. I wanted to ask you a couple of things about a software synth, since we
are talking about it -
1) Do real musicians want/need one?
2) Are there any out there that are ok and reasonably well licensed?
3) Are they as hard to write as I think that they would be?
>> And this is what I don't quite get. I looked at the MIDI spec. I couldn't
>read it in a couple of
>> hours, much less understand and code it. When you say a "working IO API",
>are you talking
>> about the Storage Kit?
>
>Simple input and output to either hardware MIDI interfaces or other
>applications.
So, say, keyboard in to kbd out?
>> Can you talk a little bit about 2 things - why Midi (1) is not good enough
>for professionals and
>> what Midi 2 does that is good?
>
>The original MIDI Kit does not support IPC MIDI input/output.
>With more complex applications I don't like having to use a BMidiPort with a
>seperate thread
>for every output. The MIDI 2 Kit has its problems too, though. If
>compatibility with BeOS is
>to be preserved we'll have to implement the MIDI 2 Kit. It's easy I think to
>build an old MIDI
>Kit compatible layer on top of that. What could prove difficult is to have a
>MIDI 2 Kit
>compatible API that doesn't suffer all the problems the Be's MIDI 2 Kit
>does.
IPC == interprocess communication?
Is a seperate thread for every output a problem for performance reasons?
>What would be good now I think is for the members of the MIDI Kit team to
>suggest ideas
>of how to implement the Kit. I have suggestions also, but I don't want to
>influence you already.
>It would be a good thing IMHO to see if we can come up with an elegant
>solution.
OK
>And we'll need drivers, (without a standard ioctl set, just a device
>dependant way to
>communicate with it) so that can be started on. Especially MPU401 UART
>support
>is important since so many soundcards have these.
I will take your word for this. That sounds more like a kernel thing, though.
>I have been working this weekend on a plugin interface that implements a
>standard interface for communicating with the low level MIDI driver:
Looks interesting. Would that be a kernel module or userland?
>midi application -> midi kit -> device plugin -> device driver.
>
>the plugin is a set of "C" functions and a C++ class. I have not yet
>finished it and I'm
>doing this for POSIX, but the plugin interface is cross platform (the
>implementation
>itself is not, it needs threads and timers, but it is also device dependant,
>so that is
>not a problem.).
Cool
>I think it would be best to start programming from the bottom up, i.e.
>starting with
>the drivers, plugin....
Maybe.
Other related posts:
