Drum Map bug? (Resolved)

[Robert Bone]

Before I even start this - PROFOUND apologies for the length of this post - it is rather hard to explain, so sorry about that.

OK - maybe I just do not know what I am doing, regarding using a track template that I set up for a friend of mine, for Addictive Drums 2, which included several pieces, and multiple audio tracks for those kit pieces, and a drum map.

Components created for the track template, which were created from a new CbB project and exported as a track template, included:

1) An instance of Addictive Drums 2, with a custom AD2 map created to assign particular note numbers to particular kit pieces, to be able to map properly between his Alesis DM Pro drum module note numbers, and the correct kit pieces in AD2.  The AD2 instance also had alterations to its mixer window, to send each kit piece to a separate output channel.

2) A track folder. and audio tracks in the track folder, for each of the kit pieces coming from the multiple outputs from the AD2 instance, so that there was an audio track assigned to each audio output channel from the AD2 mixer, so a Kick Drum audio track assigned to the AD2 audio output channel containing the AD2 Kick Drum audio, etc....  There was also a MIDI track in the track folder, which had Input set to Omni, and Output assigned to a drum map that I had built and saved, with the note numbers to map to the kit piece note numbers from the AD2 instance.  This CbB drum map was created and saved, pointing to the instance of AD2 used when the track template was created.

OK - so my friend has a number of existing projects in CbB, going back a couple of years in the making, where he set up those projects to use a simple instrument track, most of the time, for whatever AD2 instance he brought in, where all the kit piece audio was contained in the single stereo audio portion of the simple instrument tracks.

When I showed him how much nicer it would have been, for him to have set it up to where each of the AD2 kit pieces had its own audio track(s), he decided he wanted help setting up a number of track templates, like I outlined above, to accomplish splliting the AD2 audio into separate tracks for each kit piece.  So far, so good.

SO - yesterday, we built a couple of the track templates for 2 of the different kits and presets he used from AD2, so that each kit and preset would have its own track template, with the split tracks, etc...., so that he could go back into his CbB projects, and replace the original simple instrument track, in a given project, with the appropriate track template with the split tracks for the same AD2 kit.

Well, in the course of showing him how this would work, we opened up one of his existing projects, and I inserted the correct track template, and THIS is where I either don't understand something, or perhaps there is a bug in CbB's use of drum maps in track templates, because for whatever reason - whether a bug or I missed something, 

The issue: since there is already an instance of AD2 in the existing project, when I insert the track template, to bring in all the tracks and buses, and another instance of AD2, and the custom AD2 map, and the CbB drum map I had built and included in the track template, well, CbB does NOT adjust the AD2 instance pointed to in the drum map.  I was expecting CbB to have internally adjusted the drum map AD2 instance numbering, to match the numbering CbB gave the track template AD2 instance that got inserted into the Synth Rack.  

SOOOO - the original project had an AD2instance, called "Addictive Drums 2 1", and when the new instance came in with the inserted track template, the new AD2 instance was given the name "Addictive Drums 2 2" by CbB, however, the track template's drum map on the MIDI track for the track template, was built pointing to an AD2 Synth Rack instance called "Addictive Drums 2 1", and the drum map's output port was NOT internally adjusted by CbB, to match the name given by CbB to the new AD2 instance that came in with the track template, SO, the result is that the when the new track template's MIDI track MIDI icon is clicked on, to open the AD2 instance associated with the track template, because the drum map is incorrectly pointing to an AD2 instance called "Addictive Drums 2 1", which points to the original AD2 instance from the existing project, which is entirely incorrect.

It gets worse.  SO, to get the drum map, brought in by the track template, pointing to the 2nd AD2 instance (Addictive Drums 2 2), I have to open up the Drum Map Manager for the track template's drum map, and then change the Output Port in it, to point to the 2nd AD2 instance, which will only then properly route MIDI data from the track template's MIDI track, to the 2nd AD2 instance.

Well, this presents an additional problem, because I now have, in the project, a modified drum map, that will always have unsaved changes to it - because of the alterations to the Output Ports for each of the rows in the drum map. 

Maybe the above is not an issue, except this project will always just have those drum map modifications, which seems rather odd - I think that I should not have had to even alter that track template drum map - I think that if CbB has the wherewithal to know it has to adjust the naming of the 2nd AD2 instance that comes into the project from the insertion of the track template, well, I think CbB has the information needed to ALSO adjust the drum map Output Port data for each row in the drum map, to point to that 2nd AD2 instance that came in from the track template insertion.

Even if I wanted to save  the manually altered Output Port changes - to point to the 2nd AD2 instance, I cannot save those changes to that drum map in the Drum Map Manager, because of how the Drum Map Manager uses the Preset text box for drum map names. 

The way you save a drum map in the Drum Map Manager, is to type a name in the Preset text box, click Save, to create a new drum map.  There does not seem to be a way to modify an existing drum map, and have the Drum Map Manager overwite that drum map with the modifications.

If I type in the same name of the drum map that got loaded into the project by the insertion of the track template, rather than giving a means of overwriting that drum map, it tries to LOAD the unmodified drum map again, which is an issue, because it knows the current drum map (same name now as what it is trying to load), was modified, so it pops up a warning message, telling me that I will lose the drum map modifications if I allow the drum map to load.  SO, there is no way to save those changes, if I actually wanted to do that.

So, to me, it appears that CbB track template insertion logic, for track templates that include a drum synth instance, and a drum map, where there is already an instance of the same drum synth in the project where the track template is being inserted, is faulty, because it fails to internally adjust the naming of that drum synth instance associated with the drum map,  to match the altered instance name of that drum synth instance inserted into the Synth Rack.

Con someone please try to digest the above, and tell me if there is some better or different way of getting that dynamic adjustment to happen correctly?  Or do I just make manual adjustments and leave them modified for the project, but unsaved?  Is the lack of internal adjustment to the AD2 instance in the track template's drum map Output Port data a bug in CbB?

I would like to know - because I have to explain it all to my friend, and we have about a dozen such track templates to craft, and then I have my own to create for MY projects, so hopefully you guys can straighten me out. 

Bob Bone

 

 

[Colin Nicholls]

Okay, I haven't tried to reproduce the entirety of your example, but, prior to saving the Track Template, try renaming the instance of Addictive Drums in the Synth Rack so that it is not anything like the default, for example, "AD2-T" for the template. Then, ensure that all the ports and In/Out selections reflect this naming, before saving as a template.

Maybe that will be enough to allow CbB to differentiate between the existing or new instances of AD in the project, when loading in the template.

[Robert Bone]

1 hour ago, Colin Nicholls said:

Okay, I haven't tried to reproduce the entirety of your example, but, prior to saving the Track Template, try renaming the instance of Addictive Drums in the Synth Rack so that it is not anything like the default, for example, "AD2-T" for the template. Then, ensure that all the ports and In/Out selections reflect this naming, before saving as a template.

Maybe that will be enough to allow CbB to differentiate between the existing or new instances of AD in the project, when loading in the template.

Worth trying, in the morning, thanks.  12:30 AM and I think I turned into a pumpkin at Midnight - actually, more like a plumpkin.  DOH! 

Maybe nobody thought someone would bring in a 2nd instance of a drum synth, in a track template - but since they do already rename additional synth rack entries when there are multiple instances of the same plugin, ie Kontakt 1, Kontakt 2, Kontakt 3, etc.... and since they already know they are processing a track template, as the source of the additional instance of Addictive Drums 2, it sure seems logical to me that they could connect the dots, as it were, to name the drum map's Output Ports that were pointing to Addictive Drums 2 1 (1st instance of AD2 when drum map was created), to match the name of the instance of AD2 that they renamed from Addictive Drums 2 1, to Addictive Drums 2 2.

Would the above be considered an actual 'bug'?  Because, the CbB renaming of the synth rack AD2 instance, effectively 'breaks' the drum map - actually it results in the drum map pointing to the wrong AD2 instance.

Or, would asking the Bakers to adjust the drum map Output Port entries, so that they point to the renamed AD2 instance, be a Feature Request?

Or, do I need to learn more about drum maps, because I took a swing and a miss?

Bob Bone

[Colin Nicholls]

It sounds like a bug to me... but we'd need to work up a precise set of steps to reproduce I think.  Or possibly just a post-insert project that exhibits the problem, to be attached to the bug report.

I may give this a try today, if I understand your use case correctly.

[Robert Bone]

6 hours ago, Colin Nicholls said:

It sounds like a bug to me... but we'd need to work up a precise set of steps to reproduce I think.  Or possibly just a post-insert project that exhibits the problem, to be attached to the bug report.

I may give this a try today, if I understand your use case correctly.

Sure - observation - more to this than meets the eye, because I was just setting up a set of steps to reproduce, and I used SI-Drum instead of Addictive Drums 2, but it did not produce the problem, so I have to now ferret out why this worked, when my Addictive Drums 2 project exhibited the issues.

DOH!

SO - I will try to figure out why one worked and the other didn't, and when I get that figured out, I should be able to put together a set of steps for you.

[Colin Nicholls]

@Robert Bone, Here are the steps I followed; and the observations. Let me know if this is helpful.

1.0. New project; saved as "Template_Source_Project".

1.1. Added an instance of AD2 ("Addictive Drums 2 1") with 1 MIDI track and 16 mono outputs (from the AD2 mixer)

1.2. Created a new drum map, using one of my presets for AD2; ensured that the drum map note outputs were assigned to "Addictive Drums 2 1"

1.2.1. Saved DM as new preset "DM_AD_RBONE" prior to closing the Drum Map Manager

1.3. Assigned the output of the MIDI track to the new drum map.

1.4. Selected all 17 tracks as saved as Track Template "AD2_RBONE".

2.0. New Project;

2.1. Added an instance of AD2 ("Addictive Drums 2 1") with 1 MIDI track and 1 Audio output (Master Stereo). Left as default (no drum map involved)

2.2. Saved project as "Destination_Project_Pre_Insert".

2.3. Right-click, insert from Track Template, selected AD2_RBONE

2.4. Saved project as "Destination_Project_Post_Insert"

Observed:

• 17 tracks added to project.
• Synth Rack contains "Addictive Drums 2 1" and "Addictive Drums 2 2"
• The new 17 tracks are named "Addictive Drums 2 1" as they were in the source project when I saved/created the track template. (EXPECTED)
• Track 19, the MIDI driver track inserted from the template, has output assigned to "5-DM1-DM_AD_RBONE"
• In Drum Map Manager, we can see that the map note outputs are assigned to "Addictive Drums 2 1"

 

 

Expected:

• Well.... some might say that the drum map in the new project should be automatically altered to point to the second instance of AD2.

My thoughts:

• Conjecture: The Drum Map itself is not saved with the Track Template; only the NAME of the Drum Map preset is saved with the template.
• Therefore, when the track template is inserted into the new project, CbB looks around and finds a matching DM preset, and assigns it.
• CbB does not alter the DM preset as originally saved .
• CbB does not alter the DM entries in the new project.
• Once the user has noticed this "error", it is trivial to go into the DM Manager and hold down Ctrl-Shift and set all entries to point to "Addictive Drums 2 2"

I think this falls into the category of a "Feature Request" and the feasibility might be dodgy. Up to the Bakers, I guess.

Edited June 15, 2020 by Colin Nicholls
Added missing step 1.2.1

[Robert Bone]

When you created the new drum map, and you type its name in the Presets text box, then that enables the Save button, to the right of the Presets text box, and you need to save the drum map, and then create or overlay, the track template you had previously made.

So, if you did not do the above, then you may need to create the drum map again, in a new project that has the track template inserted, so create the drum map in that new project, save it, and again make sure the midi track Output is assigned to use that new drum map, and then again create or overlay the track template, which should now properly have the drum map in it, and you should be all set to run the test,

 

[Colin Nicholls]

So, having the custom template's DM saved as a preset means (theoretically) that it is then picked up during the insert template process. Hmm. I understand. Let me retry and I will update my post above.

@Robert Bone, okay, I've edited my post with complete steps, repro, and comments and observations. See above.

Edited June 15, 2020 by Colin Nicholls

[Robert Bone]

On 6/13/2020 at 11:06 PM, Colin Nicholls said:

Okay, I haven't tried to reproduce the entirety of your example, but, prior to saving the Track Template, try renaming the instance of Addictive Drums in the Synth Rack so that it is not anything like the default, for example, "AD2-T" for the template. Then, ensure that all the ports and In/Out selections reflect this naming, before saving as a template.

Maybe that will be enough to allow CbB to differentiate between the existing or new instances of AD in the project, when loading in the template.

Tried this, it named the 2nd instance with a '2', even though the name of the instance was quite different.

[Colin Nicholls]

6 hours ago, Robert Bone said:

Tried this, it named the 2nd instance with a '2', even though the name of the instance was quite different.

Yeah, now that I've gone through the whole process, I can understand why this still doesn't help. It was an off-the-cuff suggestion, and your detailed situation really warranted more attention. Sorry for the red herring.

I think I have to stay with my opinion that this is an unfortunate, non-intuitive edge case, but does not represent erroneous behavior. Once you know what information is being saved, and where, I think it has an acceptable work-around.

[Robert Bone]

1 minute ago, Colin Nicholls said:

Yeah, now that I've gone through the whole process, I can understand why this still doesn't help. It was an off-the-cuff suggestion, and your detailed situation really warranted more attention. Sorry for the red herring.

I think I have to stay with my opinion that this is an unfortunate, non-intuitive edge case, but does not represent erroneous behavior. Once you know what information is being saved, and where, I think it has an acceptable work-around.

I actually thought that was a great idea - renaming the instance before creating the track template - but CbB still internally knew it was an instance of AD2, so it still added the '2' anyways, thus breaking the connection between the track template's midi track associated MIDI track, and the AD2 instance brought in with the track template.

I was thinking your idea might work, actually, and I was rooting for you.  Alas - denied.  DOH! 

SO, it appears we are down to the notion of altering the drum map Output Ports for each of the rows in the map that are assigned to that AD2 instance, and just having unsaved drum map changes - I think that saving the project and closing it, with those unsaved drum map changes, would prompt for saving the drum map, which I would really not want to have to do,  because I would have to then overwrite the existing drum map, or end up with having to make the drum map changes to the output ports again, when I again load that project.  Neither of those two choices are good, so whether it is called a bug, or a feature request, I believe it has to change.

I believe the best solution, for CbB users, would be for the track template insertion logic to apply the same instance renumbering logic to the AD2 instance for the Output Port entries in the track template's drum map - so that the drum map Output Ports pointed to the same renumbered AD2 instance that was placed in the Synth Rack.

The above presents a problem, though, because however the Output Port entries get changed, whether by changes to the track template insertion logic, or if manually changed by the user, the drum map will have been altered, leaving that same issue of either having unsaved drum map changes, or having to overwrite the drum map to save the Output Port changes, or having to create a new drum map.

@Noel Borthwick?  @msmcleod Any thoughts on the above?  Seems like this is a bit of a mess to have to address.  Perhaps you guys have some alternative that would either fix or work around the above issues?

Bob Bone

[Colin Nicholls]

25 minutes ago, Robert Bone said:

The above presents a problem, though, because however the Output Port entries get changed, whether by changes to the track template insertion logic, or if manually changed by the user, the drum map will have been altered,

Only for that project. The DM preset would remain as it was when it was saved, I think, ready for other projects (and any project that didn't already have an AD2 instance, would be totally OK without mods)

[Colin Nicholls]

Actually the more I think about it, the more I feel that you probably don't need track templates at all - just a Drum Map preset that you can apply after adding the second AD2 instance via the Add Track Flyout, as per normal.

Unless you have other settings in the track template other than those used by our simplistic bug-repro examples...

[Robert Bone]

15 minutes ago, Colin Nicholls said:

Actually the more I think about it, the more I feel that you probably don't need track templates at all - just a Drum Map preset that you can apply after adding the second AD2 instance via the Add Track Flyout, as per normal.

Unless you have other settings in the track template other than those used by our simplistic bug-repro examples...

These have split outputs, so that the AD2 instances in the track templates, include audio output routing to separate output channels for each kit piece, plus that is done post-fader, so that the AD2 mixer fader settings can be part of the gain staging, in conjunction with the individual audio tracks and the gain control knobs for each of those audio tracks.

In addition, for the track templates, the AD2 instance for each track template uses a custom AD2 drum map - withing AD2, to map to particular note numbers for an electronic drum brain and midi trigger pads for that electronic kit, so yeah - these track templates are far more involved than just having a CbB drum map.

The nice part about doing these track templates, is that one only needs to be set up the first time I, or my friend, use an AD2 kit/preset that we hadn't used before.  Thereafter, by simply inserting one of the track templates, for perhaps the AD2 Studio Prog kit - and the Contemporary Prog preset withing that kit, we get: The custom mapping to an electronic kit, separate audio outputs from AD2 for each kit piece, all of the separate audio tracks in CbB, in a track folder, and assigned to pick up their input signal from the separate outputs from the AD2 instance, AND, all of the extra buses I set up for drums, (Kick bus, snare bus, toms bus, parallel compression bus, drums master bus),  AND, every audio track for the different kit pieces, is already set for gain staging, to the desired goal of -18 dBFS.

That is why these track templates were set up, because they save a BOATLOAD of work, other than just the intial work to create the track template for any new kit I want to use.

Bob Bone

 

[Colin Nicholls]

Gotcha, fair enough.

If I had a concise and clear way of describing what users need as a feature request, I'd submit one in the feedback forum...

I'd like to see a comment from the Bakers but I'm not holding my breath.

[Robert Bone]

2 hours ago, Colin Nicholls said:

Only for that project. The DM preset would remain as it was when it was saved, I think, ready for other projects (and any project that didn't already have an AD2 instance, would be totally OK without mods)

That issue is that because there would be unsaved drum map changes, they would have to be either abandoned when closing the project, or they would have to be saved, which would involve either overwriting the drum map, or saving the drum map changes under a new drum map.

If the changes were abandoned, then the alterations to the Ouput Port entries in the drum map, would have to be made every time that project was opened.

If the changes were saved to overwrite the drum map, then the drum map would have Addictive Drums 2 2 as the instance name pointed to in the Output Port entries, but then when that track template would be brought into another project, where there was NOT already an AD2 instance, then CbB would insert the AD2 instance into the synth rack, as Addictive Drums 2 1, which would not match the instance in the drum map associated with the midi track - problem.

If the changes were saved as a new drum map, then that would work, except firstly, there would be an eventual accumulation of pretty useless drum maps, that would literally only exist for the single project they were included in.  Secondly, for the project with the existing AD2 instance, and the 2nd instance brought in with the template, CbB would AGAIN adjust the synth rack AD2 instance from Addictive Drums 2 2, BACK to Addictive Drums 2 1, once the first AD2 instance was actually removed once the midi data was copied to the track template's midi track for the AD2 instance.  In other words, Addictive Drums 2 1 would go away, when it was removed after the drum midi data already in the project was copied over to the new midi track that came in with the  track template - and at that point, CbB would automatically rename the Synth Rack Addictive Drums 2 2 instance to Addictive Drums 2 1, because it would now be the only AD2 instance in the project, but AGAIN, this would break the connetion between the drum map Output Port data for the entries in the drum map - because those would have been manually altered to point to Addictive Drums 2 2 - when the drum map changes were made initially when bringing the drum map in with the track template.

I see problems with all of the above.

Bob Bone

[Colin Nicholls]

5 hours ago, Robert Bone said:

That issue is that because there would be unsaved drum map changes, they would have to be either abandoned when closing the project, or they would have to be saved, which would involve either overwriting the drum map, or saving the drum map changes under a new drum map.

I don't understand this statement. I don't think that is how Drum Map persistence works. Drum maps are saved with the project, you don't need to save them as a preset unless you really want to. At the risk of drifting off-scope, what am I missing? Let me explain:

I can create a new empty project; and create a new drum map, specific to this project (stored in the .cwp I assume) and any changes I make are persisted with the project when I save it. (It's called "DM-1").

I can close the project, open it again, and make further changes to DM-1, and save the project.

Now, at this point, if I want to use this Drum Map (as it is now) in another project, I can save it as a named preset by clicking into the preset name combo box; typing a name (e.g. "Test 1"), and pressing the SAVE button. Now, in addition to the Drum Map safely contained by the project itself, there is a separate "named preset" stored on disk ("Test 1.map") in the specified folder (check Prefs->Folder Locations).

Although the project's drum map name has changed from "DM-1" to "DM1-Test 1", it is not the same object as the drum map preset "Test 1".

From here, I can:

• Continue to maintain the Drum Map "DM1-Test 1" in the current project (and the name will get a * to indicate we have modified the project's DM further past the point of preset definition);
• Create a new empty project, and create a drum map using the previously saved preset "Test 1" to initialize it.
• Delete the drum map file "Test 1.map" from the preset folder without affecting the project's drum map (it is still called "DM-1 Test 1*")

...and so on.

Edited June 17, 2020 by Colin Nicholls
added bullet point about deleteing the preset .map file

[Robert Bone]

I don't even know which way is up any more, with this.  My poor brain has been running in circles - I am going to start all over later on today, after a good long nap, and try to figure out what is or is not a problem.  I have had difficulty getting to sleep, for the past 3 days - little 1-2 hour restless legs twitchy sleep sessions off and on - I need to get a clear head to reason through this properly.

Bob Bone

[Colin Nicholls]

Sorry Robert! I didn't mean to overwhelm you.

I reviewing the manual on this subject, and frankly I think it is confusing.
https://bandlab.github.io/cakewalk/docs/Cakewalk Reference Guide.pdf#G17.1089162
 

Quote

 

Drum maps used in current project

This field displays all the currently available drum maps. click the New button to create a new drum map and Delete to delete a drum map. Select a drum map to display the drum mappings in the Drum Map Manager. All drum maps in this field are saved with the current project.

Presets

Presets can be used to populate the fields in the Drum Map Manager. This field is also used to save new drum maps by entering a name in the field and clicking the Save button.

 

I think that bolded last sentence suggests that you are naming the drum map in the project, but what it is really doing is saving a preset with that name so you can use it in other projects. The Project Drum map name change is just a side-effect.

I'll stop there. Good luck, Robert.

[Robert Bone]

Not sure what you meant by 'The Project Drum map name change is just a side-effect.'  Please clarify - sorry