18 Apr
2010
18 Apr
'10
8:03 p.m.
On Sun, Apr 18, 2010 at 10:21:06PM +0200, rosea.grammostola wrote:
On Sun, 2010-04-18 at 08:31 -0400, Paul Davis wrote:
its sort of my fault. i dont feel comfortable with the jack2 codebase.
this partly has to do with the style used.
the important thing however is the class hirarchy.
i find it unacceptable that i need to add a method to 5 classes to
implement some new api function for example.
i end up writing a lot of boilerplate code i find useless, and
i really hate to write useless code.
many of the other design decisions dont make sense to me, and i am
having a pretty hard time finding the relevant code fragments.
(who would search for the servers event processing loop in the platform
specific Communication channels ?)
this makes hacking jack2 a rather unpleasant experience for me.
since nobody pays me to work on jack and i am doing this for fun.
i minimize hacking jack2.
yet since nobody will do the jack2 session patch i am forced again to
work on jack2.
i wrote tschack because i wanted to try out a different approach to the
functionality in jack2. and to understand how a parallel jack works.
now some people who had bad experience with jack2 tried it, and it works
for them.
so there is no reason to hide tschack.
i dont see a reason to try to get stephane to reconsider his design
decisions. it were his decisions, and he seems to be happy with them.
my way is to start from scratch with a new c++ implementation.
for me this has the benefit of not using CamelCase. which will never get
removed from jack2 (why should it? stephane likes it)
regarding distros move to jack2 i think its the right thing.
i just made sure, that it will be possible to install an alternative
jack implementation.
iE people had a pretty hard time installing jack2 on debian.
if they had just moved to jack2 without making libjack a virtual
package, people would have problems instlling jack1 or tschack.
now the packagers dont really want to package N versions of jack, since
they would need to test all combinations of apps and jacks.
but as long as sombody is able to provide jack1 and tschack .debs it
will be fine.
packagers are happy, and other people are able to install some
alternative.
On Sun, Apr 18, 2010 at 5:16 AM,
rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
This could all be true, but that's not the point I was talking about.
JACK2 was planned as successor of JACK1. But at some point that changed,
that's all ok, not the point here. But isn't it odd that this isn't
clearly communicated with the JACK2 maintainer, why this is happened?
That was raising questions here about the communication within the
(highly appreciated) JACK project. It's pretty odd that you guys didn't
discuss this clearly with each
other. It seems that people have an opinion about something, but only
share this with people who have the same opinion and not with the one
who himself or his code is subject of 'critique'. This is bad
communication and bad team management.
oh god. you clearly don't understand ANYTHING about how open source
development works.
there was constant discussion about all of this. But Stephane doesn't
own JACK, I don't own JACK, Torben doesn't own JACK, Jack O'Quinn
doesn't own JACK. When someone works on their own implementation of
JACK, they are free to make their own decisions about how things are
done. Maybe their ideas will be better (or worse, or about the same)
as any existing implementation, and because of this, its important to
allow them to take shape as they see fit. Clearly, providing useful
feedback and ideas is great, but there's no reason for any committees
or meetings to decide how a different implementation is going to work.
In this particular case, Jack2 started out (as Stephane has described)
as a sort of experiment - how would SMP support work, could we do
click-free graph changes, would a C++ implementation be easier to
manage, etc. etc. In that context, its not appropriate for anyone
who's not actually working on it to be trying to make decisions about
internal design. Lots of people, including myself, had input into the
design and evolution of Jack2. Pretending otherwise is ridiculous.
Jack1, Jack2 (and even the not-quite-born tschak) all implement 99.83%
of the same API. Beyond that, how they work internally is the business
of their implementors and maintainers. If someone has an opinion about
it, they are free to take it up with the implementors and maintainers.
If they feel strongly enough about it, and they don't feel that the
implementors/maintainers are doing things in the right way, they can
fork or reimplement (this clearly doesn't happen much).
quote=Stephane
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
I must say that I still don't have a clear
understanding of why this
happened. I still don't understand the sentence "Like Torben, there
are some design decisions there that I have questions about." and I
think explaining it in more details would really help.
Regards,
\r
It would be good if an '(mini) JACK
Conference' will be organized, where
JACK developers can speak each other face to face, code to code. And
share future vision, coding vision etc. IRC and mailinglists are great,
but not always the good method for communication.
Traditionally, this would be done at the Linux Audio Conference, which
I will, alas, be unable to attend this year. That doesn't stop other
people from meeting on these issues, but my impression is that we have
all become somewhat tired of struggling with the situation and instead
have been trying to find ways to allow the status quo to continue, but
better.