pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) (02/10/88)
Hi all, I'm cross-posting this to rec.music.synth, in the event there are Amigoids in that group who (*gasp* *urk* Perish the thought!) don't read sys.amiga. I've received several requests and questions regarding the PD MIDI library, so I've decided to post it to the net. Actually, I should have done that a long time ago. Anyway, this will be a first for me (posting software). How should I go about it? I thought I'd wrap the whole thing up in a .arc file, uuencode it and send it up to ... .binaries? The library itself is not very large, but the package includes documentation and source examples. This PD library was written by Bill Barton, who hangs out on PLink and BIX, but has no usenet access. He says the library is not a finished product, but I don't see much room for improvement. It's small and simple, and very flexible. It rests squarely on Exec, so it integrates nicely with everything else. Now, I'll try to answer a few questions: > do the library routines fix the problem with dropping data? As I understand it, MIDI data loss is due to limitations in serial.device (driver or hardware, I don't know), and occurs only during large data transfers (i.e. system exclusive). I don't think the library attempts to fix this problem, but then I've never experienced it. This should really be fixed with a midi.device (which Bill hopes to add in the near future, if he gets a chance to write one). > Do they do timestamping? No timestamping. Again, this should be a function of the device, not the library. In my own applications, I run a master-clock process which provides the timebase for all other MIDI processes, including sequencers, generators, and delay lines. I think this is more flexible than timestamping, as it provides a pulse for the whole system, rather than just tagging input events. There can be lots more to MIDI than just sequencers. > I was thinking of writing up a special serial.device that [...] > [would] allow multiple music programs to run simultaneously No need. When you open the MIDI library, it automatically starts a process whose sole function is to manage the serial.device. Virtually any number of processes can send to and receive from this server process. All outgoing MIDI messages are properly merged. All incoming messages are distributed to expecting processes. Automatically. See, this library is based on a simple network model: nodes and the routes that connect nodes. Any given MIDI process may have one or more destination ports, which receive messages from other processes. There may also be one or more source ports, to which the process writes in order to send to other processes. Then the application creates and configures routes which plug source ports into destination ports. From then on, the process need only read from/write to its own ports. All message routing is handled transparently. The library provides a set of simple tools for the creation, destruction and modification of ports and routes, and for message transmission. As an added plus, the routes provide some data filtering. So, I'll try to get this thing out Real Soon Now. I'm glad to see that folks are showing interest, because the modular nature of this PD system will (hopefully) encourage the creation and distribution of a plethora (love that word) of interchangeable MIDI process modules (as opposed to close-ended applications). Now get back to work! :-) Peter M. Yadlowsky Academic Computing Center University of Virginia pmy@vivaldi.acc.virginia.EDU