On Thu, Jan 27, 2011 at 11:46 AM, alex stone <compose59(a)gmail.com> wrote: [ ... ] good grief! i never said you were bad people. i have a lot of respect for you and chris. i was just puzzled and bit bothered that you would fork Muse and announce OOM2 without anything that notified people of that relationship. If you had forked *any* existing project of that size, for *any* purpose, I would have thought it would be common, normal practice to do make that link so that people (users, developers, supporters etc.) could make that link too. apparently, you feel otherwise. that's fine, just a little odd for most open source projects, that's all.

I don't think Paul said anything wrong or offensive at all and indeed he was asking the exact questions I had and went to your irc channel to have answered and indeed many others will be wondering about. Its already been alluded to but to end the mystery and speculation OOM2 is based upon Muse 2.0 for anyone else wondering where this sizeable app has suddenly appeared from. I totally agree with Paul thats its expected that people name their sources for forked projects and so it did seem very strange you omitted this from the announcement and so if Paul didn't ask the question here then somebody else would've- I know I was going to do just that but I took the irc route instead. If Werner is fine with you not mentioning/crediting Muse in relation to OOM2 then there is no problem here but Paul nor anyone else on this list could've been expected to know that. Dan On Thu, Jan 27, 2011 at 4:57 PM, Christopher Cherrett < ccherrett(a)openoctave.org&gt; wrote:

On Thu, Jan 27, 2011 at 11:08 AM, Paul Davis wrote: Hi Paul, Let me shed some light from the opposite side. I was one of the developers of the "existing codebase" [1]. Actually, I joined the project formally about 3 months ago and I believe I made a significant contribution in porting it to Qt4. The way I joined to the project was traditional: sent a couple useful patches so that people can get to know me, and after a couple rounds I got commit rights. From my experience with open source projects, this is the way things evolve. (I sent patches to ardour too in the past, you folks have been friendly all the time. I am pretty sure same thing would have happened if I contributed more frequently.) OOM folks took a different approach. Originally, we granted them an SVN branch and we were working under the same umbrella. They put really hard work in their branch, and I admired most of what they did. The plan was to merge their new features into the trunk. So we asked for patches for individual features. This never came from them. Instead they wanted us to grab everything (or a subset) as is. Our team did not have the resources to take the diff of each individual file to filter out each separate feature, and we simply didn't want to accept *everything* as is. Thus, we proposed them to fork. This is purely due to differences in the workflow and creativity. That said, I believe the original codebase deserved a little more credit than what is there in the bottom corner of the AUTHORS file. Moreover, when they forked off, they _kindly_ asked us to not backport some of the changes they made (mostly appearance related). While I do not have any intention of using their look, I found this a little odd. You are borrowing tens of thousands of lines of code from a project, don't give them credit in your project webpage, and tell them not to use your little contribution in their original codebase. There is something morally wrong here. Anyhow, I wish them good luck with their project. Best, Orcan [1] http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-December/075007…

On Thu, Jan 27, 2011 at 2:38 PM, Christopher Cherrett &lt;ccherrett(a)openoctave.org&gt; wrote: No, there really isn't.(At least not in as far as the original post that started this was concerned) Not sure why you keep insisting there is, but there isn't. It was a simple request, easily answered, and was turned into something much more than it really should have been. You also seem to think that the Ardour project is disgruntled with you. Not really. In fact many of us were discussing this project yesterday and today both on IRC, and aside from the attribution issue, it was well received in general and more than a fair amount of well wishing. There are things that confuse us, such as why fork an existing project when you were asked to put something in Mantis, instead of writing a patch for the single feature or expanding it, but that is your choice, and is part of the freedom of open source obviously and I think everyone gets that. The primary detractor from it was simply the attribution issue and clarifying that. At any rate, I think that has been expressed, wish you well on your project and I may play around with it myself before long as well. Thanks for the contribution to the community. Seablade

On Thu, Jan 27, 2011 at 2:50 PM, Christopher Cherrett &lt;ccherrett(a)openoctave.org&gt; wrote: Not really. There is the statement that not attributing is not morally correct, and as I said some people do disagree with the choice to fork rather than commit to(And as I said it is pretty well understood that is your right given the license), but I don't know what insinuations beyond that you are referring to as they really aren't there and I am fairly sure you are reading more into it than was ever intended by the original author. The second thing would never really have been an issue, it was the attribution issue that started all this and that is where it should have ended as well. Seablade

On 27 January 2011 19:38, Christopher Cherrett &lt;ccherrett(a)openoctave.org&gt; wrote: No, really not. Attribution is incredibly important to many open source developers, partly because there are so few tangible benefits involved with open source work, and partly because the force of the licenses we use (particularly the GPL) depends on being confident about the ownership of copyright. It matters a great deal to people if you take someone's work and represent it as your own. And it's a pity, because a situation like this or the earlier Rosegarden fork ought to be beneficial to everybody. With Rosegarden, your project's focus was different from that of any of our core developers and, although we like to keep people happy, we really weren't able to spend the time to do the things you wanted. Forking ensured that people who liked things "your way" had somewhere else to go, which made things better for them and simpler for us. In light of that, it's a great shame that the resulting new project should then give us such a sour impression -- and the same thing is true again here. Your casual attitude to other people's work means that I and probably many others would avoid working with you again, but that negative feeling could have been avoided with such a tiny amount of thought and even less work. Chris

On 01/28/2011 07:48 AM, Christopher Cherrett wrote: Ahhh, the tortoise and the hare... You know who won the race right? I don't think you want to throw down the gauntlet on who's the fastest around here though. Dat's just fighting talk!!! Anyway, everyone knows that Chris is one of the top dogs when it comes to precision development. People are still using STG2 because it was so well put together. A pretty interface is all very well but making sure everything works perfectly takes time and patience. -- Patrick Shirkey Boost Hardware Ltd.

On 01/28/2011 05:27 AM, Alexandre Prokoudine wrote: Heh, I'm flattered. There's a lack of design competence, but also a lack of developer time to implement design and/or a lack of better tools/infrastructure to make that less of an issue. Since a while now I'm thinking the solution can't be that I (or few others) do more, continue to not earn money, try to clone myself ... Not that I think of myself as being irreplaceable regarding my skills, but I do feel lonely here, while I know where to look, if i want to feel like a dwarf. The incredible good fortune and honor I had to see several of my concepts being implemented doesn't lend itself as a model for the wider realm, anyway. The way to become a Free Software developer seems to be clear enough (not that there's no room for improvement), motivation seems to be OK. Not so for Designers. It seems people who pick up coding tend to have fewer illusions about their skills and the quality level of their output and that there is always a long path forward, things to learn. Or maybe that's just my bias. Anyway: I think design in the FS realm fails on several levels. Developers and the general audience *tend* to not understand how it permeates everything, how it is pretty much defining and solving problems in a top-down manner. Instead there's this making-things-pretty thinking, the usability means dumbing things down thinking and an unhealthy focus on familiarity mistaken for being what's "intuitive". Usually, when any well known project opens a venue to discuss design, the result is a flood of opinions. But bring up a tricky issue, where no pre-produced mere opinions match and you either get silence or pure idiocy. Oh, and don't bother to push for formal processes, clear goals, requirements, evaluating alternatives ... that's all just bureaucracy. Counter reactions to that tend to lead to closed circles, perhaps productive for a while, but becoming echo chambers. Designer who want to try some not so usual approaches will soon find them in a situation where learning to program will seem more worthwhile than trying to convince developers. After only few steps they will start to understand why developers don't tend to jump up and implement something in an afternoon ... But there are only so damn few hours in the day! The best we could have might be developers with more design thinking, designers with more technical knowledge, and much better tools that blur the lines between mockups, prototypes and final implementations. Here, we should learn from CAD tools regarding dealing with constraints and parameterization , Flash (the authoring tool) and Smalltalk environments like Pharo. I have a still vague vision, something like a mix between Etherpad, a wiki, bug tracker, sites like github and stackoverflow. A place where design needs meet design solutions. With design methods and knowledge baked into the infrastructure, both for educational effect and as an accelerator. Where unfounded opinion, noise, sinks to the bottom, fast. What a longish off-topic, took-too-long mail, but I do feel better now ;) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

I'm surprised Alex included RG in that list as to be honest, powerful and fully-featured program as it is, I think RG is really let down by its clunky (mainly too big) GUI and I was hoping for a complete overhaul when it got ported to QT4 but sadly that didn't happen. Attractive GUIs are definitely great but are always secondary to functionality and stability, Besides, most people on this list are quite happy to work with apps that have NO gui ie ecasound or minimal, archaic GUIs ala PD. For me, the biggest turn off in a GUI is if its too big- ZASFX/Yoshimi, RG and to a lesser extent Ardour all suffer from GUI's that are a nightmare for smaller displays such as netbooks and older/budget laptops. I do like the look of Ardour but I still believe it needs to go on a bit of a diet. There are still many perfectly good laptops (Core 2 Duos etc) that can't do any better than 1280x800 but I'd encourage devs to try and get their apps to fit nicely onto 1024x768 to be even more inclusive. On Fri, Jan 28, 2011 at 12:10 PM, &lt;fons(a)kokkinizita.net&gt; wrote:

On Fri, Jan 28, 2011 at 2:35 PM, Hartmut Noack &lt;zettberlin(a)linuxuse.de&gt;wrote;wrote: I see your point and 'most people' was prob they wrong way to phrase it as I personally have never used ecasound and I totally agree about the many advantages of a GUI for audio production. I think the point I was trying to make is that I'd expect Linux users on the whole to be less concerned about a pretty GUI than Windows and especially OSX users. Personally, If I have a choice between a super-shiny, CPU hogging GUI or a much more plain yet just as functional and much less CPU intensive GUI I'd go for the latter every time. Nice looks don't mean the program is any easier to use although bad colour schemes, un-intuitive layouts and GUIs that don't fit on your screen are obviously a real problem. Nice GUIs are cool and are desireable but pale into significance when compared to usability, stability, performance, features and in the case of synths sound quality.

Hmmm, RG works quite well on my budget laptop's 1280x800 display. As does Ardour 2. Haven't tried Ardour3. For comparison, the K CD Ripper app on my system always opens its window about 1800px wide and is not resizable. The Zyn UI is a whole 'nother matter - it works fine, but you can't resize it, can't fix the font size issues (text chars too big to fully display). I understand the issue there is the developer of Zyn likes it that way and sees no reason to change it. Similar to why Cal forked Zyn as Yoshimi: Zyn developer sees no reason to change things that Cal considered important. I doubt that "most" people on this list use ecasound. ;-) But GUIs are NOT the perfect UI for everything! IDEALLY, your program is split in 2 parts. One part is the back end that does the work and has a complete, cleanly-defined and well-documented API callable from multiple languages. The other part is the UI. If the backend's API is good, the UI can be completely separate from the backend. If someone doesn't like the UI (it's too cluttered, too heavy, too little) they can roll their own. If someone needs a text UI, they can write one, too. That way, "non-UI-design"-focussed programmers can make a great back end, while those more interested in UI design can make a great front end. allcoms wrote: -- David gnome(a)hawaii.rr.com authenticity, honesty, community

On Fri, Jan 28, 2011 at 7:10 AM, &lt;fons(a)kokkinizita.net&gt; wrote: I think the biggest thing is finding a balance between form and functionality. Often times, the form aspect gets left behind slightly in open source software, either due to lack of time, or lack of talent(Meaning programmers aren't always graphic designers which is perfectly fine). In some cases functionality is taken to an extreme at the expense of form, rather than finding a balance between them. I personally think Ardour suffers some from this on occasion for example, but I don't think that is much of a secret either. I am also perfectly fine to be disagreed with on this topic as well:) What do I mean by form? I mean not just doing basic straight primitive shapes because they are the easiest to program, often times subtle changes make things much more attractive to look at, but they are also the most difficult to do in a way that is subtle enough not to draw attention to itself. If overdone functionality itself can suffer. I am going to pick on Thorsten here slightly as I think this is his work, but I do want to state up front I have the uptmost respect for him and his work. To give an example I am fairly familiar with, take Ardour's fader strips. Possibly the most commonly requested thing to be upgraded in Ardour's appearance, it is unlikely to happen because the current design is exceedingly functional. The design goals included making it visually obvious that the entire fader could be clicked on to initiate the drag, instead of just the graphical representation of the fader knob that is so common(In Mixbus for example). My question on this however would be, is the balance of form and functionality maintained in this design. How much of a difference does that functional design provide to most users, vs how much of a difference does it make to have something that many people consider not very 'flashy' looking, which there is two parts of the latter half of that. The first part is how many users are just turned away from the get go, assuming that if time wasn't spent to make the interface look nice, then it is indicative that the software itself doesn't work nice. Sad to say this is factor for many people, they choose audio software based on the appearance, that topic is left to another thread, but it is a given. The second half of this is, once it is established that you can click anywhere on the fader, how much of a detractor is it to be working starting at something that is 'less than shiny' for hours on end. For many people, myself included, it can make the work slightly more enjoyable if we enjoy what we are looking at as well as what we are listening to. I mean we are talking about something that while it is visual and not audible, and we should be concerned with the audible side of things primarily, we do have to stare at the same screen for hours on end and even though it doesn't affect the audio coming out, it does affect our personality/morale/working attitude and might very well lead to getting exhausted a bit easier. Obviously all of this is slightly moot, and is part of why I used the wording I did, because the old addage goes, "Beauty is in the eye of the beholder." What I think looks beautiful can be very different from what Paul does, or anyone else for that matter. There is no one single thing that will always be beautiful to everyone, but I think there can be some things that increase visual attractiveness to most people. Anyways random rambling over, does that provide a bit of clarity at all to this? Or just muddy the already opaque waters? Seablade

On Fri, Jan 28, 2011 at 2:37 PM, Thorsten Wilms &lt;t_w_(a)freenet.de&gt; wrote: Completely agree. But I did phrase that intentionally as along with hints from the GUI there are other ways to establish that as well, whether they are correct or not is always a good question. Examples would be in the documentation and the every annoying popup 'hints' that would describe this. And documentation doesn't necessarily mean written, but video as well in the form of tutorials etc. could be useful as well for this purpose. Note that I am not saying that is the answer specifically in this case, in fact I don't think it is, merely explaining why I used that particular phrasing. Seablade

On Fri, Jan 28, 2011 at 6:20 PM, &lt;fons(a)kokkinizita.net&gt; wrote: luckily, as someone recently demonstrated, simply replacing the png file used for the faders is a trivial way to find out: http://www.ardour.org/node/4039

Thorsten Wilms wrote: Do you really mean left, or do you actually mean primary button? Or is the left button your "right click" i.e. secondary button? As a general moan, certainly not aimed at any particular piece of software but it's as good a time as any to remind people, it's really annoying to read dexter-centric user documentation (-: "Click" and "right click" is just about okay for me as I instinctively "right click" with the left button, but "left click" makes me think and that's when I start to get confused, when the brain tries to over-ride instinct. Admittedly, hardware is generally more of a problem than software -- I find it almost impossible to answer my mobile because the call button is obscured by my palm and the buttons can't be swapped: thank goodness the trend for handed mouses died out in the 90s. We'll only ever be a minority of users, but we are sizeable minority and we have been oppressed for centuries, please don't continue the oppression q-: Sinistrally yours Q -- A musical collaborator: "Lethargy, hm really? Then it will be time for me to get over there and just accidental idea the $h!t out of you"

On 01/29/2011 01:19 PM, fons(a)kokkinizita.net wrote: Knowing isn't enough, as this is behavior that either is, or becomes automatic/sub-conscious due to training. Blender has drag-from-everywhere sliders with knobs. I found myself aiming at the knobs and the same was reported by other users. Anecdotal, yes, but this has to weight more than just claiming it doesn't happen. One or 2 pixels if you draw a frame around the widget, vs half a knob-length. They are no suggested at all. Extra functionality that doesn't indicate its presence, but is nice to have, you just have to know about this. I deem this acceptable in cases of non-critical functionality, where the alternative would be to simply don't have it. Brought this up as a side-note only, though. This supports what I said about knowing it not being enough ;p But should the faders have their own scales, somehow made to match the existing scale, or what would you suggest? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On 1/29/11, James Morris wrote: That sounds like a typical defensive reaction to me :) Let's try to avoid dumbing argumentation down to "shiny ergo bad". The question is not just about people refusing to use Linux, because they don't see so many shiny buttons, the question is how to make ourselves better tools -- tools that let any kind of musician (hello, Louigi :)) to get from an idea to final mix in less time. How can you possibly refuse that? :) As for UI, polish is part of what makes an application a craftman's work. There's nothing wrong about a job well done. But it takes people of different skills to get there. Speaking of which, GSoC 2011 has been announced earlier this week. I can only recall Ardour, Mixxx and CLAM participating in the past. Any other teams interested? Here is the timeline: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/ti… Alexandre Prokoudine http://libregraphicsworld.org

On Fri, Jan 28, 2011 at 2:35 PM, Alexandre Prokoudine &lt;alexandre.prokoudine(a)gmail.com&gt; wrote: [ ... what makes a GUI non-90's ] this is a brilliant summary. thanks alexandre! this is a very nice list too, but i'd add one more thing to it: 7. whether you provide user-configurable keybindings for every possible action in the GUI

Niels Mayer wrote: Which can very easily turn into useless visual clutter that hinders usability. -- David gnome(a)hawaii.rr.com authenticity, honesty, community

On 1/27/11, Christopher Cherrett wrote: So much for groin-level kicks. You were approached in a civilized way. Paying back with something like this is really low style. No, really not. Atrribution is very important. The whole DVCS thing immensively helped there. Being able to be *automagically* quoted in the log as developer made a lot of difference, and social coding (Github, BitBucket etc.) made a lot of difference too, because it's all about attribution (as well as being easy to fork, improve and send merge request). Yep, I personally knew that OOM2 was based on MusE2 even before compiling and running, but this is because being curious is my job, and reading the commit log at github was so easy. But you know, I don't expect everyone to be a journalist. Do you? Having said that, I do see potential in the project as well and I'll be tracking its progress with interest. Alexandre Prokoudine http://libregraphicsworld.org

On Thu, Jan 27, 2011 at 4:30 PM, Hartmut Noack &lt;zettberlin(a)linuxuse.de&gt; wrote: this isn't my fight, but I just checked out the code and found this: OOM2 is developed from the base code of MusE (Muse Sequencer) written by the mighty Werner Schweer, and maintained and modified to the present day, by the current Muse2 maintainer Robert Jonsson and his team. We not only willingly credit Werner for his code, but add our deepest respect and admiration as well. -- Josh Lawrence www.hardbop200.com

On 1/28/11, Hartmut Noack &lt;zettberlin(a)linuxuse.de&gt; wrote: Maybe because this notice was not there before yesterday. See the entry 'Here's your attribution [2cc32fc]' on this page: https://github.com/ccherrett/oom/wiki/_history Andras

On Thu, Jan 27, 2011 at 2:38 PM, Christopher Cherrett wrote: Hi Chris, what's wrong with using the colors? (just curious) I would make it clear in my fork's webpage [1] that the codebase is taken from such an original project, give thanks to the developers and the users of this original project, and obviously give the link to the original project's webpage. I would give the date of the fork, and explain what has been modified. Thanks, Orcan [1] well, not really. I would probably not fork in the first place.

Christopher Cherrett wrote: Smart man he is. I'll continue to stick with Rosegarden, and maybe look at Muse again. You can take your rude, trample-on-others-because-my-need-is-great attitude and your forked projects and roast. -- David gnome(a)hawaii.rr.com authenticity, honesty, community

On Thu, Jan 27, 2011 at 12:38:39PM -0700, Christopher Cherrett wrote: this was not a clarification. i looked at your repo. its under no circumstances mergeable. you say your moving too fast. your not tidying things up. this is going to come down on you later. you really need to keep your history clean. take a bit of time. use git rebase -i before you push stuff upstream. (or at least before you merge it into the master branch) this makes me sad. thats what theyll need :S -- torben Hohn