Re: [Audacity-devel] Assertion failure in WaveTrack::AppendAlias( )
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Shane M. <smu...@um...> - 2002-05-06 20:35:22
|
Ben, Here's a few comments/questions/replies regarding the things I know about: > Also the volume control has what I call the Queen Boadicea > problem. You signal it to go right, and it moves to the > left. Could you describe with a little more detail what you mean by this? Which version of Audacity are you using (the volume control in 0.98 is different from the one in 1.1). I'm not sure if I'm seeing this behavior or not. >All the controls flash too much as they are drawn, and If you mean that when the project window is resized, the controls flash a lot, this is something I have noticed as well. This may be a fundamental problem with the wxwindows not using double-buffering or something like that. I'm not sure if there is a way to make this better within the audacity code itself. Does anybody else know? > I found it a problem that the quiescent (but enabled) transport > buttons were not coloured. I'm not sure what you mean transport buttons. Do you mean the '|<<' and '>>|' buttons? At least in version 1.1, enabled buttons should be colored and disabled buttons should be greyed out. If this isn't true, the version you are using has a bug that I am unaware of. At the very least the record button > should be red (but should also be labelled as colour is > insufficient HCI), The record button is red in all the versions I know about, so maybe your version is buggy for some reason. I actually don't like the fact that it looks so much like a stop sign, but this reflects the use of firmly-established iconography from electronic component manufacturers, so there is little I can do about it. I agree that text-based controls can be easier to use than icon and color-based controls (the 'Stroop' effect is an excellent demonstration of why this is true. For those not familiar with this, try it out at <http://faculty.washington.edu/chudler/java/ready.html>. Actually, to get a really powerful understanding, run through each test twice, one time reading the names, the other time naming the colors). The problem with using text labels is that they are very translation-unfriendly. For better or worse, the toolbar buttons are graphical, and it is a practical nightmare to develop a new set of graphics for each new language. In the development branch, tooltips and a statusbar messages are enabled which provide text descriptions of what each button does, which is a reasonable compromise. I guess if it could be shown that naive users have a difficult time understanding how to operate the controls, that may be cause to modify the button design to allow text labels. However, my impression is that most of these users have an easy time figuring out how the controls work. >and arguably should be adjacent to the Play button. I hadn't thought about this before, and was not responsible for these buttons placements, but in my opinion the current play/stop/record order is ok. The stop button is used only after hitting either the record or the play buttons, so sandwiching it between them makes naive sense. On the other hand, most tape recorders use the order record/play/stop, but the physical interface and mechanical components is what makes this the best solution. But, as long as we're borrowing from electronic devices, this order may make sense as well. It really is an empirical question which layout is best, and we could do some user testing to determine what button layout is easiest to use. We would just need to add some logging functionality to the buttons, and come up with some test cases and instructions. There are a ton of users out there that would be glad to help in some way, and they may be willing to help by running through test-cases and sending us their data back. Anyone interested in spearheading this? Thanks for your comments. Stm... |