Re: [jazzplusplus-devel] Opinion on PortMidi

[Dave F. <dav...@co...>]

I'm sold.  :)  (I was already an advocate of this anyway)

On Thursday 25 March 2004 05:30 am, Patrick Earl wrote:
> The more I think about it, the more I think it's a good idea to go
> with PortMidi.  Here's how it balances out in my head:
>
> Disadvantages:
> 1.  May be poor support or slow uptake of new APIs.

Without it, or something in its place, we'd have to code to the new APIs 
anyway.  So if we wind up having to code to new APIs, we can add the code to 
PortMIDI instead, since we'd already be coding to new APIs, and then anyone 
else using POrtMIDI gets the code too.  Share and share alike, right?  ;)  In 
the meantime, other people using PortMidi are in the same boat, and we'll 
wind up being able to support APIs we don't have enough time to support 
ourselves.  Reusing code is always good.  ;)

> 2.  May be issues with things like latency that are tricky to handle
> without writing more native code.

Same as #1.  :)

> 3.  Need to maintain an extra external dependency.

Audacity keeps a copy of PortAudio in their source tree, I don't see why we 
can't do the same with PortMIDI and then link it in statically.  In fact, I 
seem to recall that all the PortSound libraries are intended to be used that 
way.  In that fashion, we ensure the user always has the right version, for 
one thing, and we can patch our own copies to fix problems while waiting for 
PortMIDI to either accept our patches or write better fixes.

> 4.  Needing only one code base might lead to complacency and allow the
> midi code to sprawl all over the place.

Yeah, that's a problem that's already there to be fixed in the code.  ;)

> Advantages:
> 1.  Only need to wrote the midi interface code once.
> 2.  Don't need to figure out how to port nicely between Windows, Mac
> OS X, and ALSA.
> 3.  It seems to have support behind it, so I like to think that it
> will be updated.
>
> Addressing the disadvantages, #1 may not be an issue for us.  I mean,
> look at how long it's taking to get wxWin2.4 going!  If we want the
> code sooner, we could always write it for the portmidi team.
>
> As for #2, if there are problems we could either send patches that
> improve things or try writing some small midi code hunks that improve
> the situation.  Hopefully it won't be an issue, but even if it is, we
> can try tricks like SCHED_FIFO, which I suspect we might have to do
> anyways.
>
> #3... probably easier to maintain external dependency than to port
> code.
>
> #4... uh.. uhm... no laziness allowed? :)
>
> So, in summary, my personal opinion is that portmidi is probably the
> way to go.

If there's support here, I was figuring after I had jppProject working well 
enough and reliably enough that everyone could take a crack it I was going to 
take on this project, since the Playback stuff needs rewriting anyway.  (I'm 
really irked by a realtime application deriving from wxTimer for the realtime 
part of the application, sorry)  That could be awhile before I hit it, 
though.  I'd kinda like to redesign the Preferences dialog too, but I'm much 
more worried about the backend stuff right now.

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

Men often believe -- or pretend -- that the "Law" is something sacred, or
at least a science -- an unfounded assumption very convenient to governments.