Re: [linux-audio-dev] what's wrong with glame
hmm.. how do i unsubscribe heh? like.. thanks
Re: [linux-audio-dev] what's wrong with glame
unsubscribe
Re: [linux-audio-dev] what's wrong with glame
On Fri, Jul 27, 2001 at 08:56:08PM +0100, Iain Sandoe wrote: > Yo Steve ... it *is* hot isn't it? Yes, I actually felt ill yesterday. Which is funny, because I've been trecking in both the Sinai and Sahara, and felt fine, but a 2 mile walk to the docks in southampton... no way. > but ... that's my point - have you tried the alternative? > with you can use your thumb on the modifier - which keeps the hand > in a closed position - much less OOS/RSI. Yes, I have used apps which enfore Alt, but on my favourite keyboard (cherry clicky) in order to press alt+x,c,v with my left hand I have to curl my thumb right under my second finger. Painful. > > Spot the vi user. ;) > > we all have that affliction from time to time ;-)) Now, now, lets not get political. I don't take the p**s out of your one button mice. [lie] ;) > I suppose you could then supply sets of "M$-like, MacOS-like, LAD-like" pref > files to give people a "leg up". > > Maybe in an anarchy that's the only practical way. > > I wonder if we could get global agreement to use a fixed place for LAD prefs > (and to *use* them) between app writers. Maybe globally defined interface style? I will generally go for vi style, few chords, crypic keypresses style over, chord heavy or mouse heavy operation. Gnome and KDE people have standard location for config files, so it can't be that hard ;), but it does raise the question about about where a gnome audio app stores its prefs. - Steve
Re: [linux-audio-dev] what's wrong with glame
> so why don't we use the key as the copy/cut/paste modifier? What's wrong with C-w, M-w and C-y? ;-). ccb -- Charles C. Bennett, Jr. VA LiNUX Systems Systems Engineer, Northeast US 25 Burlington Mall Rd., Suite 300 +1 617 543-6513 Burlington, MA 01803-4145 [EMAIL PROTECTED] www.valinux.com
Re: [linux-audio-dev] what's wrong with glame
Yo Steve ... it *is* hot isn't it?
On Fri, Jul 27, 2001, Steve Harris wrote:
> On Fri, Jul 27, 2001 at 07:29:00PM +0100, Iain Sandoe wrote:
>> Why don't I like the -{x,c,v} keys on Linux & M$ - is it because they
>> are 'different' from the -{x,c,v} on MacOS?
>>
>> Nope. It's because the key (placed where the key is on a PC
>> keyboard) is less of a stretch for one-handed operation.
>>
>> If I do lots of cut-and-paste (or repeated paste) on Linux or M$ I get
>> severe hand/wrist ache ... which I *don't* get on MacOS...
>>
>> so why don't we use the key as the copy/cut/paste modifier?
>
> I find it much easier to use ctrl, I can hold it down with my little
> finger whilst pressing the appropriate key.
but ... that's my point - have you tried the alternative?
with you can use your thumb on the modifier - which keeps the hand
in a closed position - much less OOS/RSI.
> Spot the vi user. ;)
we all have that affliction from time to time ;-))
> User pref?
yeah, I guess, that's the opposite route to a system HIG - make every app
customisable so that the user can define their own "HIG".
I suppose you could then supply sets of "M$-like, MacOS-like, LAD-like" pref
files to give people a "leg up".
Maybe in an anarchy that's the only practical way.
I wonder if we could get global agreement to use a fixed place for LAD prefs
(and to *use* them) between app writers.
ciao,
iain.
Re: [linux-audio-dev] what's wrong with glame
Patrick Shirkey wrote: > > Taybin wrote: > > >But that menu would be rearranging, so it would be slower to use it. Now, > >I would suggest connecting the redo, or some "do again" command to the > >last action taken. The user always knows what he did, and always knows > >where the "do again" command is located. This would be most helpful if > >the previous command was buried in submenus. > > But then if I shutdown the app I loose that usability. Also if I use an > obscure command that becomes the default. Thats a design issue. True, undo-redo lists are generally discarded when a session is closed, but there is no reason in principle why a command history cannot be saved with a session - perhaps like a CVS/RCS system. You might have a menu command "Save Suspended", which retains the undo-redo list. Or a dialog pops up asking if you want to keep the list, or If you use an obscure command, it should merely get promoted to the default display; the vertical ordering of items in a menu shouldn't change. > Maybe this argument is better for the gtk List. It is really just an > aside. Why should we concern ourselves with making the menu run more > efficiently? We aren't, as such (well, I'm not, anyway :-) ); the issue is of transparency of functionality (aka intuitiveness?), and overall efficiency for the user, where the metric is minimum user actions for the most often used tasks. Menu compaction is merely one aspect. It is easier to access a menu item in a list of six, than in a list of twenty, even if you know where on the screen it will be. It is quicker to access menu item close to the previous menu item, than to ones half-way down the screen. I read one HCI study (sorry, can't remember where now - it was in a bookshop) which reported how a user orbits a menu item with the mouse, sometimes scanning a menu several times even though the item is visible and they know where it is; they don't always go straight there as you might assume. This is because using a mouse is not so far removed from playing a muscial instrument, or knitting - you want to get into a rhythm with your movements. Get the rhythm wrong, or try to work just a tad too fast, and click the wrong item And in case you think this is fanciful, I saw a lot of demonstrations using music software, at a recent conference, and I saw just this behaviour, with due variation in style, most of the time! Richard Dobson > -- > Patrick Shirkey - Manager Boost Hardware. > Importing Korean Computer Products to New Zealand. > Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy. -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] what's wrong with glame
On Fri, Jul 27, 2001 at 07:29:00PM +0100, Iain Sandoe wrote:
> Why don't I like the -{x,c,v} keys on Linux & M$ - is it because they
> are 'different' from the -{x,c,v} on MacOS?
>
> Nope. It's because the key (placed where the key is on a PC
> keyboard) is less of a stretch for one-handed operation.
>
> If I do lots of cut-and-paste (or repeated paste) on Linux or M$ I get
> severe hand/wrist ache ... which I *don't* get on MacOS...
>
> so why don't we use the key as the copy/cut/paste modifier?
I find it much easier to use ctrl, I can hold it down with my little
finger whilst pressing the appropriate key.
Spot the vi user. ;)
User pref?
- Steve
Re: [linux-audio-dev] what's wrong with glame
On Fri, Jul 27, 2001, Steve Harris wrote:
> On Fri, Jul 27, 2001 at 02:08:12PM +0100, Iain Sandoe wrote:
>> order. [Iain rates the probability approx. = 0.5 * sqrt(bugger all) ]
>
> Possibly a bit of a high estimate ;)
>
>> an Audio HIG?
>
> I would be nice, but even getting people to agree on simple things, is
> hard in the UNIX world. eg. what the buttons do, obviously its:
>
> left: select
> middle: move
> right: menu
>
> and anyone who says otherwise is just wrong ;)
but seriously folks ...
Yes, this is a hobby... but a lot of us do these things 'properly' for a
day-job - so why not in the evening?
Ergonomics is important to the end-user e.g.
Why don't I like the -{x,c,v} keys on Linux & M$ - is it because they
are 'different' from the -{x,c,v} on MacOS?
Nope. It's because the key (placed where the key is on a PC
keyboard) is less of a stretch for one-handed operation.
If I do lots of cut-and-paste (or repeated paste) on Linux or M$ I get
severe hand/wrist ache ... which I *don't* get on MacOS...
so why don't we use the key as the copy/cut/paste modifier?
Iain.
Re: [linux-audio-dev] what's wrong with glame
Taybin wrote: >But that menu would be rearranging, so it would be slower to use it. Now, >I would suggest connecting the redo, or some "do again" command to the >last action taken. The user always knows what he did, and always knows >where the "do again" command is located. This would be most helpful if >the previous command was buried in submenus. But then if I shutdown the app I loose that usability. Also if I use an obscure command that becomes the default. Maybe this argument is better for the gtk List. It is really just an aside. Why should we concern ourselves with making the menu run more efficiently? The only reason I can think of is to combat the spread of OOS(Occupational Overuse Syndrome) or, for the oldies, RSI (Repetitive Strain Injury). -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Products to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] what's wrong with glame
- Original Message - From: "Taybin Rutkin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, 27 July 2001 10:51 Subject: Re: [linux-audio-dev] what's wrong with glame > On Fri, 27 Jul 2001, Patrick Shirkey wrote: > > > On Thu, 26 Jul 2001, Taybin Rutkin wrote: > > > > > > I believe that studies have been done with dynamic menus. They found that > > > it was confusing to have the menus rearrange. Humans get used to looking > > > for the same thing in one place, and if the place changes and we have to > > > look for it, it is an annoying slowdown. > > > > > > > Don't rearrange the existing menu just have a "best of menu" in the > > menu. > 'best of menu' or a 'dynamic learning menu' *is a [constant] rearrangement* in the sense of cognition - as a menu is at best a reliable form of transport. get a working system up based on exisiting successful menus's in projects of a similar scale - the effort of innovation can be spent in better places !! a mnemonic menu need only carry a five 'recent files / applications' for instance. 'learning menu's' are useful up until the point they become reliant on monkish consistencies. when the needs of the studio change they become stubborn. the principle of the 'shortest route' can be invested in where the design of menu's is concerned because it recognises that menus should be as transparent as possible [where 'opacity' might be the friction of hampered interaction]. this is all very idealistic of course ; ) de|
Re: [linux-audio-dev] what's wrong with glame
On Fri, Jul 27, 2001 at 02:08:12PM +0100, Iain Sandoe wrote: > order. [Iain rates the probability approx. = 0.5 * sqrt(bugger all) ] Possibly a bit of a high estimate ;) > an Audio HIG? I would be nice, but even getting people to agree on simple things, is hard in the UNIX world. eg. what the buttons do, obviously its: left: select middle: move right: menu and anyone who says otherwise is just wrong ;) - Steve
Re: [linux-audio-dev] what's wrong with glame
Richard Dobson wrote: >[lots of reasonable stuff snipped...] > 'Intuitive' is a wonderfully useless (and much abused) (non-)technical > term, as it invariably means different things to different people, > because, strangely enough, people learn to wotk (and think) in different > ways. Nothing is intuitive, until you have learned it! Any of you tried > learning a musical instrument to conservatoire level recently? How long > did it take you? But these instruments are very intuitive to play, when > you have mastered them. this is quite right, of course, (and I'm one of those that finds Macs intuitive - always to be surprised when 'doze-trained people have trouble using it ;-) I suspect that the real answer lies in having a "HIG" (Human Interface Guideline) that is followed by the vast majority, if not all, of app writers. The reason that this results in what people call "intuitive" is that the apps behave in the same way, the same keys do commonly used functions etc. etc. This idea is prevalent on Mac (first) and these days also 'doze - the reason one man's "intuition" is another man's "drop from great height" - is, I suspect, that these learned keys, policies & so on are different. --- Now, of course, in an anarchy, getting agreement about a HIG seems a tall order. [Iain rates the probability approx. = 0.5 * sqrt(bugger all) ] What about it LAD? an Audio HIG? at least then all these apps we have will work together in a (linux-learned) "intuitive" way. I still feel that "complexity of interface" is not the same as "richness of capability" and, as an app writer am painfully aware that designing good UIs is actually harder that fancy DSP (in many cases). ciao, Iain.
Re: [linux-audio-dev] what's wrong with glame
On Fri, 27 Jul 2001, Patrick Shirkey wrote: > On Thu, 26 Jul 2001, Taybin Rutkin wrote: > > > > I believe that studies have been done with dynamic menus. They found that > > it was confusing to have the menus rearrange. Humans get used to looking > > for the same thing in one place, and if the place changes and we have to > > look for it, it is an annoying slowdown. > > > > Don't rearrange the existing menu just have a "best of menu" in the > menu. But that menu would be rearranging, so it would be slower to use it. Now, I would suggest connecting the redo, or some "do again" command to the last action taken. The user always knows what he did, and always knows where the "do again" command is located. This would be most helpful if the previous command was buried in submenus. Taybin
RE: [linux-audio-dev] what's wrong with glame
On Thu, 26 Jul 2001, Richard C. Burnett wrote: > The next best alternative is code that statistacally keeps track of how > often commands etc are used, then its sent back so people can see what the > most frequent operations are and how they distribute between different > users. Seems uncomfortably close to spyware. I'd be happy just as long as they were group together by function and there was a help file explaining the obscure ones. Taybin
Re: [linux-audio-dev] what's wrong with glame
Well, nobody can ever win these arguments; I find the new Start menu system very convenient and intuitive, as I do indeed use 15% of my installed programs 99% of the time. Win2k Startmenu doesn't move menu items to different places (though it enables you to do that if you want), it just hides rarely used items. 'Intuitive' is a wonderfully useless (and much abused) (non-)technical term, as it invariably means different things to different people, because, strangely enough, people learn to wotk (and think) in different ways. Nothing is intuitive, until you have learned it! Any of you tried learning a musical instrument to conservatoire level recently? How long did it take you? But these instruments are very intuitive to play, when you have mastered them. There simply is ~no~ single 'right' way to design things, and in the end people do learn to use one tool in depth, and working with it does become transparent, unless the design is totally flawed. You may feel that Win2k does come into this category, but I don't (actually, I think it is political posturing much of the time!), and that is as much as I can say about it, really. Whereas I find a lot of Linux (especially the new Gnome/KDE interface) anything but intuitive, and in general, unless you were born thinking of shell scripts, I would say that very little of Linux is intuitive at all. But you get used to it, like using an italic fountian pen after years of using a biro, and forget there is an interface between you and the task you are doing, witness the amazing things a skilled user can do with emacs. This clearly works for Mac users, who make exuberant claims about how intuitive and easy to use it is, whereas never do I come so close to dropping the machine from a great height as I do any time I try to use a Mac. And I feel that the new KDE itself has tried to add too many stupid added-value enhancements that I could well do without, c.f. the example I described in a previous post. Richard Dobson Kevin Hremeviuc wrote: > > Hi all, > > --- Steve Harris <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 27, 2001 at 04:54:09AM +0900, Patrick > > Shirkey wrote: > > > Richard Dobson said: > > > > > > >and, wherever possible, ensure that the most > > frequently performed tasks > > > >(which may be the most argued-over parameter, of > > course) require the > > > >least number of steps. A sub-menu requires at > > least four, possibly five > > > >steps: > > > > > > How difficult would it be to add a statistical > > analysis function to the > > > program which tracks the most used menu items and > > organises them into a > > > seperate menu specifically for the most used > > items? > > > > Nnnno! > > > > That way lies madness. Have you used win2k? I find > > it really anoying. > > I agree totally!!! W2K and the Microsoft philosophy of > trying to do as many stupid values adds, to justify > there ridiculous price tag ( given the volume sold ) > are incredibly annoying. > > User interfaces need to be intuitive. For linux > applications it is better to satisfy the 90 > percentile. Bells and whistles should be left to > professional software companies in competitive markets > where the price tag and the functional inanity reach > mind boggling levels. > > What is needed is good robust applications that offer > sensible functionality with intuitive user interfaces. > > > > > - Steve > > > Do You Yahoo!? > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk > or your free @yahoo.ie address at http://mail.yahoo.ie -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] what's wrong with glame
> User interfaces need to be intuitive. #1 priority - preferably with: the main (if not all) tasks right in front of you. well-designed icons that lead you to the task directly. > For linux > applications it is better to satisfy the 90 > percentile. Bells and whistles should be left to > professional software companies in competitive markets > where the price tag and the functional inanity reach > mind boggling levels. not sure that functionality and intuition are mutually exclusive - but, better have two apps linked together if you can't make one that does it all without confusing the User. errm... a bit like ... "doing one thing well" ? > What is needed is good robust applications that offer > sensible functionality with intuitive user interfaces. HEAR! HEAR! let's return to the days where (at least on one platform) you can do the job without wading through fifteen layers of hierarchical menus - or resorting to the manual - which as we all know is the "last resort for any engineer". this all IMHO, of course... Iain.
Re: [linux-audio-dev] what's wrong with glame
Hi all, --- Steve Harris <[EMAIL PROTECTED]> wrote: > On Fri, Jul 27, 2001 at 04:54:09AM +0900, Patrick > Shirkey wrote: > > Richard Dobson said: > > > > >and, wherever possible, ensure that the most > frequently performed tasks > > >(which may be the most argued-over parameter, of > course) require the > > >least number of steps. A sub-menu requires at > least four, possibly five > > >steps: > > > > How difficult would it be to add a statistical > analysis function to the > > program which tracks the most used menu items and > organises them into a > > seperate menu specifically for the most used > items? > > Nnnno! > > That way lies madness. Have you used win2k? I find > it really anoying. I agree totally!!! W2K and the Microsoft philosophy of trying to do as many stupid values adds, to justify there ridiculous price tag ( given the volume sold ) are incredibly annoying. User interfaces need to be intuitive. For linux applications it is better to satisfy the 90 percentile. Bells and whistles should be left to professional software companies in competitive markets where the price tag and the functional inanity reach mind boggling levels. What is needed is good robust applications that offer sensible functionality with intuitive user interfaces. > > - Steve Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
Re: [linux-audio-dev] what's wrong with glame
On Fri, Jul 27, 2001 at 04:54:09AM +0900, Patrick Shirkey wrote: > Richard Dobson said: > > >and, wherever possible, ensure that the most frequently performed tasks > >(which may be the most argued-over parameter, of course) require the > >least number of steps. A sub-menu requires at least four, possibly five > >steps: > > How difficult would it be to add a statistical analysis function to the > program which tracks the most used menu items and organises them into a > seperate menu specifically for the most used items? Nnnno! That way lies madness. Have you used win2k? I find it really anoying. - Steve
Re: [linux-audio-dev] what's wrong with glame
On Thu, 26 Jul 2001, Taybin Rutkin wrote: > > I believe that studies have been done with dynamic menus. They found that > it was confusing to have the menus rearrange. Humans get used to looking > for the same thing in one place, and if the place changes and we have to > look for it, it is an annoying slowdown. > Don't rearrange the existing menu just have a "best of menu" in the menu. -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] what's wrong with glame
- Original Message - From: "Richard Dobson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, 27 July 2001 2:42 Subject: Re: [linux-audio-dev] what's wrong with glame > (bearing in mind I haven't installed, much less used, GLAME, or > anything, yet...) > > Alexander Ehlert wrote: > > > > > Yeah, hmm, that's just naming. We could add something called open in the > > menu which creates a group with the wavfile in it. But, importing it makes > > sense because we convert everything to float internally to allow for high > > quality dsp. So you have to import and export it. But that's not really > > an issue compared to open/close, it's just getting used to it. Ok, I have > > to admit that the file importing(opening) gui is rather bad. But I wasn't > > motivated yet to change that. > > I think this is a semantic misunderstanding. > > All the ~multi-track~ programs I have had experience of (Cubase, Cool > Edit Pro, and most recently, cakewalk SONAR) use the semantic 'Import', > for a simple reason - in a multi-track project, you have N tracks, and > any soundfile must be 'imported' to one of these (You may indeed need to > select a track before 'Import' becomes active). Cool Edit Pro has a nice > feature in that if you right-click in a track, the File menu appears > with Import, and the file is inserted at the cursor point. In a plain > stereo wave-editor, there is by definition only one track, so 'Import' > is unnecessary, and 'Open' is more idiomatic. 'import' is perfect for the multracker, because it means 'adding to the existing session'. however in the the editor it is less appropriate- which is why in all the above applications 'open' to reach audio data for editing. Glame may not need to use 'import' because it is [atm] primarily an editor. Open is also used in the Multitrack window of CEPro to open a 'session' file, the same applies elsewhere. but you're right, it is semantic - though semantic differences also mark intuititve differences - i see this alot when teaching new tools to students. > > At least in Windows and the Mac, the File->Open command is always > understood to relate to the main file associated with the project (the > file you might double-click on from Windows Explorer); this would for > most users be a Session, Project, name-it-what-you-will. Double-clicking > on a soundfile name would be expected to play it using the default > player. However, at least under Windows, you can change a file > association so that selecting a soundfile opens it in your preferred > application (assuming it can accept the file in that way). This merely > requires a 'multi-document' capability where the command-line passed to > the program can contain the name of either a Project or a SoundFile (or > a MIDI file, or...), and either can be opened. > > SONAR cannot do this (for the above reason - where would it go?), but > Cool Edit Pro can, possibly uniquely, because it implements two parallel > modes - multi-track project, and single-track editor mode. > > > Interpreting 'Import' as format conversion is, IMO, a typical > programmer's tinted spin on how the user thinks, or, rather, doesn't > want to have to think. After all, you don't 'Import' a Word document > into a word processor because it happens to be converted to Unicode,say, > internally. The user, generally, couldn't care less about internal > representation. They will only want to know that the highest audio > quality is maintained internally (however that's done - 32bit ints? > doubles? quads?), and they will sometimes want to 'Save As' a different > format, or explicitly do a Format Conversion as some programs require > you to do - which even I find a complete pain in the A. > > > Designing User Interfaces is a real challenge, not merely from an > implementation point of view (all those debates about libraries!), but > literally from a design, i.e. HCI, point of view. Certain procedures > become de-facto standard, and a developer takes a great risk in changing > this; on the other hand if the change very clearly leads to an increase > in intuitiveness and efficiency for the user, they will generally accept > it after a moment to re-orient. Nevertheless, there is a simple HCI > measure of efficiency for the user, which is to find the number of > discrete steps the user must perform to achive any specific operation, > and, wherever possible, ensure that the most frequently performed tasks > (which may be the most argued-over parameter, of course) require the > least number
RE: [linux-audio-dev] what's wrong with glame
The next best alternative is code that statistacally keeps track of how often commands etc are used, then its sent back so people can see what the most frequent operations are and how they distribute between different users. Just an idea, Rick On Thu, 26 Jul 2001, Taybin Rutkin wrote: > On Thu, 26 Jul 2001, STEFFL, ERIK *Internet* (SBCSI) wrote: > > > yes! instead of rigid menus or menus with last N open files etc. there > > should be a menu re-arranging functionality that changes parts of the menu > > so that the most often used functions are easy to access. For one-prupose > > I believe that studies have been done with dynamic menus. They found that > it was confusing to have the menus rearrange. Humans get used to looking > for the same thing in one place, and if the place changes and we have to > look for it, it is an annoying slowdown. > > Taybin > > ++---+ | T a l i t y | +--+ | ++ ++-+| | | Richard Burnett |+-+| | | Senior Design Engineer +---+ ++ | | [EMAIL PROTECTED] | | | | | | | | Phone: 919.380.3014 | | | Fax: 919.380.3903 | | | ++
Re: [linux-audio-dev] what's wrong with glame
>> who said a shallow learning curve was a goal? > In a word - users! I don't think this is realistic for professional media tools. If it were, there wouldn't be complete course tracks in commercial art school for learning how to use commercial software packages -- Maya, Photoshop, etc. These folks are getting trained to spend 40-60 hours a week in front of monitors, with the goal of being maximally productive. A semester spent learning how to use the tool is a good tradeoff. And in fact, I just noticed that SFSU (San Francisco State University, which specializes in media education here in the Bay Area), teaches courses like this for Pro Tools now too. If I had a spare $1600 lying around, I'd take it to see if it was really worth a Grammy :-). - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] what's wrong with glame
Inveterate Windows-avoiders may not know this, but Win2k does this for the applications on the Start menu. This can carry a potentially huge number of applications (I've seen examples where the full top-level menu filled two columns); Windows gradually learns what the most-used programs are, and presents a condensed menu with just those visible (there is of course an arrow item to open up the full menu). It's a, um, start - submenus are still submenus, and ~eventually~ the adept user discovers there are ways of rearranging everything. But unless it occurs to you that it might be reconfigurable (and there is no reason it should unless someone, or the program tells you!), you will never think to hunt the facility down. The modern customisable toolbar is another attempt to provide this functionality, but it still represents a chicken and egg situation to the user. So, yes, there is a real ~design~ job to be pursued here - a dynamically reconfigurable menu, that learns from the user, but that still presents a predictable enough structure so that things don't suddenly move to unexpected places. We are perhaps moving towards the era of the intelligent Agent, wher the program answers Howto questions from the user, and reconfigures itself according to the tasks the user most want to perform. Microsoft added a 'Answer Wizard' feature to Word (under the Help menu) where you type in a sentence such as "How do I format into two columns?", and it will parse the question and, with luck, take to to a suitable help message. Richard Dobson "STEFFL, ERIK *Internet* (SBCSI)" wrote: > > yes! instead of rigid menus or menus with last N open files etc. there > should be a menu re-arranging functionality that changes parts of the menu > so that the most often used functions are easy to access. For one-prupose > application that's already done, sort of, by designing the menu according > the common usage but for more complex apps that can be used in many ways > (e.g. start/root menu in window manager) it would be really nice to have the > menu changed according to your usage of the menu (since there is no good > default). > > it should be able to remember how many times you use the menu items and > have some sort of frgetting mechanism. I was thinking about implementing > something like that for fvwm (in debian (almost) all X apps and lot of text > mode apps have menu entries in pre-defined category so I was thinking about > putting the most often used ones into top level menu... > > there an interesting user interface used for one of the midi apps, forgot > the name, where you can rearrange all the menus, pin the menus or individual > buttons to workarea etc... it might be interesting to have something like > that in gnome or kde (qt, gtk) or other toolkits... > > erik > > -- -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
RE: [linux-audio-dev] what's wrong with glame
On Thu, 26 Jul 2001, STEFFL, ERIK *Internet* (SBCSI) wrote: > yes! instead of rigid menus or menus with last N open files etc. there > should be a menu re-arranging functionality that changes parts of the menu > so that the most often used functions are easy to access. For one-prupose I believe that studies have been done with dynamic menus. They found that it was confusing to have the menus rearrange. Humans get used to looking for the same thing in one place, and if the place changes and we have to look for it, it is an annoying slowdown. Taybin
RE: [linux-audio-dev] what's wrong with glame
yes! instead of rigid menus or menus with last N open files etc. there should be a menu re-arranging functionality that changes parts of the menu so that the most often used functions are easy to access. For one-prupose application that's already done, sort of, by designing the menu according the common usage but for more complex apps that can be used in many ways (e.g. start/root menu in window manager) it would be really nice to have the menu changed according to your usage of the menu (since there is no good default). it should be able to remember how many times you use the menu items and have some sort of frgetting mechanism. I was thinking about implementing something like that for fvwm (in debian (almost) all X apps and lot of text mode apps have menu entries in pre-defined category so I was thinking about putting the most often used ones into top level menu... there an interesting user interface used for one of the midi apps, forgot the name, where you can rearrange all the menus, pin the menus or individual buttons to workarea etc... it might be interesting to have something like that in gnome or kde (qt, gtk) or other toolkits... erik -- Time flies like an arrow but fruit flies like a banana... > -Original Message- > From: Patrick Shirkey [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 26, 2001 12:54 PM > To: [EMAIL PROTECTED] > Subject: Re: [linux-audio-dev] what's wrong with glame > > > Richard Dobson said: > > >and, wherever possible, ensure that the most frequently > performed tasks > >(which may be the most argued-over parameter, of course) require the > >least number of steps. A sub-menu requires at least four, > possibly five > >steps: > > How difficult would it be to add a statistical analysis > function to the > program which tracks the most used menu items and organises > them into a > seperate menu specifically for the most used items? > > > > > > > > > > > > -- > Patrick Shirkey - Manager Boost Hardware. > Importing Korean Computer Hardware to New Zealand. > Http://www.boosthardware.com - Cool toys to fufill every > geeks fantasy. >
Re: [linux-audio-dev] what's wrong with glame
Paul Davis wrote:
> who said a shallow learning curve was a goal?
>
In a word - users! A shallow learning curve exists where, primarily, a
user can open an application specified to perform a specific set of
tasks (e.g a soundfile editor, a word processor), and does not have to
read the manual, in order to start using it. The program is
self-documenting - the function names are expressive, toolbar buttons,
if used, identify their functions clearly (hence, ToolTips, status-bar
explanations). You should not, in most cases, have to use something in
order to find out what it does. Where de facto conventions exist for
some operations (such as mouse drag to select a region), they are
implemented, even if the developer has thought up some wizard-prang new
fancy way of dong this that he undestands but the user has no clue
about). When a user complained that an audio program I had written
didn't allow 'Play' to be controlled with the space bar ("all programs
do that!"), I learned this lesson myself.
Error messages are presented in plain English, and do no merely say
"Error" or "You can't do that", but offer a reasonable suggestion of
what you could do. The program itself guides the user into its more
obscure areas.
Now I am well aware that Linux/unix inherits and gleefully preserves a
aura of obscurantism, with requests (often none too polite!) to RTFM at
every turn, but often the FM is incomprehensible unless you already know
what it means, and often the FM doesn't exist anyway. Where
documentation does exist, it often says things like "to un-mitigate the
interface manifold bi-furcation, de-synchronize the positronic
lambdoma". Fistly, it assumes you know how to do the latter, and
secondly, it assumes you know ~why~ you would want to do the former in
the first place.
I could go on; you get the idea.
Failing the shallow learning curve is not a problem confined to Linux,
of course, but Linux does rather seem to specialize in it.
Someone (I genuinely forget who) recently posted a mesasge to this list
saying "I don't care about users, except contributing users", where the
clear meaning was that by this was meant erudite users who were probably
also programmers.
I rest my case...
Richard Dobson
--
Test your DAW with my Soundcard Attrition Page!
http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000)
CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] what's wrong with glame
Richard Dobson said: >and, wherever possible, ensure that the most frequently performed tasks >(which may be the most argued-over parameter, of course) require the >least number of steps. A sub-menu requires at least four, possibly five >steps: How difficult would it be to add a statistical analysis function to the program which tracks the most used menu items and organises them into a seperate menu specifically for the most used items? -- Patrick Shirkey - Manager Boost Hardware. Importing Korean Computer Hardware to New Zealand. Http://www.boosthardware.com - Cool toys to fufill every geeks fantasy.
Re: [linux-audio-dev] what's wrong with glame
>Actually you can resample with rather good quality. But you have to setup >a network for that purpose. Just stream the audio into FFT->FFT_RESAMPLE-> >IFFT. IMHO the quality is better than sox with polyphase resampling which >produces glitches. What exactly is the algorithm? Does it do a good job? How have you tested it? I'm in progress of implementing a resampler, and would like to know if any existing really work. Julius O. Smith has resampler but it may work for 16-bit audio only. SonicFlow has a resampler too, but I don't know details of it. -*- As what comes to various wave editors: it could be better to start turning Glame's wave editor, Sweep and Audacity(?) to a SoundForge clone because SoundForge has a quite good user interface. I understand you have your own ideas of how the editor should look like but as written here, they cannot be used if they are different from "standards". When all three are looking like SoundForge, they could be fused together much better. But it really is not necessary. Anyway, when we have a "standard" looking editor, it is easier to improve it further. It doesn't make sense to improve an editor which is practically unusable. Yes, SoundForge is not perfect either: I have a very hard time to perform such a simple operation than to extract selections of audio from larger files. It is next to impossible (but, of course, it is possible from engineer's perpective; not enough for artist!). However, I have a right tool for the task. ;-) I have a list of problems in SoundForge and would like to share it with you when we have a "standard" looking editor. Best regards, Juhana
Re: [linux-audio-dev] what's wrong with glame
>All the ~multi-track~ programs I have had experience of (Cubase, Cool >Edit Pro, and most recently, cakewalk SONAR) use the semantic 'Import', >for a simple reason - in a multi-track project, you have N tracks, and >any soundfile must be 'imported' to one of these (You may indeed need to >select a track before 'Import' becomes active). Cool Edit Pro has a nice >feature in that if you right-click in a track, the File menu appears >with Import, and the file is inserted at the cursor point. Yes, ardour uses "right click on track->Menu->Insert->Audio File". this pops up a "database" of audio files. you click on the one you want, and its inserted at the insertion cursor location for that track. current support is for mono audio files only (since tracks are mono). You could use the same Menu to insert the "Selection", "Cut Buffer", "Region" or a few other items. >Interpreting 'Import' as format conversion is, IMO, a typical >programmer's tinted spin on how the user thinks, or, rather, doesn't >want to have to think. After all, you don't 'Import' a Word document >into a word processor because it happens to be converted to Unicode,say, >internally. yes, thats why I prefer the word "insert" to "import". >Of course a keyboard shortcut can be used, but you have to know what it >is first, and preferably not requring three or four keypresses; so this >can conflict with the goal of a shallow learning curve (emacs being the who said a shallow learning curve was a goal? --p
Re: [linux-audio-dev] what's wrong with glame
(bearing in mind I haven't installed, much less used, GLAME, or anything, yet...) Alexander Ehlert wrote: > > Yeah, hmm, that's just naming. We could add something called open in the > menu which creates a group with the wavfile in it. But, importing it makes > sense because we convert everything to float internally to allow for high > quality dsp. So you have to import and export it. But that's not really > an issue compared to open/close, it's just getting used to it. Ok, I have > to admit that the file importing(opening) gui is rather bad. But I wasn't > motivated yet to change that. I think this is a semantic misunderstanding. All the ~multi-track~ programs I have had experience of (Cubase, Cool Edit Pro, and most recently, cakewalk SONAR) use the semantic 'Import', for a simple reason - in a multi-track project, you have N tracks, and any soundfile must be 'imported' to one of these (You may indeed need to select a track before 'Import' becomes active). Cool Edit Pro has a nice feature in that if you right-click in a track, the File menu appears with Import, and the file is inserted at the cursor point. In a plain stereo wave-editor, there is by definition only one track, so 'Import' is unnecessary, and 'Open' is more idiomatic. At least in Windows and the Mac, the File->Open command is always understood to relate to the main file associated with the project (the file you might double-click on from Windows Explorer); this would for most users be a Session, Project, name-it-what-you-will. Double-clicking on a soundfile name would be expected to play it using the default player. However, at least under Windows, you can change a file association so that selecting a soundfile opens it in your preferred application (assuming it can accept the file in that way). This merely requires a 'multi-document' capability where the command-line passed to the program can contain the name of either a Project or a SoundFile (or a MIDI file, or...), and either can be opened. SONAR cannot do this (for the above reason - where would it go?), but Cool Edit Pro can, possibly uniquely, because it implements two parallel modes - multi-track project, and single-track editor mode. Interpreting 'Import' as format conversion is, IMO, a typical programmer's tinted spin on how the user thinks, or, rather, doesn't want to have to think. After all, you don't 'Import' a Word document into a word processor because it happens to be converted to Unicode,say, internally. The user, generally, couldn't care less about internal representation. They will only want to know that the highest audio quality is maintained internally (however that's done - 32bit ints? doubles? quads?), and they will sometimes want to 'Save As' a different format, or explicitly do a Format Conversion as some programs require you to do - which even I find a complete pain in the A. Designing User Interfaces is a real challenge, not merely from an implementation point of view (all those debates about libraries!), but literally from a design, i.e. HCI, point of view. Certain procedures become de-facto standard, and a developer takes a great risk in changing this; on the other hand if the change very clearly leads to an increase in intuitiveness and efficiency for the user, they will generally accept it after a moment to re-orient. Nevertheless, there is a simple HCI measure of efficiency for the user, which is to find the number of discrete steps the user must perform to achive any specific operation, and, wherever possible, ensure that the most frequently performed tasks (which may be the most argued-over parameter, of course) require the least number of steps. A sub-menu requires at least four, possibly five steps: Menu-->scroll-to-Item-->(Click-item-->)scroll down submenu-->click sub-item. Of course a keyboard shortcut can be used, but you have to know what it is first, and preferably not requring three or four keypresses; so this can conflict with the goal of a shallow learning curve (emacs being the prime culprit/hero here, as was, in days of yore, WordStar). Given the WIMP paradigm, it follows that a design that allows both projects, and soundfiles, to be opened with one mouse-click (!), is the Holy Grail. Good Luck! Richard Dobson -- Test your DAW with my Soundcard Attrition Page! http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)
Re: [linux-audio-dev] what's wrong with glame
- Original Message - From: "Paul Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, 26 July 2001 11:29 Subject: Re: [linux-audio-dev] what's wrong with glame > I'm not the obvious person to define GLAME, but: > > >The idea of a 'project' is a nice approach - but it tends to assume that one > >is about to embark on something of a large scale. In other environments this > >is also called the session - which is an option only if you want to save > >global setting as applied specifically to your work, or an arrangement, as > >in cool edit pro [windows]. > > > >Often however i don't want to make a project, so much as quickly edit a > >wave. Most desktop studios are engaged in editing samples every few minutes > >during a normal day. This is where glame really struggles to be useful. > > This is where almost all multitrack-capable systems tend to fall > over. Its very common to see people use ProTools *and* a wave editor > like soundforge or Cool Edit Pro. The multitrack systems are just > that: tools for recording, playing, arranging multitrack > recordings. If you want a wave editor then you either have to: > > 1) use a dedicated wave editor > 2) find the wave editor *within* the multitrack system > Thats not to say that (2) shouldn't be easy, and that editor shouldn't > be good. But its very likely that you would still continue using a > dedicated external editor even if the one inside the MT system was > pretty usable. sometime this is the case, but as i may have indicated, this is dispreferred in the ends of efficiency. the all in one studio, though more ambitious, is a lovely thing to drive. however you are right, one becomes habitually addicted to a good editor, and will often be used independently of the multitrack studio as a result. > > You're also missing out on a crucial distinction between editing > music, which is mostly a matter of *arranging* existing audio, and > editing wavefiles, which is concerned with the itty-bitty details of > samples and so forth. A tool (possibly within-a-tool) that is well > suited for the first of these is likely to be not well suited to the > second, and vice versa. I think you know this, but its a distinction > that hasn't even been obvious to date in any Linux audio software > (except perhaps in MusE and Jazz, neither of which have "good" audio > editors). > not at all, both of which were being actively considered in my notes. i think the arranging of music [in the sense of orchestration] is better left to the Logic / Cubase / Pro-Tools strain of apps - eg MIDI + sequencer, with a notation layer for portable arrangement. glame however has the possibility to be a powerful editor if only it had an better GUI and *some* support for the fundamental need of bumping down tracks. if not, it is stuck as a rarified filter-chainer with entry level editor. glame however has the capacity to satisfy both the pre and post production requirements of projects in MusE and Jazz [for instance]. de| _ / a -> b, b ->c, a -> d, d -> c ...and so on...\ _
Re: [linux-audio-dev] what's wrong with glame
> > So if we pop up the waveeditor right away you would be happy? ohhh yes ; ) and as for all that's below - look great so far - richards comments earlier seemed clear-headed also. you guys already know this stuff! i'll pick through it all and get back to you tommorrow. de| > > > And the waveform view is nothing to smile about - black and white is a bad > > choice of rendering. High contrast schemes like this make a 10 hour session > > in the editor a strain, though the wearing of sunglasses indoors is > > particular to this field. > > Agreed :) > > > At this stage I realise that I loaded the wrong file[s], to get rid of it > > from the project list i have to [delete] [as opposed to the inuitive, > > 'close'] and then 'empty the > > trash' [what trash? and why should i [?] - implying that i have the option > > to revoke my decision once it's in the trash]. > > Thats actually a new feature because I delete some samples I made > accidentially before I saved them. But this could be made configurable in > the preferences menu. > Or a popup "Really delete file"? But that last option IMHO suxx. > > > I find that there aren't even samples, rms, or 'beats' as alternative timing > > schemes - many other media packages require these time scalings for sync > > up - in this way glame further rarifies it's position as a stand-alone-tool. > > Ok that goes hand in hand with the still bad wavewidget which lacks > support for all that stuff. > > > There needs to be an option for resampling file in conjunction with shifitng > > bit-rates. > > eg: 48khz / 24bit > 22.05khz / 8bit. preferably with dithering and > > noise-shaping in order to maintain the integrity of the signal. > > this would enable the multimedia community to use glame for web and cdrom > > without fscking around in other apps. > > Actually you can resample with rather good quality. But you have to setup > a network for that purpose. Just stream the audio into FFT->FFT_RESAMPLE-> > IFFT. IMHO the quality is better than sox with polyphase resampling which > produces glitches. > Saving with other resolution than 16bit would go into exporting features. > > > [looks like a recycle symbol] that I assumed probably meant 'loop' - that > > strangely means 'view all'. I couldn't and still can't find how to loop on a > > selection in glame... > > You can't :( > > > I can't do it in either install of glame. For this reason i can't really use > > it at all. Similarly all editors have a key-bind for play and stop!!! Why > > doesn't glame?? > > hmm, ok, you'll find the default keybindings in default-accels. On the > other hand it should be easy to add keybindings for that stuff. Are you > on glame-users yet? > > > enough i have to then hit a second play button in a strange play control > > that pops up!!! That i found really frustrating. > > Yupp :) It is. > > > representation of commonly expected envelope based amplitude fade, with > > presets for bell, curved and the requisite attack/decay. > > Ok, if you can explain to me in detail how that fader should look like > I happily extend it. > > > useless. The worst case here is 'volume adjust', which uses [instead of > > 'dB', or 'percent'!!] 'factor' whatever that is. Here information is use > > with confidence. > > True, what do you like better, dB or percent or both? Factor is just the > multiplication factor. So 1.5 = 50% increase. > > Ok thanks, you're the first to actually give some decent feedback. Without > that we just don't know what's missing, what people want. And I haven't > used all those windows software on a regular basis.
Re: [linux-audio-dev] what's wrong with glame
Hi, first of all thanks for all your constructive feedback. > install notes you said this worked - I may have done something wrong. Also > it should be said that I've only been using Glame for a week or so, forgive > me for the things I've overlooked [short keys / menu's etc]... Hmm, it only works if you configure either oss_audio_out or alsa_audio_out as output plugins and use something newer than glame 0.4. > wave. Most desktop studios are engaged in editing samples every few minutes > during a normal day. This is where glame really struggles to be useful. Yeah, hmm, that's just naming. We could add something called open in the menu which creates a group with the wavfile in it. But, importing it makes sense because we convert everything to float internally to allow for high quality dsp. So you have to import and export it. But that's not really an issue compared to open/close, it's just getting used to it. Ok, I have to admit that the file importing(opening) gui is rather bad. But I wasn't motivated yet to change that. > Glame's functionality needs to be considered within this hierachy of needs: > Most studios, home and pro, require these in an editor /multitracker /dsp > studio: > > Open sample [resample / attentuate / trim > Record sample [line in or another output from app] > Edit sample / signal process /clean [many of these open at once] > Multitrack session [for composition, syncing and mix down] > Custom project / session / filternetwork If you wanna get active in ergonomic gui design and propose some structure that fits on our backend, go ahead :-) > are ditching pro-tools] simply has 'open' when in 'waveform view' - since in > that window, you're always going to be opening soundfiles...import in so > many desktop studios represents a special function, that's why when i first > used glame, i reached for the 'add stereo wave' item. So if we pop up the waveeditor right away you would be happy? > And the waveform view is nothing to smile about - black and white is a bad > choice of rendering. High contrast schemes like this make a 10 hour session > in the editor a strain, though the wearing of sunglasses indoors is > particular to this field. Agreed :) > At this stage I realise that I loaded the wrong file[s], to get rid of it > from the project list i have to [delete] [as opposed to the inuitive, > 'close'] and then 'empty the > trash' [what trash? and why should i [?] - implying that i have the option > to revoke my decision once it's in the trash]. Thats actually a new feature because I delete some samples I made accidentially before I saved them. But this could be made configurable in the preferences menu. Or a popup "Really delete file"? But that last option IMHO suxx. > I find that there aren't even samples, rms, or 'beats' as alternative timing > schemes - many other media packages require these time scalings for sync > up - in this way glame further rarifies it's position as a stand-alone-tool. Ok that goes hand in hand with the still bad wavewidget which lacks support for all that stuff. > There needs to be an option for resampling file in conjunction with shifitng > bit-rates. > eg: 48khz / 24bit > 22.05khz / 8bit. preferably with dithering and > noise-shaping in order to maintain the integrity of the signal. > this would enable the multimedia community to use glame for web and cdrom > without fscking around in other apps. Actually you can resample with rather good quality. But you have to setup a network for that purpose. Just stream the audio into FFT->FFT_RESAMPLE-> IFFT. IMHO the quality is better than sox with polyphase resampling which produces glitches. Saving with other resolution than 16bit would go into exporting features. > [looks like a recycle symbol] that I assumed probably meant 'loop' - that > strangely means 'view all'. I couldn't and still can't find how to loop on a > selection in glame... You can't :( > I can't do it in either install of glame. For this reason i can't really use > it at all. Similarly all editors have a key-bind for play and stop!!! Why > doesn't glame?? hmm, ok, you'll find the default keybindings in default-accels. On the other hand it should be easy to add keybindings for that stuff. Are you on glame-users yet? > enough i have to then hit a second play button in a strange play control > that pops up!!! That i found really frustrating. Yupp :) It is. > representation of commonly expected envelope based amplitude fade, with > presets for bell, curved and the requisite attack/decay. Ok, if you can explain to me in detail how that fader should look like I happily extend it. > useless. The worst case here is 'volume adjust', which uses [instead of > 'dB', or 'percent'!!] 'factor' whatever that is. Here information is use > with confidence. True, what do you like better, dB or percent or both? Factor is just the multiplication factor. So 1.5 = 50% increase. Ok thanks, you're the first to actually give some decent feedback. With
Re: [linux-audio-dev] what's wrong with glame
On Thu, 26 Jul 2001, delire wrote: > This is a fairly lengthy rant on the latest glame. Some of you might find it > boring. It's really directed at the authors. > What I say here needs to be taken in context. My requirements for an editor > are fairly heavy as I make both commercial special effects and > noise/electroacoustic music. > It's rare that I work under DAT level audio - 48khz. But like a normal > studio it's not uncommon for me to have 50 or 60 audio files open at the > same time. Similarly, with my electroacoustics, I rarely work under 4 > channels. > > So in this way i'm not your ideal subject. However I do produce alot of work > for various multimedia productions, including games, which i think includes > your target user. I say this because while glame isn't advanced in other > areas, you have placed a strong emphasis on signal processing. Ok, you actually _seem_ to be our ideal subject - somehow :) For the following I will assume you tried GLAME 0.5.2 and mark things that are _not_ available with 0.4.2 with a [~0.4.2]. > Two different systems are running glame in my studio, one is a debian box > and the other runs suse [both latest kernels (now) thanks to a bad analogy > from paul davis] All required libs are installed. I noticed that both don't > have a play head that follows the audio - instead it remains static. In the > install notes you said this worked - I may have done something wrong. Also For esd output we didnt bother to add support for it (blame us - will fix this in a minute), for other methods it should work [~0.4.2] > it should be said that I've only been using Glame for a week or so, forgive > me for the things I've overlooked [short keys / menu's etc]... > > I'll begin: > > The idea of a 'project' is a nice approach - but it tends to assume that one > is about to embark on something of a large scale. In other environments this > is also called the session - which is an option only if you want to save > global setting as applied specifically to your work, or an arrangement, as > in cool edit pro [windows]. Ok, our whole concept of the tree-view with projects is that you have exactly one seession which handles multiple projects (aka subtrees). Maybe not really obvious / useful. > Often however i don't want to make a project, so much as quickly edit a > wave. Most desktop studios are engaged in editing samples every few minutes > during a normal day. This is where glame really struggles to be useful. Is this because of the many steps you need to do before you are presented with the wave editor? If so, adding shortcuts for this is easy. Or are there more fundamental problems? > What tends to happen in most studios is users become loyal to an editor > through familiarity. As a result one editor is chosen as the native editor > for all situations, so even when you're in another app, you can click > [something like 'editor'] and your waveform immediately appears. Also it's > necessary to be able to click on a sound-file and immediately bring it up in > waveform view ready to go. In these two ways, 'setting up a project' blocks > access to the urgent role of the editor in any audio. Ok. Noted. I suppose, we'll add a Project/Edit file... main menu entry which just inserts the imported wave as a "new project" and opens up the wave editor with it. > Glame's functionality needs to be considered within this hierachy of needs: > Most studios, home and pro, require these in an editor /multitracker /dsp > studio: > > Open sample [resample / attentuate / trim > Record sample [line in or another output from app] > Edit sample / signal process /clean [many of these open at once] > Multitrack session [for composition, syncing and mix down] > Custom project / session / filternetwork > > > By orienting work around the 'project' you're stopping glame from becoming a > popular [frequently used] editor. > > Once I made a project, i had to 'import audio'!! As though audio were not > the native media of the app. All good apps assume that 'open file' leads to > a wave. Cool edit pro [which is becoming so popular that many major studios > [including the ABC in my country] > are ditching pro-tools] simply has 'open' when in 'waveform view' - since in > that window, you're always going to be opening soundfiles...import in so > many desktop studios represents a special function, that's why when i first > used glame, i reached for the 'add stereo wave' item. > > Even once i've imported the audio i'm still barred; held back before getting > on with the job of editing...now i have to select the > text-that-represents-my-file and choose to 'edit it', as though there were > other things i might want to do with it instead. > So i right click on the name of the file [?] and then choose 'edit', which > brings up the waveform view. > > And the waveform view is nothing to smile about - black and white is a bad > choice of rendering. High contrast schemes like this make a 10 hour session > in the
Re: [linux-audio-dev] what's wrong with glame
I'm not the obvious person to define GLAME, but: >The idea of a 'project' is a nice approach - but it tends to assume that one >is about to embark on something of a large scale. In other environments this >is also called the session - which is an option only if you want to save >global setting as applied specifically to your work, or an arrangement, as >in cool edit pro [windows]. > >Often however i don't want to make a project, so much as quickly edit a >wave. Most desktop studios are engaged in editing samples every few minutes >during a normal day. This is where glame really struggles to be useful. This is where almost all multitrack-capable systems tend to fall over. Its very common to see people use ProTools *and* a wave editor like soundforge or Cool Edit Pro. The multitrack systems are just that: tools for recording, playing, arranging multitrack recordings. If you want a wave editor then you either have to: 1) use a dedicated wave editor 2) find the wave editor *within* the multitrack system Thats not to say that (2) shouldn't be easy, and that editor shouldn't be good. But its very likely that you would still continue using a dedicated external editor even if the one inside the MT system was pretty usable. You're also missing out on a crucial distinction between editing music, which is mostly a matter of *arranging* existing audio, and editing wavefiles, which is concerned with the itty-bitty details of samples and so forth. A tool (possibly within-a-tool) that is well suited for the first of these is likely to be not well suited to the second, and vice versa. I think you know this, but its a distinction that hasn't even been obvious to date in any Linux audio software (except perhaps in MusE and Jazz, neither of which have "good" audio editors). --p
[linux-audio-dev] what's wrong with glame
This is a fairly lengthy rant on the latest glame. Some of you might find it boring. It's really directed at the authors. What I say here needs to be taken in context. My requirements for an editor are fairly heavy as I make both commercial special effects and noise/electroacoustic music. It's rare that I work under DAT level audio - 48khz. But like a normal studio it's not uncommon for me to have 50 or 60 audio files open at the same time. Similarly, with my electroacoustics, I rarely work under 4 channels. So in this way i'm not your ideal subject. However I do produce alot of work for various multimedia productions, including games, which i think includes your target user. I say this because while glame isn't advanced in other areas, you have placed a strong emphasis on signal processing. Two different systems are running glame in my studio, one is a debian box and the other runs suse [both latest kernels (now) thanks to a bad analogy from paul davis] All required libs are installed. I noticed that both don't have a play head that follows the audio - instead it remains static. In the install notes you said this worked - I may have done something wrong. Also it should be said that I've only been using Glame for a week or so, forgive me for the things I've overlooked [short keys / menu's etc]... I'll begin: The idea of a 'project' is a nice approach - but it tends to assume that one is about to embark on something of a large scale. In other environments this is also called the session - which is an option only if you want to save global setting as applied specifically to your work, or an arrangement, as in cool edit pro [windows]. Often however i don't want to make a project, so much as quickly edit a wave. Most desktop studios are engaged in editing samples every few minutes during a normal day. This is where glame really struggles to be useful. What tends to happen in most studios is users become loyal to an editor through familiarity. As a result one editor is chosen as the native editor for all situations, so even when you're in another app, you can click [something like 'editor'] and your waveform immediately appears. Also it's necessary to be able to click on a sound-file and immediately bring it up in waveform view ready to go. In these two ways, 'setting up a project' blocks access to the urgent role of the editor in any audio. Glame's functionality needs to be considered within this hierachy of needs: Most studios, home and pro, require these in an editor /multitracker /dsp studio: Open sample [resample / attentuate / trim Record sample [line in or another output from app] Edit sample / signal process /clean [many of these open at once] Multitrack session [for composition, syncing and mix down] Custom project / session / filternetwork By orienting work around the 'project' you're stopping glame from becoming a popular [frequently used] editor. Once I made a project, i had to 'import audio'!! As though audio were not the native media of the app. All good apps assume that 'open file' leads to a wave. Cool edit pro [which is becoming so popular that many major studios [including the ABC in my country] are ditching pro-tools] simply has 'open' when in 'waveform view' - since in that window, you're always going to be opening soundfiles...import in so many desktop studios represents a special function, that's why when i first used glame, i reached for the 'add stereo wave' item. Even once i've imported the audio i'm still barred; held back before getting on with the job of editing...now i have to select the text-that-represents-my-file and choose to 'edit it', as though there were other things i might want to do with it instead. So i right click on the name of the file [?] and then choose 'edit', which brings up the waveform view. And the waveform view is nothing to smile about - black and white is a bad choice of rendering. High contrast schemes like this make a 10 hour session in the editor a strain, though the wearing of sunglasses indoors is particular to this field. At this stage I realise that I loaded the wrong file[s], to get rid of it from the project list i have to [delete] [as opposed to the inuitive, 'close'] and then 'empty the trash' [what trash? and why should i [?] - implying that i have the option to revoke my decision once it's in the trash]. Back in the edit mode with the right file I look first for my peak values, trying to get a sense of how i should attentuate the file. Also because i have to, say, make a file exactly 10.253 seconds in length i look for the time [this probably sounds ridiculaous but it happens often when making sound for film or games]. also accuracy is a kind of confidence. I find that there aren't even samples, rms, or 'beats' as alternative timing schemes - many other media packages require these time scalings for sync up - in this way glame further rarifies it's position as a stand-alone-tool. Most importantly however, there is no means of ev
