For a person like myself, Beat Designer is superior to the drum editor in at least early the early phase of a project. The workflow I have in mind:
(1) Write a song. Voice, guitar or keys, maybe some bass. No drums in mind, because that’s not my strong suit.
(2) Using rudimentary or neutral drums (almost like a click track), lay down what I have.
(3) Design a real drum part to enhance what I have. Beat Designer is ideal for this.
However, I may wish to pick and choose drum sounds from multiple sources, such as:
(1) Groove Agent sampled kits (Pop Rock Toolkit, Beat Agent, AM Signature Drums)
(2) Acoustic Agent (part of Groove Agent, it appears)
(3) B Box
(4) HALion factory kits
(5) World Percussion
Now, you can’t drag and drop from Acoustic Agent to Beat Agent (nor should you be able to) because Acoustic Agent isn’t a sample library, sliced loop source. It’s a simulation of recording a drum kit in a studio, with many complex factors. (mic placement and spillage, HH spacing, and such.) Therefore, it needs to be on a separate track.
A similar issue appears with World Percussion. If there’s a way to find samples and drag them to Beat Agent, it can’t be easy. It’s incompatible with Acoustic Agent, as it should be. One must establish a separate track to draw on World Percussion sounds. A similar situation exists for HALion kits and sounds. Each sound requires its own track.
B Box is not part of Grove Agent, it’s an instrument set, like World Percussion or HALion factory sounds. Therefore, it needs its own track.
So we could be looking at 5 tracks, one for each item on the list above. Beat Designer is a MIDI insert. It is associated with one track. So you need 5 instances of Beat Designer. This is awkward. Transferring patterns from one instance of Beat Designer to another requires a cut/paste operation that can easily go wrong. Even without that issue, your kit is no longer consolidated in one place.
Suggested Feature
Suppose we were to have a group track containing the 5 tracks. Imagine BD+ (Beat Designer Plus), an enhanced version of beat designer. It’s still a MIDI insert, and it’s the same as beat designer when used on a single track. But it can also be inserted into a group track. (Granted, there are no MIDI inserts on group tracks, but that could be changed).
When inserted into a group track, BD+ adds the option of routing each lane to a track within the group, like this:
The cyan triangles activate a pop-up menu that lists the track names contained in the group. In this example, there are 5 destinations (Beat Agent track, Acoustic Agent track, World Percussion Track, B-Box track, and HALion factory track). The user chooses a destination for each lane. The MIDI events for that lane are then routed to the appropriate track.
Result
With a fairly modest amount of software engineering, we now have a consolidated kit. The need to copy between instances of Beat Designer is eliminated. Additional tracks can be added to the group without much user agony. I believe these modifications would vastly improve Beat Designer at minimal cost. Lanes routed to tracks that have been deleted would route nowhere, but the pattern would remain in BD+, awaiting assignment.
Implementation
… might be simplified by spawning instances of (existing) Beat Designer into tracks within the group. Already existing instances of Beat Designer would be preserved, but deactivated. BD+ would essentially copy the relevant lanes to the appropriate spawned instance of Beat Designer. Should users be able to edit the spawned BD instances? Perhaps not, because:
(a) It violates the BD+ concept of centralized control over a consolidated kit.
(b) It would require transfer of the edits from BD to BD+, and that’s more engineering.
On the other hand, prohibiting users to modify the data in spawned BD instances would require making spawned BD read-only (except via BD+), and that could be more trouble to engineer than it’s worth. (It doesn’t strike me that way - just add a boolean instance property to BD, set true by default, but set false in the case of spawned BD. Add it as an optional parameter to the tail end of the constructor, or use a Set() method just after spawning. Such a property would only have to be read in the event a of direct user editing event, so should have minimal impact on performance.)
Following normal engineering practices (as I understand them) would mean changing the existing BD into an Abstract Base Class (AbstractBeatDesigner, say) that includes the new boolean property. Concrete BD and BD+ would be sub-classes. Avoid trouble using the existing BD class name for the Concrete BD subclass. A new write method (protected or friend access granted to BD+) for MIDI transfer might be required in the new concrete BD class. BD+ would require a publish/subscribe design pattern to communicate with spawned instances of BD. The subscription would be controlled by the group track; when new tracks are added or deleted, and when BD+ is instantiated. (Obviously, only a group track could call the BD+ constructor. This would be triggered by the user requesting a BD+ MIDI insert from the group track.)
It all seems so possible to me.
My only reluctance with this proposal is having to pay $50 for it in build 8.5.16.