Oh and there is no need to remove ALL Pm_ calls, just the ones which change
portmidi state: enumerate,open,close,error conditions and such. Pm_Read etc
should be fine in the portmidicontroller.cpp, which just receives the device to
work on from the backend module.
And, there is a need for a signal from this backend to tell a
PortMidiController it's device is removed, I think. Not that portmidi supports
hot pluggging, but we might fix that in portmidi itself and then need this
signal.
*hile*
On 17 Mar 2012, at 07:26, Ilkka Tuohela wrote:
>
> Hi Sean,
>
> I had a long chat on the IRC about separating midi backend initialization in
> new controllers code, when you were away. Of course ask RJ about how he feels
> about it before coding of course and do this before merging the controller
> abstraction to main, I'm just spitting ideas
>
> The point is, I was thinking about extensions, which could be implemented,
> including creating an MIDI virtual port device to send MIDI events to anyone,
> not just controllers. We are not planning to do this right now, but I
> noticed issues with portmidi code which could be fixed now cleanly.
>
> Right now Pm_ calls are done in portmidicontroller.cpp and tied to the
> controller implementation, and since portmidi must be only initialized once
> per application, this is a problem for code which is not a controller.
>
> So, my suggestion is to do something like:
>
> - Create src/midibackends directory for any midi enumeration and backend
> initialization code
> - Create new midibackends/portmididevice.cpp module, which implements opening
> all Pm_ calls
> - Make sure portmidi enumerator is not calling any Pm_ calls directly and
> create appropriate modules to midibackends
> - Call the new portmididevice.cpp module from cleaned up
> portmidicontroller.cpp, removing any Pm_ functions from the controller side
> itself, implementing only the 'controller' part of it
>
> Goal would be simply to encapsulate MIDI device access cleanly to one place,
> which is not in the controller code.
>
> This would allow any other part than controllers to open the
> PortMidiEnumerator() and PortMidiDevice() instances as well, list midi
> devices, open midi ports etc cleanly. This also allows debugging portmidi
> without even thinking about controllers.
>
> I think now is the right time to implement this, when your controller
> abstraction changes the tree drastically anyway, it does not seem to require
> much new coding, just code separation and encapsulation for portmidi.
>
> *hile*
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
