Talk:Big Architectural Ideas

TrackPanel
James: In my view a refactoring of the TrackPanel will need us to write flyweight sizers to manage the resizing of tracks. These will be analogous to wxWidgets sizers. Tracks are not true windows, and should not become ones. This is based on experiments with my own DragGridSizer and Johannes' experience during GSoC. Happy to say more on request.

Channels/Grouping/Linking
LRN: I'd like to see multichannel support. That means that Audacity should handle any number of channels as a single entity, should be able to record from multichannel sources and should know about channel layout. From architectural point of view that means that there should be either a separate 'channel' hierarchy level under the 'track' level, or some kind of other universal grouping mechanism. It's easy enough to do that for audio tracks, but i do not know how that would apply to non-audio tracks, and how would that work with some tools. That should be defined.

I think this feature is linked (NPI) somehow to label track linking, because both are dealing with track groups. That is why it could be better to use a 'track group' instead of a 'track that consists of channels', but if non-audio tracks can be grouped together with audio tracks, there's a question of what to do with them when something happens.

On the other hand, as far as i understand, linking use-cases involve linking together a few separate audio tracks (that do not form a single multi-channel track) and separate label tracks. Which means that either groups should support nesting, or multichannel grouping should be separate and should stay on lower level in the hierarchy.

Note, that we're talking about internal architecture, users may get different view of tracks that does not mirror internal track architecture.

One of the ideas is to allow users to 'enter a group'. When you're inside a group, you can edit its components separately. But once you exit it (usually - by double-clicking outside of the group), the group is treated as a single object. At least that is how it seems to be working in office applications. That would work with both nesting and non-nesting approach to track grouping.

Also, all operations should be remade to have generic multi-track (multi-channel?) support. That is, performing the action N on a track from a group causes action N to be taken upon all other tracks in that group. It can be applied on per-track basis (can be applied only to one track at once, does the same thing to each track) or to all tracks simultaneously (does different things to different tracks). These actions can be issued from menus/tools, but effects should use them to. For [a hypothetical] example, an effect that generates a tone could do: delete selected audio (if selection is non-NULL), cut at selection (if selection is not at clip boundary), create clip at cut point, resize clip to N milliseconds, replace clip contents with tone (actual effect code is at work here), join this clip with the left clip (if present), join this clip with the right clip (if present). All these actions (except clip contents replacement) are generic and can be applied to all tracks in the group (including non-audio tracks). Thus, an effect implementation would not have to worry about groups - it will just mirror all actions to all tracks in the same group. At least, that is true for mono effects. But non-mono effects will still be able to mirror actions to non-audio tracks in a generic way.

Here are two UI mockups. They are drawn from user's point of view, but architecture should match that (generic group class that can accept any simple operation and mirror it to all sub-tracks/groups).

Channel layout
LRN: This does not depend on grouping (although it works well with it and might not work correctly with current stereo tracks). Basically, Audacity should have a [user-defined?] enumeration (like, "Forward Left, Forward Right, Backward Left, Backward Right, Center, LFE", let's call it "layout group") and let user attach layout members of that layout group to individual channels (single-track audio groups, if we adopt the grouping terminology explained above in "Channels/Grouping/Linking"). When audio is played, Audacity searches for channels with the same layout members and mixes them together (well, to speed up things it should keep a list of tracks for each layout member close at hand). That is, finds all "Forward Right" channels and mixes them together, regardless of where in the track hierarchy they are located; though per-track volume sliders still apply and are cumulative for nested tracks; solo and mute apply too. Then, once audio is mixed for each layout member, each member is mapped to a real channel of the output device (with some more mixing when output device has less channels than the audio being played). When audio is exported, layout members can be mapped to output file channels (roughly the same way they do now, just use pre-mixed tracks that correspond to layout members instead of individual tracks) Mapping should be configurable, and layout group could be too. By default mapping would be straightforward - roughly 10 layout group members, and something like 4 different mapping templates (for 2.0, 4.0, 5.1 and 7.1). Some layout members will be mapped directly to some output device channels, others will be mixed evenly to all output device channels (such as "Center" layout member in 4.0 mapping, which knows only "Forward/Backward Left/Right").

Drawing Code
James: Anti-aliased drawing will be important in the future. Cairo is the natural choice. The vowel-quadrilateral in audacity-extra looks way better with it, and so do rulers (these using anti-grain).

I very much like our existing decision to have TrackArtist classes that do actual drawing.

"I would like us to systematically separate code that uses the GDI into artist classes throughout Audacity. In particular we do not embed drawing code in the same classes that handle the underlying cut/paste/copy data operations."

Guiding Principles
Are there any guiding principles we want to mention on the article page? One I have long found useful is:


 * Try to reduce the number of 'different kinds of things', example: labels being different from clips causes more work.