Subject:Acid Improvement?
Posted by: mike_s
Date:6/8/2000 8:53:00 PM
The improvement: Collapsible tracks. The user should be able to group tracks and collapse or expand them to save UI space. The collapsed display could just show the combined duration(s), but it would be nice if it differentiated between the contained samples' events, possibly with a color-coded overlay. Collapsible sections are a feature of Allaire's Homesite HTML editor, and layer grouping will be a feature of Photoshop 6. This might be a moot point if more than one sample could be used per track. The track metaphor seems to be a relic of tape/HW-based recording. Isn't Acid's track view just a 2D array (level+duration)? Why not save a ton of UI space and allow multiple samples per track? Of course this would increase processor utilization, as you would want to optionally handle timestretching and effect processing on a per-event level, but I suspect that this is doable, given the power of the latest processors and multi-processor systems. |
Subject:Re: Acid Improvement?
Reply by: Kelly_S
Date:6/14/2000 6:36:00 PM
Hello Mike! These are very good suggestions, have you had a chance to put it into the suggestion form yet? Everybody can and should do this, you can go to: http://www.sonicfoundry.com/support/feedback.asp Thanks! Mike S wrote: >>The improvement: Collapsible tracks. The user should be able >>to group tracks and collapse or expand them to save UI >>space. The collapsed display could just show the combined >>duration(s), but it would be nice if it differentiated >>between the contained samples' events, possibly with >>a color-coded overlay. Collapsible sections are a feature of >>Allaire's Homesite HTML editor, and layer grouping will be a >>feature of Photoshop 6. >> >>This might be a moot point if more than one sample could be >>used per track. The track metaphor seems to be a relic of >>tape/HW-based recording. Isn't Acid's track view just a 2D >>array (level+duration)? Why not save a ton of UI space and >>allow multiple samples per track? Of course this would >>increase processor utilization, as you would want to >>optionally handle timestretching and effect processing on a >>per-event level, but I suspect that this is doable, given >>the power of the latest processors and multi-processor >>systems. |