Hi, I'm just getting started with portmidi, but already I have lots of questions and issues. Please excuse my ignorance!
So about the web page: searching for portmidi turns up http://www.cs.cmu.edu/~music/portmusic/. This page has some fluff, and then portaudio doc and src links, which don't point to docs and src, but to portaudio.org, which at least will eventually get you some. The portmidi src link however points to a sourceforge page with no releases and clear way to download anything. The page also has a mailing list link to archives, which is broken "The requested URL /mailman/listinfo/media_api was not found on this server.", and a reference to the mailing list address, with no instructions on how to subscribe. The only reason I managed to subscribe at all is thanks Stephen Travis Pope who sent me a link. On the mailman link he sent me, I did manage to find some archives, so I'll be looking at those in a bit. I still don't even know how to download the library. The sourceforge page is confusing as usual, but has three overlapping terms floating around: portmedia, portmusic, and portmidi. There are some generic instructions for a svn download... should I go find and install an svn client and download it that way? Is there an easier way? I'm going to try a mac osx portmidi "port" which looks like a completely separate implementation and is at version 1, and is unmaintained, but it's the only thing I figured out how to download. So in general, is that bit about "No other cross-platform APIs enjoy a support community." really serious? By all outward indications it's a dead project! Some questions about the interface: My app wants to write midi msgs as (Timestamp, Msg). From the header comments and also from the OS X source, it looks like portmidi sets the timestamp to 0 if latency is 0. This is hard for me to understand. I don't want any latency added to the msgs, I want them played when I said I wanted them played. If I wanted latency, I would have added it to the timestamp myself. But if I set a latency of 0, all timestamps are ignored entirely. What's the rationale here? How can I have it play my midi when I tell it to? I notice that portmidi only exposes a blocking read interface, not the underlying callback interface (at least underlying in CoreMIDI, alsa looks like a blocking interface). Is there any particular low-latency way to do midi thru, other than calling Pm_Write with a 0 timestamp as soon as I get something from Pm_Read? I haven't tried it yet so I don't know if it's acceptable in practice, but I thought the whole idea of having a high-prio callback thread is that you can get midi thru out the door quickly. While I appreciate the desire for simplicity, the fact that portmidi intersperses realtime msgs in a sysex to avoid buffering an unlimited amount of sysex data, just means that the first thing my app has to do is insert an unlimited buffering layer above portmidi to collect the complete sysex. And won't all apps be doing the same thing? Unless you are echoing sysex through unchanged, you need a complete sysex to do anything with it. What's so bad about portmidi having a big sysex buffer? Also, here's something from portmidi.h: For input, the buffersize specifies the number of input events to be buffered waiting to be read using Pm_Read(). For output, buffersize specifies the number of output events to be buffered waiting for output. (In some cases -- see below -- PortMidi does not buffer output at all and merely passes data to a lower-level API, in which case buffersize is ignored.) However, it never appears to explain those "some cases". I would, of course, prefer to use the CoreMIDI timing system where (apparently) you just give it timestamps. Speaking of which, I don't really understand the use of timestamps at all. The doc says: (NOTE: time is measured relative to the time source indicated by time_proc. Timestamps are absolute, not relative delays or offsets.) So it's saying time is relative... but it's absolute. Even if it's "absolute" it has to be relative to some kind of epoch, but it doesn't say what. A signed long counting nanoseconds can only count off about 24 days, by my calculation. My best guess is that "timestamps are not relative offsets" really means "timestamps *are* relative offsets to the last thing that time_proc returned", but that's about the opposite of what it says. Speaking of incomplete references, here's another one: (In some cases -- see below -- PortMidi does not buffer output at all and merely passes data to a lower-level API, in which case buffersize is ignored.) I wasn't able to find any cases below. At one point in the past, I did figure out how to download portmidi (I think it was the "mainline" version) and even wrote a binding to haskell so I could use it, but I remembered I had a problem with corrupted sysex msgs on os x. I remember tracking it down to some invalid assumption the os x code made about how CoreMIDI split up sysex msgs. Does this sound familiar? I'm going to try to get my binding working with the os x version and see if sysexes are corrupted in that version, but I'm curious if that was a known bug. So, in summary, all of this is making me wonder if it wouldn't be easier to just write to CoreMIDI, but I'm sure I'd eventually wind up writing an alsa layer too, and then I'd have essentially reimplemented portmidi, which would be sort of silly. Anyway, thanks for reading this far! _______________________________________________ media_api mailing list media_api@create.ucsb.edu http://lists.create.ucsb.edu/mailman/listinfo/media_api
