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
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 !
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.