On 18-Dec-08, at 7:52 AM, Sean M. Pappalardo wrote: > Hi. > > Albert Santoni wrote: >> My proposed new MIDI restructuring, class diagram: >> http://i42.tinypic.com/20k9bi9.png > > Looks good to me. Calling it MidiDevice & MidiDeviceManager makes > everything much clearer. > >> - What IS a MidiObject??? > > My guess is "the object that handles everything MIDI." Something else > not designed to scale. > >> - I feel like MidiObject shouldn't do the MIDI processing- >> >ControlObject >> interactions itself, but I can't think of a better OO way to do it >> because of scripting. > > It seems multiple (unrelated) objects & functions can be exposed to > scripts, so why would scripting prevent doing it the Right Way(tm), > especially since nearly all scripts would be tied to separate > MidiDevices anyway?
I think I understand what my gut feeling was saying now. The temptation is to divide the MIDI code up into upper and lower halves like a device driver. In this case, the lower half would be MidiDevice (which just does I/O) and the upper half would be some other class that does the high level logic (mapping events onto ControlObjects, hooking stuff into scripts, etc). Maybe we'd call it MidiProcessor or something. The part I was confused about was would be where this hypothetical MidiProcessor would get created at runtime, and how many we'd have. I think you're right - we'd definitely need to have one MidiProcessor per device, and perhaps MidiDeviceManager would create them and make the necessary "connection" between each and it's corresponding MidiDevice. Does this make any sense? As far as I can see it, the advantage of doing this is that it moves code that's not strictly related to "midi devices" (ie. event processing) out of MidiDevice, and it gives us flexibility to swap out both the device I/O layer (bottom half) or the event processing layer (top half). As an example, if someone ever wanted to build a MIDI sequencer into Mixxx, they would just generate MIDI data and pass it along to our existing MidiProcessor. > > >> and Linux, and the API is well thought out. I've never used output >> with >> it though, but it looks OK. > > As long as we can send arbitrary length messages to MIDI devices, I'm > happy. (Arbitrary length SysEx messages anyway; note and CC message > length are fixed by the MIDI spec.) > The docs for PortMidi are here: (it's all commented in portmidi.h) http://portmedia.svn.sourceforge.net/viewvc/portmedia/portmidi/trunk/pm_common/portmidi.h?view=markup As far as I can tell, both Pm_Write() and Pm_WriteSysEx() will allow you to write arbitrary length sysex messages. One thing to notice is that Pm_WriteSysEx() doesn't take a length parameter. I peeked at the MIDI specs, and it looks like sysex messages must be terminated with a 7F byte, so I think that's why. > Just let me know with what sub-tasks you'd like help (and you think I > could handle) when you're ready. > I'm going to leave stubs for the MIDI output functions, so it would be helpful if you could fill these in once I commit something to trunk. :) Thanks a ton! Albert ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
