Adding more features.. In general.

edited February 2014 in General
Hey all I am impressed with the constant updating of this really cool looking instrument, and of course the sounds and synthesis look really nuts!!!  But I just want to speak my mind here, which comes from experience with other open source projects as maybe a warning...? 

It is easy for hundreds of users to come up with many, many "necessary" features.  And as a programmer I understand how it is always tempting to "accept the challenge" of implementing more and more features, modes, and ideas. And then more and more.  and more.  To the point where the instrument gets clogged up with crazy button combinations, undocumented modes, odd behaviors that are only seen on one screen and other issues that affect the instruments playability.  The project becomes a mutant which has lost track of its original vision.  And so my point is that we should keep in mind the usability of the machine, and how a good user flow is more important than having 1001 features that most will never use.  "Instant fun is guaranteed" should be the guiding principle!  

I have not even built mine yet so I cant speak about actually using the LXR.  But I've seen other projects turn almost unusable unless you were there programming the thing from the get go and I would hate to see this happen with the LXR.  I think having a concrete "end goal" in terms of features/functions should always be in place.  Bug fixes, and making things run smoother, faster and more clearly is always good, but adding things because there is code space left is not a good work habit.


That being said, I am excited to build mine when it arrives and to dig into the source for a little customization of my own!

thanks for hearing me,
with the best intentions,
~Steve

Comments

  • I totally agree and relate with you revtor. As a passionate user of this great instrument, I would definitely prefer having my LXR fixed from all his bug (for example there are still original features, such as LFO destinations, that don't work), than implementing certainely cool, but not highest priority new features.

    When I'm picturing myself using this instrument in a live context (cause it totally deserves it), I'm still reluctant, I'm afraid it might let me down, or be unable to launch an effect I had planned.

    That being said, the developpers are making an amazing job with their constant work, I'm just approving revtor in his suggestion of :

    "Usability of the machine, and how a good user flow is more important than having 1001 features that most will never use"

    Best


  • PLease, if you're not happy, DO YOUR OWN FIRMWIRE !  and share it, with the only features that's interest you. I dont think the LXR features are messy as you said. I use all the function of the rudeog firmwire, so please, if you dont use them, don't say they are useless. If you can't handle it, if you can't read a forum thread, if you can't search for some informations, please stick to the official firmwire, which is still really great . If you want to help here, work on the wiki, help people find bugs, do your own firmwire (yeah again) I don't feel i lost the lxr usability with all the new features, au contraire. 
  • I am happy.

    I never said the LXR features were messy.

    I can handle it.  I can read a forum thread.  I can search for some information.

    I plan on messing with the firmware for fun.

    I am happy that you didn't lost the usability of the LXR.


    thanks for understanding,
    ~Steve
  • @erwanone: no need for so much aggressiveness rector here just expressed an opinion making it clear he had the best intentions, and did not point to any current feature of the LXR he thought was useless or superfluous.


    He just voiced concern about the strategic idea behind what feature gets added and what not. Maintaining focus is very important in product design, that is all.

    I think that his opinion is good food for thought, and certainly hope rudeog and Julian read this article to reafirm in them the same beliefs.

    The LXR is a hell of a great drum machine right now, and will be much much better once it is fully fleshed out firmware-wise, but a focus on stability and completing the basics needs to be there.

    Let´s all relax by jamming with our LXR a little more!
  • I didnt want to be aggressive. I cant see how all the updates are not usefull. I didnt see strange combination of button or odd behaviour. Complain about original features still bugged is really easy, try to fix it is harder...If some people find the improvment of rudeog are not really usefull for them, they can use an older version, or better, modify the firmwire to "erase" the function they dont want. I cant see how new feature is not interesting thats all.
     If you plan to work with the firmwire, i would be very happy to try your version.
  • Thank you Varthdader, you totally got the point : strategic suggestions, i.e. ideas about the program design improvement (and not useless rant...). 

    Of course it is just ideas, which can vary from one individual to another, but "stability and completing the basic needs" it's always a good focus in every design project :)

    I wish I had the programming skills to help in the debugging process ! But as erwanone pointed out, people less skilled can still : "work on the wiki, help in finding bugs" and suggesting ideas !


     

  • I can definitely understand the concern here, and there are indeed some good points raised.
    Having worked in software development for over 20 years, as well as having owned more drum machines than I can count, I can appreciate the importance of product design and usability. I've seen my share of good ones and bad ones :-) The LXR is still in a fairly early stage, and I think people are playing with it, and seeing what's cool about it, and what shortcomings it has, and are offering feedback. Features are still being added, bugs are being fixed. There will probably be things that change (but hopefully not in a radical way).
    Generally in the software development process you have two camps: users, and developers. In this case, we have two camps as well, but they are users, and developers who are also users, so there is the danger that developers, wanting a feature for themselves, will add it, and users who are less keen on it are stuck with it. I can definitely understand the concern.
    In my case, If I were to add an off the wall feature that changed the way the machine functioned to the point that it didn't correspond with general expectations, I'd keep it off in a branch so that those who wanted to play with it could, but those who didn't were not burdened by it. Or, make sure the feature is off by default, could be turned on in a menu, and doesn't chew up resources.
    I don't think there is a danger of developers "accepting a challenge" for the sake of it, or trying to use up every byte of prog space because they can. Julian is running this as a business, and has a huge interest in keeping people using it (and therefore promoting it). I am approaching this to tailor for myself a machine that rivals and improves upon offerings from Korg, Roland, etc, is eminently usable in a live situation, and plays well with other midi gear. I'm also very interested in making this useful for others, so that it gains the popularity it deserves. I agree that if people find the box too hard to use, or not fun to play with, they will just shelve it and go play with their Electribe (or other toys).
    I think that once more people start hacking firmware, we will see some interesting developments, but we will also see more of a need to keep a sane "release" version that is in maintenance mode (ie. only bugfixes) so that those who don't want to be on the bleeding edge, or those who are just coming into this from the outside, have something to use for day-to-day stuff.

    Anyway, good points, all.

  • If you want to foster developers, get it the hell out of Eclipse, and into a simple autoconf/make based system. Nothing puts me off working on it more than having to deal with Eclipse.
  • Sounds like we have a volunteer with some incentive to create some autoconf/automake scripts! I'll be happy to merge your changes into my repository when you have them. ;-)

Sign In or Register to comment.