On Sat, Jun 5, 2010 at 1:19 PM, Niels Mayer <nielsmayer@xxxxxxxxx> wrote: > What I don't understand is why there isn't more overt collaboration > and code-sharing between the different DAWs, because ultimately, I > find myself wishing I could mix-and-match a "module" of functionality > from qtractor with another module of functionality from ardour and > another from rosegarden. Some kind of abstract non-destructive-editing > core that can be "skinned" by Gtk, or Qt, or even in the browser ( > http://news.cnet.com/8301-19882_3-10354268-250.html ). this is a little misguided. i can only speak to the ardour case, but in the ardour case, we already do the "skin the backend with GTK" approach. libardour, the backend of ardour, makes no reference to GTK and no direct reference to any GUI at all (it can't, because we want it to be usable with no GUI, multiple GUIs, 1 GUI and 1 MIDI UI, 1 GUI and 1 OSC UI or any combination you can imagine). but what this means in practice is that more than 75% of the code of ardour *IS* the "skin". every person who has ever said "why can't we just add a Qt GUI for Ardour doesn't seem to grasp that in some very real sense, Ardour *IS* a GTK program much more than it is a realtime, multichannel, multitrack, nonlinear, nondestructive DAW (in terms of how much code there is that supports the GUI versus the backend). i am fairly sure that this is true of QTractor and Rosegarden also (substituting Qt for GTK, obviously). furthermore, even our choice of backend API (for example, our use of boost:: or sigc:: signals) has a fairly major impact on any user of libardour. i recently switched ardour3 from sigc::signal as the main way that the backend notifies interested parties of various changes and started using boost::signals2 instead. they are conceptually quite similar, but it still took a pretty huge effort to make the switch. and yet this was a relatively small change in a relatively unimportant aspect of the backend. even the *concepts* represented by the backend are important. the model that rosegarden has to represent tempo & meter is completely different from the one ardour has. even code level issues, trying to fit something from RG into Ardour (or vice versa) that has to tackle tempo & meter would be incredibly hard because of the different data structures and metaphors used in each program. > PPS: Ardour's Gtk doesn't seem to be as fragile since quitting only > produces the following, without coredumping :-) > .... > (ardour-2.8.7:29963): Gtk-CRITICAL **: gtk_box_pack: assertion > `child->parent == NULL' failed > Session writable based on /home/npm/Music/yoshimidoublearpeggiator/ > (ardour-2.8.7:29963): Gtk-CRITICAL **: gtk_box_pack: assertion > `child->parent == NULL' failed > i assume you've filed a bug report on this, and/or verified that the problem still exists in ardour 2.8.9 ? ... > _______________________________________________ > Linux-audio-user mailing list > Linux-audio-user@xxxxxxxxxxxxxxxxxxxx > http://lists.linuxaudio.org/listinfo/linux-audio-user > _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
