The main novelty is KMidPart, a component that implements the interface KMediaPlayer, playing MIDI/Karaoke files and using KMid infrastructure. The component shares the same configuration as the main program, so by default the MIDI port selection and Soft Synth will be common. This component by default shows only a play/stop combined button and a slider for the time position, in addition to the actions Play/Pause/Stop. Hidden, but selectable by means of KMediaPlayer::View interface methods, there are several additional controls: pause button, volume, pitch transpose and tempo (speed). The following pictures show the minimum and complete user interface respectively.
Once installed the new version of KMid, the KMidPart component is immediately available in Konqueror, either as file manager or web browser, since it is a simple standard KParts/ReadOnlyPart service. Examples of web sites that can benefit from this component can be anaigeon.free.fr and greekmidi.com.
Of course, this component is available to all fellow KDE developers so they can include MIDI playback in other programs. The programming API is quite simple, as demonstrated by two examples in C++ and Python included in the examples directory. If the KMediaPlayer interface is not enough, there are other methods and additional signals available through DBus.
From here, KMid will continue to evolve. I am considering further integration with KDE desktop technologies. For example, standard MIDI files are not scanned or indexed currently, but much of their metadata could be exploited with Nepomuk: tonality, rhythm, tempo, number of tracks and instruments. The settings of the songs, now stored in individual text files, may also be candidates for better integration. Another candidate for integration would be Solid, publishing system MIDI ports. Integrating KMid backends in Phonon can not be addressed at this time, but maybe in the future Phonon may evolve and such integration become possible.
Further integration into KDE unfortunately means less chance for KMid users of using it on Windows and Mac OSX. Although there are ports of KDE for those operating systems, both communities are not very active. I have received a suggestion that KMid does not need to depend on KDE, but only Qt4. This would make possible to distribute KMid binaries for Windows and Mac easily. I'm not especially interested in this option, followed for instance by the Rosegarden project, sacrificing both functionality and community by this way.
Hm, your comment that the KDE Windows and OS X communities aren't very active doesn't quite match my own experience as an app maintainer. Konversation gets packaged fairly swiftly for Windows and OS X (via Fink) when a new release occurs, and has a fair number of users on either platform. The KDE Windows devs have also contributed a number of Windows-specific fixes and improvements to Konversation.
ReplyDeletePorting KMid is probably much more challenging than porting Konversation, granted.
@Sho: thanks for your comment. KMid doesn't need to be ported to these platforms. I've already written native backends, and if you check this blog, there are some screenshots and video screencasts of KMid on Windows and Mac. What we need is packaging, and users reporting issues on these platforms.
ReplyDeleteI've already opened a package request in Fink, and in the winkde project. Looks like KMid is not interesting for them, as opposed to Konversation.
I find that nagging people on IRC often helps :-D
ReplyDeleteThat may explain why they are eager to support Konversation, if they spend a lot of time hanging out in IRC. My preference is communicating by mail, and using the mailing lists. I'm subscribed to kde-windows and kde-mac mailing lists, and the traffic is very low on both. Sometimes (rarely) I get an answer there, though.
ReplyDelete