hey paul and evan- thanks for getting back to me. the new .cabal builds nice. if you're going to include portmidi in it, we should find a way to offer dynamic linking to an existing install, cuz someone like me uses portmidi for other things and wants to maintain it separately.
i'm surprised you guys have moved away from portmidi -- i have been a happy user of it (via the python bindings in pyPortMidi) with no problems (well, i still get that bus error if i let it sit for awhile). i only use it for output, though, and nothing complex like sysex, and only on osx. roger seems to keep up with the list (i thought traffic was so low cuz there's not much that needs fixing). paul, did you send the win32 bug to the list or roger? that would be helpful. RtMidi looks interesting, i am definitely committed to cross-platform dev, so i don't want to go the Core.Midi route. since we already have (two!) working haskell bindings and python bindings for portmidi (i think 4 different ones have been mentioned?), i'm happy with it. evan - i saw in paul's example a use of a priority queue (Data.Heap) from hackage (http://hackage.haskell.org/package/heap) to handle scheduling. i am also using it, and it's great. it has a merge function (http://hackage.haskell.org/packages/archive/heap/1.0.0/doc/html/Data-Heap.html#v%3Aunion) that would do what you want for merging streams. i have argued that portmidi should offer a default buffer and allow events to be sent nonmonotonically, but any time you have a priority queue handy you can easily whip one up for yourself -- here's one i wrote for pyPortMidi using the new threadsafe PriorityQueue introduced in python 2.6: http://code.google.com/p/h1ccup/source/browse/trunk/theory/python/midiBuffer.py one thing that winds up being tricky if you send notes out of order is preventing the ends of notes from prematurely cutting off an overlapping note. i didn't try to address that in the python version, but my haskell version (below) handles it. > I looked at your code, and I think your program > will exit before producing any sound. yeah, i wasn't that far yet. i'm familiar with getting midi out of portmidi. :) i was still dealing with the Eithers and Maybes, like i said. i finally learned enough haskell to solve it nicely (i don't count manually casing out Either as a solution). the following lets you specify two functions, one for a good stream and one for a broken one. import qualified Data.Traversable as T import Control.Arrow useStream :: (PMStream -> IO a) -> (b -> IO a) -> Maybe (Either PMStream b) -> IO (Maybe a) useStream = T.sequenceA `dot` fmap `dot` (|||) -- from http://www.haskell.org/haskellwiki/Pointfree#Dot dot :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c dot = (.) . (.) now i can just work with a stream obtained with the following, and not special case all the failure modes (no default, stream error, etc). T.mapM (flip openOutput latencyMS) =<< getDefaultOutputDeviceID here's a demo of it in action: http://code.google.com/p/h1ccup/source/browse/trunk/theory/haskell/src/PMTest.hs -e _______________________________________________ media_api mailing list media_api@create.ucsb.edu http://lists.create.ucsb.edu/mailman/listinfo/media_api
