Re: [LAD] GuitarSynth
On Sat, Apr 25, 2015 at 5:13 AM, Tim E. Real termt...@rogers.com wrote: If it provides inspiration, I was doing this in the late 90's on Windows, in good ol' Borland C++ Builder. If you still have the code lying around somewhere, why not throw it up on github so that others can learn from it? Question: I tried a demo product which did polyphony, with similar latency as my app, which claimed to have a full version with near-zero latency. Is this actually possible? Sounds like snake oil to me, but don't take my word for it. Albert -- Dr. Albert Graf Computer Music Research Group, JGU Mainz, Germany Email: aggr...@gmail.com WWW:https://plus.google.com/+AlbertGraef ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, 25 Apr 2015 08:50:21 +0100, Will Godfrey wrote: One of my pet hates is erratic implementation of tooltips... that can't be disabled! Tooltips showing the value instead of a description of the option IMO are good. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Fri, 24 Apr 2015 23:55:31 -0400, Tim E. Real wrote: My centre-screen technique is in fact limited to half-screen The real desk might be limited to, e.g. a mini mouse pad on a synth, so the mouse wheel option could be very important to avoid huge mouse movements. It's not only the screen that is a limitation, the desk/mouse pad could be very, very small. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, 25 Apr 2015 10:23:14 +0200, Thorsten Wilms wrote: https://afaikblog.files.wordpress.com/2013/01/date-and-time.png We already know a solution since decades. Checkboxes +1 I see that on my iPad every day and never become used to it, there's always doubt. I've never noticed such a bad thing by the Linux desktop PC apps I'm using. Reminds me of consumer hifi gear were sometimes inputs are outputs and outputs are inputs. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, Apr 25, 2015 at 11:01:54AM +0100, Will Godfrey wrote: Tooltips showing the value instead of a description of the option IMO are good. Debatable. If I'm twiddling knobs to get a particular 'sound' I'm not at all interested in what the numbers are. At a later date I might want to make a note of them, but if I can save the settings anyway, even that is moot. Musicians and sound engineers will have a different view on that. When I'm mixing, I *want* to know the values of e.g. equaliser parameters, for two reasons. First to be sure I'm not doing anything insane. Second, because that way I will learn the relation between the values and the resulting sound, and be able to do the same on different HW or SW without having to search blindly by twiddling the knobs. It's somewhat strange that musicians expect a sound engineer to have this sort of competence and complain if he/she takes too much time to find the right settings, but don't want to learn any of it themselves. Not even the wannabe sound engineers among them. Some time ago I was editing a long radio documentary. At some point we had to fix a badly recorded interview, so I launched an EQ/filter. On seeing the UI (knobs only), the director (an OSX user) said 'oh god, that's Linux, no graphical display or spectrum analyser, how are we going to adjust that thing'. I ignored his remark, set the EQ to what I knew was needed, and only then activated it. The result was right on spot. At that point I just said 'real sound engineers don't need toys'. He refrained from making more silly remarks for the rest of the production. Probably remembered that he came to me because he wasn't able to get things right himself. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 24.04.2015 23:40, Fons Adriaensen wrote: Consider a button that toggles between 'stop' and 'play'. Does it show the current state of the player, or the one you get when you click on it ? Yes, a classic. It's the general problem that using any toggle-action successfully requires the user to be aware of the current state. That might sound like a non-issue seen in isolation, but if a user has to deal with lots of such states over a long period of time, mistakes will happen. At the very least frustrating double and triple triggering. The reason to use one toggle button over 2 action buttons is saving space. Likewise, one shortcut over 2 shortcuts. A DAW can get away with Play/Pause toggling, but less often changed states that affect other actions are more troublesome as toggle. I mean to recall that Rhino3D has buttons that will always enable / keep enabled something on left click and will always disable / keep disabled on right click. Regarding ambiguous icons on toggle buttons that might display either state or action: If you can't avoid them, didn't find icons that imply action or state, the last line of defense is convention. Always state or always action. Similar situation with 'slider switches' which show 'on' or 'off' on the flat part. If you have no other feedback, the state of the button or slider gives you a very ambiguous hint at best. The blind copying of Apple's sliding switches is one of the saddest things to happen in recent GUI design. I for one can't take anyone serious who thinks this is acceptable: https://afaikblog.files.wordpress.com/2013/01/date-and-time.png If one wanted to infer a guideline from that screenshot, it could be: Make sure there is a huge gap between labels and associated widgets. This slows the user down to avoid stress and gives his eyeballs a nice workout. We already know a solution since decades. Checkboxes with their identifying graphics on the left side. Taking touch into account should not mess up pointer-based use. If you can't make sure of that, maybe a hybrid is a bad idea? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Fri, 24 Apr 2015 20:33:05 -0700 (PDT), Len Ovens wrote: another idea for a touch screen: 1 touch control with finger one. 2 put finger two some distance away. 3 move finger two towards control to decrease value or farther away to increase value. 4 lift both fingers. I am not sure if lift order would matter. (it shouldn't) I do not know how long it would take to learn this so it was natural to use. Hi Len, it conflicts with gestures, if you by accident don't touch the control and you do the two finger pinch, something unpleasant could happen. IMO 1 touch the control, it gets a colour that signals that it's activated 2 put a finger some distance away 3 move towards control to decrease value or farther away to increase value 4 touch the control again, to deactivate it, colour becomes normal Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On 25.04.2015 09:50, Will Godfrey wrote: One of my pet hates is erratic implementation of tooltips... that can't be disabled! I'm not sure where I saw it ... an interesting alternative is to have a status line in a static location. It can be used for tooltip text, parameter values and perhaps a few messages. A drawback is of course the distance between the line and whatever the pointer is hovering. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Fri, 24 Apr 2015 22:18:57 -0400, Tim E. Real wrote: What do you think? Hi Tim, if the mouse courser reaches a screen border, the mouse movement should continue to increase/decrease the fader/knob value, but the mouse cursor should stay at the boarder, without movement, close to the knob/fader. Repositioning it, far a way from the area were we are working isn't good. There's no need to see a moving mouse cursor, since the fader/knob is moving. 2 Cents, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
One of my pet hates is erratic implementation of tooltips... that can't be disabled! Either provide them for *every* control or not at all, and *please* provide a way to disable them. Ideally there should be a way to enable/disable them from every part of your application, so that an experienced user has them off (and out of the way) but on using an obscure feature can briefly re-enable them. -- 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
Tim E. Real: 6: Now turn the mouse pointer back on. Done. Ehm, missed on of the best parts: 6: Now return the mouse pointer to where it was when originally clicked. 7: Now turn the mouse pointer back on. Done. Sounds like the perfect way to do it, and Radium works exactly the same way: http://folk.uio.no/ksvalast/radiummouse.webm (that's a 60fps video. Firefox doesn't seem to display 60fps videos correctly. Chrome does though) :-) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, 25 Apr 2015 10:53:07 +, Fons Adriaensen wrote: Second, because that way I will learn the relation between the values and the resulting sound, and be able to do the same on different HW or SW without having to search blindly by twiddling the knobs. Couldn't say better. As I pointed out by my synth attack sync example: it can help to at least get coarse results very quickly This is much more true for good EQs. Sometimes I need to search a culprit using a narrow bandwidth [1] using a parametric's EQ Q and checking different frequencies, but at least a coarse mix can be done without listening. [1] Allow me to misuse this word ;). http://www.sengpielaudio.com/calculator-bandwidth.htm It's not needed to know such things, if you get a feeling for it by practise. Regarding the toy GUIs that show a graph. I'm not against graphs, but they aren't (always) useful and I don't had them over several decades when using analog mixing consoles. Regards, Ralf PS: IMO tablet PCs should be excluded from a discussion about Linux audio, that usually doesn't run on tablet PCs. Touch screens have other pitfalls. http://www.xewton.com/musicstudio/forum/viewtopic.php?f=3t=2524 JFTR I'm Unknown Crewman. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Saturday 25 April 2015 03:50:21 Will Godfrey wrote: One of my pet hates is erratic implementation of tooltips... that can't be disabled! +10 Either provide them for *every* control or not at all, and *please* provide a way to disable them. +100 Ideally there should be a way to enable/disable them from every part of your application, so that an experienced user has them off (and out of the way) but on using an obscure feature can briefly re-enable them. And, whoever thought it was a good idea, gets 10 lashes for doing the 10 second time out when the thing is stting on the next damned button you need. Damit folks, if you have to have it, kill the SOB when the mouse moves the next pixel! Let us get on with our work. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
On Sat, 25 Apr 2015, Thorsten Wilms wrote: I for one can't take anyone serious who thinks this is acceptable: https://afaikblog.files.wordpress.com/2013/01/date-and-time.png If one wanted to infer a guideline from that screenshot, it could be: Make sure there is a huge gap between labels and associated widgets. This slows the user down to avoid stress and gives his eyeballs a nice workout. We already know a solution since decades. Checkboxes with Also make the colour theming such that the widget is effectively invisible in one of it's states. This more helpful when using the device in bright sunlight of course. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
