5 Jun
2010
5 Jun
'10
11:15 p.m.
On Sat, Jun 5, 2010 at 1:19 PM, Niels Mayer <nielsmayer(a)gmail.com> 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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user