14.7. The Future of MCOP

MCOP is new. This means that not every feature that should be available is available already. Here I'll try to outline the most important plans and show you where implementations are currently missing, so that you get an orientation of how the big picture will look when it is completed.

14.7.1. Composition/RAD

artsbuilder, which existed already for arts-0.3.4, needs to be ported to the KDE 2.0 aRts/MCOP technology still. It will allow building more complex objects out of simpler ones visually. For instance, if you have a delay module, you can easily built a reverb filter by using a few delay modules and adding them together (with some feedback). All this should be available in an easy-to-use visual builder (just like the arts-0.3.4 artsbuilder).

This needs some internal tweaking in MCOP so that you can implement complex modules in terms of easy modules transparently.

14.7.2. GUIs

As you have seen, writing plug-ins for the soundserver is easy. Using them in other software as wave editors, hard disk recorders, and sequencing software such as Brahms (which is a CuBase clone for KDE) should be no problem, as well. What is missing is the capability to make GUIs for those plug-ins easily. Maybe, if you are reading this, this is already fixed.

It would be nice to have the StereoBalanceControl object you wrote available in artscontrol, KWave, Brahms, and other software, with a nice control panel to configure the balance to be actually used.

With the modularity I mentioned previously, the GUI building should be as flexible. It should be possible for somebody without any programming skills to create a reverb effect out of some delays and give it a nice GUI. Maybe GUIs should also be toolkit independent, as a side effect of that.

14.7.3. Scripting

Programming signal flow in C++ is nice. But you may not always want to wait for your compiler to achieve a small task. If components could be scripted by JavaScript and/or KScript, another powerful tool would be added to the multimedia capabilities. You could do whole presentations with amazing video and audio combinations just as scripts. You could implement even more complex modules than with artsbuilder, without knowing C++ at all, or needing your compiler, or anything else.

14.7.4. More Media Types

Finally the most important point right now is that sound is what you can currently do reasonably with aRts/MCOP technology. The possibilities would be greatly enhanced if MIDI and video were modular, just like sound. Video codecs and effects, modular MIDI processing, and modular sound would give users and developers the ultimate unified multimedia API for solving complex problems easily.

It will happen; and if I know KDE development, it won't take too long.