*grabs flamethrower* On Wed, May 6, 2009 at 10:34 AM, Andreas Pflug <[email protected]> wrote: > Albert Santoni wrote: >> Hi guys, >> >> I'd like to schedule a Skype meeting sometime in the next two weeks to >> talk about Mixxx 1.8 > 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. :) > > Looking at 1.7 Beta, I wonder if this version is really mature enough to > justify a beta release. Apart from bug fixes there are two major > features added: Scripting and the midi wizard. > - I didn't succeed in getting the scripting engine to do work. As a > regression from 1.6.1, my Hercules RMX doesn't work, and the js > functions just return nothing. 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 [1], 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.) > - 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? 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. > > 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 > http://www.mixxx.org/wiki/doku.php/midi_controller_mapping_file_format#ui_midi_controls_and_names > 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. There's a dozen other problems with the control system too. 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 have. > > Currently, the wizard does everything hardcoded, guaranteeing to be a > PITA for further maintenance. But before starting to code a wizard, > there needs to be some kind of control registering architecture, so > anybody coding according to hints at > http://www.mixxx.org/wiki/doku.php/adding_a_new_button_to_mixxx_s_interface > automatically provides all information needed by the wizard (and > potentially other instances) without poking around allover the code base. > 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. > 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.) > > 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. 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: http://sourceforge.net/mailarchive/message.php?msg_name=499A49F9.5050302%40renegadetech.com 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. > Next, the control creation code should be refactored > using some kind of registering mechanism, which consecutively allows a > wizard to enumerate all controls with their properties. This approach > seems far more sensible to me than adding more and more half-brewn > features which are ultimately not maintainable. It's about creating the > infrastructure for future enhancements. 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. 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. Thanks, Albert [1] http://www.mixxx.org/wiki/doku.php/supported_controller_test_grid ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
