On tal, 2014-09-30 at 10:56 -0400, Paul Davis wrote: Why doesn't Harry learn howto do a dial. I just take a look at his code and it just sucks. Why don't you take a look how it should have been done. For sure you will get it for once. https://sourceforge.net/p/ags/code/HEAD/tree/src/ags/widget/ags_dial.c kind regards Joël

On arb, 2014-10-01 at 12:39 +0100, Harry van Haaren wrote: Excuse me being unpolite I just was thinking about all day. I can say it sucks because me was at the same point. Please take this as a chance to learn where the user benefits of experience. Scaling is done normally between -1.0 ... 0.0 ... 1.0 Your constants are false. I can't say if it was cause of selfishness looking at the code but telling you that you're wrong is cause wanting you to help. have a nice evening and kind regards Joël

On Tue, Sep 30, 2014 at 2:10 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote: given that i don't really agree with his talk, i'm going to defend it anyway. what has happened with automobiles? when first introduced, they were the domain of enthusiasts only. then they spread out to a wider audience, an audience that was frequently irritated by the maintainance requirements, breakdowns and poor behaviour of the machines. that gets us to the 1980s. and now .... cars are almost all of a near-uniformly high quality, and that quality exceeds the levels attained even in 1970's era elite vehicles. you need to know almost nothing about them to use them (other than knowing how to drive). their reliability and longevity have improved dramatically, as have their safety qualities. maintainance is generally simple - regular oil and other fluid changes, less frequent tire replacements, occasional body work due to damage. oh, and much better fuel mileage too. of course, every single one of these improvements isn't the end of the road (no pun intended), and new engine and propulsion systems still offer huge new areas of potential improvement, along with self-driven cars for some situations. if i give this presentation the benefit of the doubt, what he's arguing for is that *consumer* software, having arrived at feature parity, should be planning to evolve in the same general direction that automobiles have. that is: away from an object only maintainable by an enthusiast who is willing to take the time to learn about it, passing through the phase of an unreliable, short-lived object that gets fixed by others, to reach a state where fundamentally, the owner/user doesn't need to know anything and the thing just works today, tomorrow and the next day. i don't think i want to write software for people who think software should be this way, but i will concede that if you accept the premise, it has its own compelling internal logic.

My take on this is much more practical. I make software to fill my needs and expected experience. I may be willing (if it's easy) to add features that are not for me. I may add some features like documentation/packaging that are not so easy because it makes it worth while to share the SW. In the end I have a limited amount of time and resources. I am not a FOSS evangelist and am not willing to tythe money I typically don't have to shove FOSS down someone's throat.... or build beautiful toys for yuppies (or whatever they are called these days). BTW, maybe add ubuntu touch to openmoco... -- Len Ovens www.ovenwerks.net

On Tue, 30 Sep 2014, Paul Davis wrote: Yup, certainly. That was not my point though. Yes 1994 or 95 when I started using Linux, computer audio was midi. X was around, but was a toy, I did everything on terminals accessed with c-a-F* key combos. I don't do that any more because I don't have to. I do use a GUI based DAW and am grateful for those who developed it. The point is that I don't get paid for playing with Linux (and when I did it was for a specific outcome), I can only spend so much time on it (and in the case of HW, only so much money... I have a family to feed). I do like open sw and so when I do create something I am willing to share it in the same spirit.... but I am not ready to start a world domination campaign. To put together something like this person was suggesting has been tried and failed because it has to happen quickly. Even closed house with lots of money doesn't always manage "catch the wave" in time. This is part of the reason there is more open SW than HW. SW has a lot less to loose. The HW that is open is a lot more things that can not be bought or where customization is desired and competition is unlikely. Control surfaces, high end preamps, even microphones. Any time hardware is mentioned one of the first responses is that "you can buy one for less than making it". So it has to have some other value for the hobbist to make it. But it is still a value that is personal. Besides, What do I need a smart phone for? The more I play with them the more I long for the old clamshell. Its the same with convergence... everything has a phone interface, but I can't do what I want to do on it... without more work. Sometimes the keyboard is the right input device and sometimes this simple text editor is faster and easier than a gui. -- Len Ovens www.ovenwerks.net

On Tue, September 30, 2014 23:51, Paul Davis wrote: that was not my point but i agree with that view

On Wednesday 01 October 2014 01:04:52 hermann meyer did opine And Gene did reply: I'm one of the weekenders I guess, although my weekends can be anytime since I retired a decade & change back up the log of life. But to facilitate some precision in my woodworking for mortise & tenon joinery, I long ago made up an alu bar that I can bolt to the front of the head casting of my cnc'd (using LinuxCNC of course) micromill to mount a cheap die grinder far enough forward and offset to the left, and some jigs to mount the frame sticks in a vice-like setup, wrote a bit of gcode and carved both the tenon on the end of the stick, and its matching mortise. My last such project, for the next door neighbor, was a set of benches with seat backs that double as storage for toys etc for all ages, only had 172 such joints in it. And no, not a pro, but just making the best use of the tools I have. My interests are best described as eclectic I guess. Keeps me out of the bars, is I believe the usual excuse. :) Point being, use the tool you are familiar with. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Hi all, There's a lot of interesting points brought up: I've only just had the time to read them, and reply to the points that most speak to me (the individual) and me (as OpenAV). Charles Henry wrote: There are various companies working on this type of integration though: there are various HW/SW combo that works with a computer, and integrates very well: sure they're not selling the PC yet: but it won't be long I think. Actually they're probably working on developing that right now :D (example that I worked with http://www.presonus.com/products/StudioLive-16.0.2 ) Charles Henry also wrote: Agreed: with my OpenAV hat on, that's something that I'm thinking about and concidering how I can earn a living somehow by developing open music software. Fons wrote: Agreed, I also feel that doing the thinking for a user of a piece of software is not the right thing: I have no issue with a user having to spend time to learn to use a domain and tool. What I do want to note here, is that said user should not have to learn an unrelated-domain, in order to use the software in the target domain. In my opinion, the learning curve is too steep (or perhaps more accurately too board) for musicians starting to use linux-audio. Louigi Verona wrote: Cool, looking forward to your opinion as a user. Tom wrote: Indeed: and I don't agree with everything in the talk; this is a good example. Tom also wrote: It is easy to have bad/overly-complicated workflow in a piece of software, and call it "professional" to make up for it. That's pretty much exactly why I started this thread: thanks for making it obvious to me :) Paul Davis wrote: In my opinion its about creating software that caters for a workflow, or "use case" if that's a term you prefer. This is about designing software for a particular use-case, and *then* focussing on the experience while using it. The talk mentions "the age of experience", perhaps I interchange the word "workflow" and "experience" sometimes. A smooth workflow provides a good experience. And certain use-cases are catered for very well by certain programs *features*, but the *experience* or *workflow* of using it is not something that I feel is somewhat lacking. Flo wrote: And I understand that there is a need for software to cater for your use case, or preferred workflow too. That's the lower-left quadrant in the talk: "Open Features-driven" tools. Very powerful when in very capable hands. Its users who would prefer a smooth experience that do not have software available to them on linux audio right now. And its designing and building software in that domain that I'm interested in (both as "me", and OpenAV). Cheers, -Harry -- http://openavproductions.com

On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt &lt;mista.tapas(a)gmx.net&gt; wrote: "slaughter" is perhaps a strong term. perhaps a more nuanced description might run something like this (taking a little inspiration from the video): creating and maintaining **consumer** software with a very good user experience is expensive (relative to other tasks that people do) and takes a significant amount of time. therefore the creation and maintainance of this sort of software requires resources that are not clearly available to most open source efforts. the proprietary software that manages to do this is influenced at some level by where its creators and maintainers get their income from, and the development of the "free" model used in particular by google points in a direction where the software must allow/empower/enable behaviour by the software developers that are not in the users' best interest (e.g. selling data about the users).

On Wed, Oct 1, 2014 at 11:01 AM, Louigi Verona &lt;louigi.verona(a)gmail.com&gt; wrote: this isn't universally true. there is a class of user for whom editing the text file is actually the faster, more efficient way to change options, especially if there are a lot of them. whether this group of users is large, and whether it should dominate design models is a separate question. it doesn't have to mean that, but it often does, especially if the program has a lot of options - people get scared of presenting them all and so they hide most of them. consider the case of all the things you can do with sysctl(1) on OS X that are not represented anywhere in the GUI. they *could* be, but they are not, because doing so conflicts with the experience that apple designers wanted people to have. anyone who needs to do "that stuff" is fine with the command line, they apparently reasoned. in general, textual presentations of options and parameters *tend* toward showing the user everything; GUI presentations *tend* towared a more structured display of selected options believed to be the most important. these are not hard rules, just tendencies, but important ones, nevertheless. until you need to use a delay to compensate for a block size delay that you known in samples :) this is a secondary question. until you define what the "things" that are going to get done, you can't begin to ask if or how to help users with those tasks. i think it has a *lot* to do with it. there are a whole bunch of things you can do in a DAW-like tool to reduce the initial confusion and number of things the user has to do and comprehend before they manage their first recording pass or audio import. garageband is a perfect example of how to do this. the cost is that (a) the user learns very little about the underlying concepts of the application (b) you must hide a set of options that would just confuse first time usage but that may be critical one month in (I've watched my son face this curve with garageband, which is partly why he no longer uses it and is on Live instead). This leads naturally to one of two approaches: more workflow specific tools (e.g. Live/Bitwig, Trackers, audio file editors, traditional DAWs, SuperCollider ...) or "gradual reveal" in which the user gets to control how much of the full set of possibilities are accessible/visible at any point in their use of the tool. When you give people an app that does one thing (i'm thinking of android/iOS apps here), these considerations don't apply because the "things to be done" are so easily defined and so limited that it really just a presentation/design issue that doesn't have to sacrifice power for experience. But when you give people an app with the power of (even) audacity (let alone Live or ProTools), there is naturally a learning curve, and it is a critical question how and if the application will try to assist the journey along this curve. First time DAW users are always "dumb", no matter which DAW they sit down in front of. How they get to be less "dumb" is about learning, and the learning is very very dependent on the design and structure and goals of the application.

On Wed, Oct 1, 2014 at 4:40 PM, Fons Adriaensen &lt;fons(a)linuxaudio.org&gt; wrote: point your chrome at: about:config :)

On Wed, October 1, 2014 17:40, Patrick Shirkey wrote: That might be true but UX isn't restricted to visual aspects IMO. Looking at a button to indicate two statuses, is it a pure (visual) design question how large the button is, where it is placed, how it is labeled and how it looks? I think there is a layer between the pure design aspects and the pure functional aspects where the line is blurred. For the button to indicate two statuses, it's inherent that the distinction of the two statuses must work. This is clearly a functional aspect of the (visual) representation, in terms of operating the widget. If the button is too small or placed where it won't be found it's also a functional aspect. The pure visual design aspects come into play *when the above functional aspects of operation driven by visuals are met*. The visual aspects on top of that can be to match a common style ("we use rounded corners for our buttons") *without breaking* the functional aspects (i.e. changing the colors in a way that affects the distinction of statuses). This is also where the individual preferences start whereas independently of that, everyone needs to find, read, hit the button and distinguish its statuses. ___dev focus / __ux/design focus / / | |---What is shown to the user, "make use of" the offered functionality | | --Wording, style/theme, "hidden-factor" of function | | --Documentation | | | |---The functionality embedded to the ecosystem of the program | | --Accessibility, grouping ("..is in the same category as") | | | |---The abstract functionality | | --Fits/amends the core idea, plays well with existing | \ | | ---The concrete implementation | --Algorithm 1 faster than 2 | --Library x | --Already existing (just another parametric call) | : ---The distribution : --Needs special attention to build on y : : ---Other aspects : --Legal, license etc ("can we use lib z?") \ (this is a free-form layering, change/comment it if you like) Please note the the dev has/should have the full picture and shares the top layers with a ux/design person. I make an example using that layer stack. Request: provide a way to add a new track in a multitrack app via keyboard shortcut (no more actions/data entry needed) Check legitimacy of request: is it something new or already existing, how does it differ, does it fit to the core ideas, does it bring additional value, does it break existing concepts etc. Possible outcome: feature exists but it's not done in the most simple way (clicking through menus and dialogues needed) Possible arguments against: it can already be done. We can't know how many channels the user wants in the track thus we can't make a shortcut without data entry. Possible facit: In 98% of cases, the users want's to either add a mono or a stereo track. We provide the shortcut just for these two cases. Layers bottom up: --Other aspects: no change --Distribution: no change --Concrete implementation: already existing (just another parametric call) --Abstract functionality: all conditions met --Functionality embedded to the ecosystem of program: group with existing track ops --What is shown to the user: some minor work here (mainly: documentation) In this case, the UX can be improved for users, without the UI changing except for a menu entry showing the action and keyboard shortcut. All the involved steps can be done "just" by developers. Now one could do that again with the next request: "add a button to add a track immediately" :) where UI/UX person will play a greater role. Regards Tom

On Wed, 1 Oct 2014, Louigi Verona wrote: Yes, To add to the point, Just as the author of the talk is developing a phone, so is ubuntu. I was following the progress for a bit and what stands out to me is that almost all of the people who showed up and wanted to add code were interested in porting the the sw to another device (the one that person has) rather than improving the look, feel, experience or even the functionallity. It seems a part of it is that developing for other people can be pretty thankless. One hears about the problems and dislikes, but even when these grumbles have been addressed or fixed, there is rarely any thanks. This is even more noticable for those users who have switched over from proprietary sw who's attitude is more along the lines of "why haven't you fixed this yet?" to much more abusive language than that. On a community developed project, how the developers "feel" about their work is much more important when they are paid for the same work (even the same people). Just dabbling in development has made me much more understanding and appreciative of the work that others do. I am much more willing to "make do", much more willing to hear "no I am not going to add that". Much more willing to use two (or more) tools to do the same job that might be done with one if designed so. The whole idea of "we can make something beautiful with a wonderful experience and so users will use it and be free" doesn't ring true. An open source project can put a product out like that yes, but as soon as they do it will be copied and even before that, it will not be chosen because it is "free of malwere", but rather because it goes with my feeling this week and next week it is back to some closed device because my friend has one. In the end, "open" devices would have to be made by people just as "cut-throat" as a closed shop. so what is really gained? -- Len Ovens www.ovenwerks.net

bah. bad formatting. try this: http://www.dailymotion.com/embed/video/x26axz5?start=1530

On Wed, 1 Oct 2014 21:40:10 -0700 (PDT) Len Ovens &lt;len(a)ovenwerks.net&gt; wrote: <snip> I found myself nodding all the way through this! Also, it seems that as time goes by a lot of people are using steadily more powerful equipment to actually do less! Whether this is what they want to do or whether it's what the interface *allows* them to do is a moot point. As someone who tries to get the most out of anything I use, I find most commercial software extremely frustrating in the way it strait-jackets users. I think this also blocks curiosity and maybe stops more youngsters joining the creative communities. I think this relates back to the topic as in who's experience should lead the design? -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Thu, Oct 2, 2014 at 5:24 AM, &lt;gordonjcp(a)gjcp.net&gt; wrote: euro-rack modular synthesis is a big growth area for small companies right now. doesn't mean they are in widespread use, but to call them dead is pushing it a bit. a process very similar to the contrast between mixbus and ardour. mixbus represents harrison's accumulated experience about what people do when mixing, ardour represents a totally open-to-whatever approach. interesting that they both use substantively the same codebase, eh? it is all relative - in the US almost nobody drives a manual transmission either. Moog's biggest contribution to analog synthesis, other than the filter, was to add a keyboard. Buchla was ahead of Moog in actual synthesis, but was opposed to the idea that such a capable instrument should be constrained by the limitations of a keyboard. Moog thought that was stupid, and Moog won that argument hands down, even though in some deeper sense, Buchla was correct. UX ... all the way.

On Fri, October 3, 2014 7:51 am, Harry van Haaren wrote: It's probably better that someone other than me does the official announcements. A couple of observations though. If it is monthly we will get through 12 apps a year. That is not going to make much of a dent. Weekly gives people a hard/fast deadline to participate and provides some urgency. Getting the details fed back to LAU provides exposure for the app to a few thousand list members and ensures transparency. It also allows us to monitor which apps are getting feedback. Collating the details at the end of the week and submitting back to the developer is a minor task. We could whip up an official website for storing the feedback once it is collated to use it as SEO copy for guerrilla marketing purposes. There are other options to draw in feedback like giving away prizes: - for the best feedback (as voted by the community) - for people who go out of their way to contribute - for useful patches - etc... Where do we get the prizes? If we allow advertising we might get some funding from companies that are interested in having more exposure. We can also get some decent money from google ads if we can hit approx 10k page view a month. Enough to actually buy a T-shirt, mug, microboard, etc... Sponsorship from a larger company like intel/amd/etc... would also make for some interesting prizes. The Linux Foundation is known to get involved in these kinds of things. The trick is generating real traffic and having the data to prove it. To start with I can put in some funds to the kitty to provide prizes for the first 6 months of operations (E600) and hosting of course on the channellinux.com network. I am also able to commit some developer resources but I think it would be better to have a team/community effort. If other companies want to chip in the E25/week prize budget will be expanded. Dealing with shipping costs is a big financial hit so maybe the prizes shouldn't be physical items. Just giveaway money? We might get a lot of interest from poorer regions of the world if we are giving away E25/week. In some countries that is one weeks salary at minimum wage. -- Patrick Shirkey Boost Hardware Ltd

On Thu, 2 Oct 2014, gordonjcp(a)gjcp.net wrote: Good, I have tried it a number of times (every release I install and try it) and for me it always ends up being more keystrokes to do anything more than use the browser. I know someone who uses the new gnome shell as well for music and loves it. However, I have heard more complaints about both of them than praise. Both require an up to date reasonably powerful machine to run. (My P4 box will not even start gnome screen and unity barely moves, my 3 year old netbook doesn't like either of them either) As such, even something that runs these ok may not be able to do the same lowlatency audio that other DEs can do on the same machine. In trying to help people do so I have seen more people switch than not. Now obviously I won't have tried to help those for whom unity has just worked so my POV is bound to be one sided. There does need to be a balance. However, part of the problem is user mindset, and here I am talking linux hobby mindset. Many people who use linux expect to get away with a lesser machine. The same person will spend twice what their computer is worth for an audio IF. Really, if someone is serious about music, they need to have reasonable gear. But they shouldn't have to have a server class box just so the display can look pretty either. If we were truely worried about cpu cycles we would all be using NAMA as our DAW with no X running. One of the things I heard from one of the videos mentioned was that the UI can influence the music that comes out of it. Limitations in the UI can shape the way the music is made. So here is another place there needs to be balance. I don't know how this relates, but It may be interesting to note that I have tried LMMS and Bitwig both of which are supposed to be very easy to use, but I found them hard to get noise out of at all. Yet I was able to use Ardour and have it act as expected from my first use. So obviously my head does not work the same as the average musician... and as such maybe I should stay as far away from developing anything as I can. I think even the 32 setups on the DX7 were more than needed, yet there are people who have played with them for years who comment they are still learning new things on them. I do not know if two more operators who have helped, but having 6 still seems to be better than 4... though 4 with more than just sine wave in may be a different story. The dx21 only has 8 because it only has 4 operators. This is math related rather than usablity related. I suspect it had something to do with production cost as well. I have a 4 operator synth (even cheaper version than the 21) and I do not like the sound as much as the DX7 (I have one of those too). However the usability angle really shows well here. The DX7 was not at all easy to program and it showed, it was easy to recognize the DX7 in popular music becasue everyone just used the factory defaults... good thing they were reasonable defaults for the DX7 would have been dead as soon as it came out. Having more operator controls may have helped, but the cost would have been a lot more too (the DX1 for example). The manufacturers have learned from this all and most new synths just have presets that eveyone uses. No one creates new sounds on them but rather buys them for the sounds that they come with. In the end it has led to less experimental music, but there are a lot of other factors that pointed that way anyway. The big labels are not interested in music at all, just profit. They hire the same producers who use the same sounds that have worked before... A live drummer may play his own drums, but the producers will remove his sound and replace it with a sampled drum kit in time with what would have been the drumkit. One has to look for experimenting in music or just something different. thanks to Internet people can self release what the record company is not interested in. Some is awful, but there is a lot of really good stuff too. Yes and no. That would be like watching some one play the guitar and deciding we only need the bottom 5 frets because the player never used any bar chords (it would be easy to find a group of 1000 professional musicians who played this way). The tool can define the music as already stated by a few people. Ease of use is not king... otherwise we would use the auto-harp instead of the guitar (there are some people who do amazing things with the auto harp, but there are a lot more that just push the buttons). Adding more UI than the working musician uses is not bad, it means that new styles can be conceived and what is never done now can become normal. See my comment above about different DAWs. The ones I find hard to use are the "Cats meow" for some of the people who have started their DAW experience having never recorded music with all hardware. (there are also some people who are just more adaptable than I am too) I am often amazed at the new ways of making sound on physical instruments, some that have been around for 100s of years. It is easy to make sw more restricting than that. Maybe for the "average working musician" that is ok, it pays the bills and the asier the better. Maybe Linux developers should cater to these people more. On the other hand, maybe tomorrows closed SW will be based on tricks that the experimenter figured out using a more open aproach. FM synthisis was a very hard sell. No one wanted it. Yamaha took it only because one of their people was a tinkerer and messed with it enough to get it in the door. What other ideas are waiting to be used that will only be discovered by someone with tools that are open enough to allow it? SHould Linux target those who only see a comodity? WHo are only looking to have what their "idol" uses? Or who want the cheapest one that works? The stuff already out there will be what gets bought. Developing HW with Linux is like developing with any other OS, it requires innovation and lots of support. The linux HW has to have what nothing else does and the something has to be seen as needed. Lets see how the mod duo does. -- Len Ovens www.ovenwerks.net

On Fri, October 3, 2014 7:22 am, Len Ovens wrote: <snip > SHould Linux target those who only see a comodity? WHo are only looking to > have what their "idol" uses? Or who want the cheapest one that works? The > stuff already out there will be what gets bought. Developing HW with Linux > is like developing with any other OS, it requires innovation and lots of > support. The linux HW has to have what nothing else does and the something > has to be seen as needed. Lets see how the mod duo does. I have asked people who already have similar gear about the mod boxes and while they are interested in the platform they are put off by the price. Until they reach the economies of scale to be price competitive there will be a small market. Especially if trying to sell to the existing Linux peeps who are generally pretty cheap when it comes to actually parting with their own personal cash. Several people have tried to tap the market with expensive hardware and had pretty dismal results. However if we look at the success of the low end DIY market ex arduino, rasp pi, rockchip, allwinner that is a pretty good success story. -- Patrick Shirkey Boost Hardware Ltd

On Fri, 3 Oct 2014, Patrick Shirkey wrote: compare to this for example: http://www.zoom.co.jp/products/ms-100bt $160, but you have to buy new effects... after the first 100 already there. I did notice they do not seem to be looking at the Linux users market, the promo shows the user with an apple product for browsing. The form is enough different than the norm that players will recognize it on the stage if they see someone else using it. It is very hard for me think like the group of people this is/should be aimed at, because I am one of those "cheap" Linux guys. Though of all the kickstarter categories I am most attracted to the "gift a developer" one... even for a gift size bigger than the next two categories. Free and open seem to have almost no meaning/value to those who do not already know what that means and value it. Cheap and effective or over priced and branded are what seems to be attractive to people. I guess what I am trying to say, is that spreading Linux and it's tools is not going to be simply adding a nicer/easy UI. Those things will not hurt and besides will help those already using the SW. -- Len Ovens www.ovenwerks.net

On Thu, October 2, 2014 7:00 pm, Will Godfrey wrote: If "youngsters" are people under the age of, say 25 then, most of them will be blocked from LAD by not having access to a Linux PC. The ones who do will mostly be doing academic study, scientific research or working for governments who have chosen Linux instead of the other options. It's increasingly unlikely they will have Linux Desktop PC's at home. Very few new people are taking the time to install Linux OS's on desktop PC's and the desktop market is in decline for the consumer portion across the board. The majority of the shift to Unix has been for Android, ChromeOS, OSX with firefoxOS and Tizen coming closer to fruition each day. The remaining professional portion of the market which I assume Harry is targeting for a sustainable income is well and truly in the OSX camp. It's going to be hard to pull them away from OSX to this OS. Even with really slick interfaces they generally have a different mindset that defines their reasoning. As I was told once. "it's not about how much money they can save, but how much money they can make..." Linux has seen wide adoption in the embedded audio hardware market but many of the companies that make audio hardware running on Linux systems do not participate directly here. So in terms of usability and this discussion the majority of LAD professionally focused developers are targeting the scientific/academic markets and embedded hardware markets. In that case usability takes second place to raw power and functionality. There is also the web market but I am in a clear minority on the importance of that round here. -- Patrick Shirkey Boost Hardware Ltd

On Thu, October 2, 2014 7:44 pm, Neil C Smith wrote: I've seen those reports too. They are optimistic but potential growth is not the same thing as actually growing. It's more likely to be corporate buyers replacing existing stock. The current situation is the consumer desktop PC market when it comes to audio/multimedia has been decimated by mobile. The Linux Audio Market is currently doing best in embedded hardware. If we want to consider Android as a Linux OS then Linux Audio is doing the best that it has been for years with many companies that have nothing to do with LAD making a business out of their Android applications. The corporate market is still there as a potential battle ground and will probably never go away but getting Linux Audio into the corporate market is a very tough slog. Even at companies where they have massive investments in Linux infrastructure and embedded hardware they are still using OSX for multimedia production and M$ for general purpose administration. It's almost impossible to convince an established Digital Media department that Linux is an appropriate platform for their team members. Firstly there is a massive lack of expertise and training. For example, It is very rare to see a job ad for a multimedia position that uses open source technology. The Blender community is making some headway in the training aspect of the problem but it is slow going. Nearly every "professional" multimedia person working in corporate space uses those other tools and platforms without question. To change that will require getting into the heads of corporate managers so they make decisions based on a different set of goals. It's a tough sell. It will also require students to choose Open Source over proprietary and that is also a hard nut to crack because the proprietary companies offer incentives to the HoD's that open source can't match. Will Linux Desktop professional or consumer multimedia ever become a growth market? I am not convinced that putting additional effort into usability is the key to cracking it. IMO there are other issues that need to be resolved first. Getting a couple more big names in on the game will be useful too. I recall Native-Instruments were on the fence a couple of years back. They needed more convincing at the time. Maybe they have an update about their assessment of the current market? Has anyone here actually tried selling *any* kind of app on the Ubuntu App Store? Does anyone have actual data about the amount of people out there who use LAD tools? the past 4 years I am not seeing significant growth or decline month on month. One could spin it that we have seen overall growth because it is unlikely that a lot of the same people would return to the LAU-Guide on a regular basis. That suggests that there is a reasonable sized potentially untapped market out there of at least 100k. Who are these mysterious people and will they spend any money? If I had tracking tags on the site I might be able to provide more details but I don't. Until someone nails a mega successful app/model with Linux the other companies waiting in the wings will continue to dip their toes. -- Patrick Shirkey Boost Hardware Ltd

On Thu, October 2, 2014 9:14 pm, Neil C Smith wrote: If SteamOS becomes a fully fledged distribution on the scale of Ubuntu/Fedora then it might have an affect on adoption rates for LAD software with the "young" crowd. NVidia is putting a lot of effort into expanding the use of GPU's with CUDA/OpenCL API's so that might also have a positive affect on adoption but only if we build the tools to take advantage of the hardware. FFMPEG developers are doing a great job of keeping things progressing on that front. But LAD'ers could do more to build out tools that leverage GPU's. We could get some more wind in our sails if some well known companies/artists/producers actively promoted their support for Linux OS and encouraged adoption. That has to be a two way street though. For example famous artists usually give endorsements for something in return. -- Patrick Shirkey Boost Hardware Ltd

On 01.10.2014 22:19, Fons Adriaensen wrote: Sounds like a piece of functionality that should be covered once, for all, ideally. As some kind of unit conversion/entry lib/plugin. For every plugin time parameter where any of the provided units make sense, there would be an input field with a default unit for that specific parameter, and a way to switch between samples, ms, s, d:h:m:s, ..., meters at [some] speed, beats at hots-provided bpm. The space required and the shear number of options would infer a cost with no payback for some users, but otherwise could make for a great user experience ;), where: - no distraction is caused by having to do workarounds, even just having to get out the calculator. - the consistency across plugins/apps means the interface can be learned once, with gains in efficiency on repeated use. Another candidate would be frequency/pitch. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/