Thanks for taking the time to express your opinions. The Mixxx
development roadmap is the result of considerable thought and
experience so I will try to explain the reasoning behind some things.
Since 1.6.1 there have been a few significant improvements. Without
dragging out the whole changelog the biggest things from an end-user
point of view are probably MIDI scripting, which allows complex
mappings to be developed without recompiling Mixxx and big
improvements in stability. For more details, see this blog post:
Depending on how you use Mixxx of course, you may find that none of
this provides extra value to you but these features will provide
significant new functionality to a significant fraction of Mixxx
Your main complaint though is about the quality of the beta release.
The whole purpose of the beta release is to be feature complete but to
attract both testing and discussion of changes, which is exactly what
is happening here. You shouldn't expect it to compare to the quality
level of a beta release from a large development team (proprietary or
open source) with enough resources to devote to internal testing and
QA. But then Mixxx is not Ubuntu or OpenOffice and not only has this
definition of beta served us well in the past but you will find
similar policies in most other small open source projects.
Having worked with Mixxx for several years I have a reasonable grasp
of the contents of the codebase. In my opinion rewriting the control
system would be a significant task, since many disparate pieces of
code touch on it and expect it to behave in various ways. While I
appreciate that it may appear like a trivial problem to solve in some
ways, the control system is more than just a map of strings to
numbers, it is the system by which the core audio engine communicates
with the user interface and receives input from the user interface and
MIDI controllers. It must also handle additional issues such as
thread-safety. So I would suggest that this would be a rather large
and challenging project.
Since rewriting the control system is such a large task, we have
considered the benefits of various approaches and decided that with
our current resources, the best way to deliver value to our users is
to implement functionality on top the existing infrastructure.
Having said that, if you have an interest in working on this topic, we
would be happy to assist with and review any code you produce. I would
also recommend that you consider coming to the meeting on the 17th if
you are interested in being involved in Mixxx as this will give a
better overview of the development process and roadmap.
2009/5/6 Andreas Pflug <pgadmin@...>:
> Hi Albert,
> Albert Santoni wrote:
>> *grabs flamethrower*
> <ducks head>
>> On Wed, May 6, 2009 at 10:34 AM, Andreas Pflug
>> <pgadmin@...> wrote:
>>> Well, I'm afraid this post isn't going to make me popular, but I feel
>>> kind of impelled to make my remarks, because I think Mixxx is a fine
>>> product that has quite some potential (as of 1.6.1).
>> Thanks for the compliment. :)
> <raising head a little>
>> The regression we experienced with the Hercules controllers was to do
>> a slip-up we made when porting our mapping files over. I asked people
>> to test MIDI controllers before the beta release, nobody tested the
>> Hercules ones , and I was fully aware of this. I was prepared to
>> release the beta with broken Hercules support, in the worst case. If
>> you want to make Mixxx better, please test your controller when we ask
>> for testers next time. (The point of the beta is to find problems like
>> this too. When people stop reporting problems with our pre-beta
>> packages, it means it's time to go ahead with a wider release in order
>> to get the feedback we need.)
> I received my Hercules last week... :-)
>>> - The midi wizard is far from helpful, because it supports just a very
>>> very basic set of controls, and doesn't understand their specific
>>> attributes (it's not just about inverting a fader!).
>> Do you have any specific suggestions?
> Actually I'd have some suggestions, but I actively refuse to share them
> because I really think it's too early to discuss this. Implementing a
> wizard is much easier with a good controller infrastructure underneath
> mixxx' surface.
>> Certain sophisticated features like automagically mapping the range of
>> a jog wheel will be tricky, but it's not out of the question. However,
>> I think the MIDI learning wizard is functional enough to get _most_
>> users a basic MIDI mapping. There's a handful of extra features we can
>> add without too much difficulty, but after that, making the MIDI
>> wizard more robust will start to take more time. This is the best we
>> could do with the amount of time we were able to put into it, and I
>> think expanding significantly beyond what we have at this point is not
>> going to be beneficial in light of the feature freeze.
> <harsh mode>
> I believe 1.7 will only have a poor and hardly usable midi learning
> wizard, barely worth mentioning in the release notes. Spending time on
> fixing this on the current control frame code base is a waste of time.
> </harsh mode>
>>> While I can't tell what's wrong with the scripting, I have a distinctive
>>> meaning about the midi learning function: it's a feature that was
>>> implented on a base that doesn't provide the infrastructure to do so. A
>>> quick look at
>>> shows what I mean: it's still undocumented which controls actually exist
>>> and what they do, not to mention their specific attributes. A wizard
>>> needs to know all of these, PLUS it must be maintainable so that any new
>>> feature immediately shows up in the wizard.
>> This is a fundamental limitation of our control system. Just to make
>> sure you know where we're coming from, none of our current developers
>> or contributors designed the ControlObject framework or had anything
>> to do with its implementation. There is no central list of available
>> controls inside Mixxx at runtime. There is no description of the
>> ranges of each control inside Mixxx besides some comments in the code,
>> if you're lucky.
> That's my current understanding. Don't understand me wrong: While the
> current implementation isn't that elegant, it works ok for 1.6. But it
> won't for further extensions.
>> There's a dozen other problems with the control
>> system too.
> Probably some I didn't realize so far.
>> I completely agree with you, but the infrastructure just
>> wasn't there to begin with, and so we've had to work with what we
> I think it's a mistake not to fix this NOW, not later. You'll be
> throwing away too much.
>>> Currently, the wizard does everything hardcoded,...
>> Yes, this registration architecture is the sort of thing you'd want to
>> code when you're _starting_ to write a piece of software like Mixxx.
>> It's going to be a tough task to address this problem now or in the
>> future, but regardless, several of us developers agree that we'd still
>> like to see some sort of replacement for the control system at some
>> point. Whether or not we can actually do it (and have worthwhile
>> gains) without rewriting Mixxx is still unknown to us.
> I don't think it's that tough (... see below)
>>> In addition, I still don't really know where I can find the very latest
>>> sources. Obviously, it is NOT trunk, as I'd assume. Code snippets seem
>>> be be scattered around branches. That makes it quite hard to contribute
>>> stuff, unless it's just some fixing oneliners.
>> We're in the middle of switching over our main development from
>> SourceForge-hosted SVN to Launchpad-hosted BZR. We're also beginning
>> to change our development workflow so that we use branches more.
>> You've caught us at a bad time, sorry. The 1.7 branch in Launchpad is
>> where we're doing active (albeit feature-frozen) development for the
>> time being. I'll explain in some detail our new workflow at the
>> meeting, and we will be sure to document clearly on our site/wiki
>> where development is taking place for new developers like yourself.
>> (New contributors are our lifeblood, so we try to do our best to make
>> sure Mixxx is reasonably approachable for new developers. Our IRC
>> channel - #mixxx on Freenode - is a great place to ask questions and
>> hang out with the dev team too.)
> That's an unfortunate situation. I could spent some time in the next few
> weeks, but I need a usable system. I can't see where I should start now,
> apparently the best candidate would be 1.6.1 (for me). And a prolonged
> migration period from svn to bzr is plain horrible. Apparently I
> invested time in a dead trunk, following the official instructions.
>>> Since IMHO 1.7 doesn't provide mature additional stuff, but currently
>>> imposes some regressions, I'd propose to retract the 1.7 Beta, clean up
>>> branches/trunk, and prepare a 1.6.2 version that has all fixes currently
>>> announced for 1.7.
>> The new MIDI stuff might be basic, but it's functional and stable, and
>> that's as mature as we need for 1.7.
> I consider this a street that won't go anywhere.
>> Sure, if we had more time to make
>> stuff even more feature-complete, we would have, but our users are
>> still going to appreciate the functionality we've added. (Release
>> early, release often?) Also, we had a discussion about 1.6.2 vs. 1.7
>> about a month or two before you showed up on mixxx-devel, part of
>> which is here:
> Well, whatever it's called... I won't argue about version numbers.
>> Re: redacting the release - We've already been advertising 1.7, so
>> it's too late to change it now. The plan was to clean up branches and
>> finish migrating to BZR after the final 1.7 release, and I think it
>> would just be a distraction to do it before then.
> Hm, this is not a beta to me, but an early alpha. It's not only Hercules
> being broken, but I failed to get it working too.
>>> Next, the control creation code should be refactored ...
>> We hear you, but refactoring the control system is a major task, and
>> we think that our users would prefer to have a simpler MIDI learning
>> system + scripting sooner over some more complicated system later (and
>> I mean _much_ later). We picked our feature targets for 1.7 a long
>> time ago, but if a refactored control system is something you'd like
>> to see for 1.8, then I'd invite you to come to our Mixxx 1.8 Skype
>> meeting to come both see the big picture and have a better opportunity
>> to discuss it with us.
> AFAICS, 1.7 will not bring me ANY advantage. The midi xml description is
> still more complicated than necessary (and buggy, try a comment like
> <!---------- ...), and any feature I'd add in the very near future would
> be on source code. My point is, there has been discussion about features
> to implement while the platform doesn't really support it. Releasing a
> wizard now is very much cosmetic.
> Methinks creating a viable control system framework isn't that hard (I'd
> do it probably over a weekend, seriously). I'm not too inclined to
> participate in a meeting over 1.8 features, for several reasons (I'm
> probably not interested in most features wished, like sound plugins),
> it's just homework to do (fixing not only the control system, but the
> hard wired sound manager as well). I know, talking about fancy features
> is soooo much more fun.
>> For the most part, I hear your concerns, but unless you can tell me
>> exactly what problems you have with our new MIDI features that are
>> going to be critical for the majority of our users, I don't see a good
>> reason to change any of our plans.
> Summed up, I believe 1.7 won't deliver substantial advantage over 1.6,
> even regressions when previous midi descriptions are not functional any
> more, not promising too much benefit when migrating. And who's the
> audience for a minimal midi learning wizard anyway? Do you think there
> will be a single additional DJ controller usable without manual midi
> definition tweaking?
> <back in the trench>
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> Mixxx-devel mailing list