UML, as promised: Old MIDI device I/O class diagram: http://i42.tinypic.com/34evza8.png
My proposed new MIDI restructuring, class diagram: http://i42.tinypic.com/20k9bi9.png (will look familiar to anyone who knows how the audio code works) Rationale: - We have 7 Midi backends right now. PortMidi will drastically reduce the amount of code we have. - What IS a MidiObject??? - Old MIDI code isn't object-oriented. Other thoughts: - I have no idea how MidiObject hooks into our ControlObject system. I think I can get away without actually understanding it though. - 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. We _do_ want each MIDI device's events to be processed asynchronously and independently, AND we want each device to be scriptable separately (ie. have its own MidiScriptingEngine object). - If anyone has any objective, concrete complaints about PortMidi, voice them now. I have a reasonable amount of experience with PortMidi on OS X and Linux, and the API is well thought out. I've never used output with it though, but it looks OK. We don't have the manpower to maintain separate Windows/Mac/Linux MIDI backends. P.S. The existing PortMidi backend we had was like 1/4 finished and totally non- functional. Thanks, Albert On 17-Dec-08, at 7:50 PM, Albert Santoni wrote: > Hi Sean, > > I answered some of these questions on IRC, continuing them here for > more discussion: > > On 17-Dec-08, at 2:06 PM, Sean M. Pappalardo wrote: > >> Hello. >> >> I have some questions about MidiObject as it relates to the rest of >> Mixxx. >> >> 1) Clarification: Does one and only one MidiObject get created for >> each >> MIDI device connected to the system? > > Yes, this is my understanding. I've poked at the code for a few hours > today though and I'd like to propose some refactoring, which I'll > explain later. I don't think it'll affect anything you're working > directly on. > >> >> 2) If so, shouldn't it be the container for things like QString >> deviceName and channel #? > > Yes. It isn't? > >> >> 3) Will dlgprefmidibindings be able to access these? >> >> (I ask because I need these two values to be able to call intelligent >> init() functions in scripts when the scripts get loaded, (currently >> in >> the MidiObject constructor) as well as a shutdown() function when the >> device is closed. That and it makes more sense to me to have these >> in an >> object instead of passing them all over the place.) >> > > This interaction needs to be sorted out. I'll try to post some UML to > the list when I'm done with this refactoring idea and critique it to > make sure it'll resolve this issue. > > Thanks, > 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 ------------------------------------------------------------------------------ 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
