Doktor Avalanche
At risk of sounding like a smartarse, I've done QA professionally for years. If I saw in the fix list something about drum maps templates being fixed during a save, the first thing I would have done is test the save/load functionality everywhere for drum maps.
That's not to put down Cakewalk QA, they simply may not have been given the time to test it, although the bug would probably have been uncovered in less than an hour with basic tests.

Yeah, the drum map issue is a great example of a "holy crap, we shipped that?" moment. I've sure had my share of those and I feel bad for the PM and QA guy who owned that piece. That being said, I sincerely doubt it was because of time pressure. If a fix isn't ready to ship, it doesn't ship, period. Every person in the industry knows the consequences of doing otherwise. I won't speculate about why it shipped that way or Monday-morning quarterback their process execution, but I'm pretty confident that Noel knows why, and that some efforts are underway to fix what went wrong.

Noel Borthwick [Cakewalk]

kevinwal
I don't mean to belittle anyone's considered and well articulated opinions here, not at all, but holy crap, it's only been four months! I'm amazed and impressed that Cakewalk is getting it so right so quickly out of the gate. That tells me that they must have been an agile shop (or at least semi-agile) for some time internally. Yeah, maybe the release management side might have had a few burps, but as with playing a musical instrument, you just get better at the stuff you do really frequently, so I expect that aspect to improve over time as well. And I'll bet my next two paychecks that the drum map project loading scenario is now part of the formal regression test suite, lol.
 
Most of all, I am hugely impressed that the executive leadership approved such an audacious program to go with the transformation to a "membership model" when they could have done something a lot less aggressive and let the buckaroos roll in for a while.

 
Hi Kevin,
 
Thanks for your understanding. Your points are pretty spot on. Though we don't follow the "traditional" agile methodology, we have been agile for at least 8-10 years in the way large features are developed. i.e we split them up into milestones and each milestone was internally tested like a shipping product. So we had dev and QA cycles all through the year. From this year as you know the big change is to release features as they become available - i.e. when the final milestone for that feature is complete as opposed to waiting for ALL features to be complete.
Drum Replacer for example had several internal milestones or mini releases as you could call it - the DSP, the UI the integration/ARA, MIDI, code Refactoring, etc. 
 
We experimented with releasing smaller updates several years ago - even before X1 if memory serves me, but didn't have all the delivery and support infrastructure to do that at the time, so it wasn't very successful and met with internal resistance. The final approval to switch to this system came from no other than Henry Juszkiewicz our CEO, who is a really savvy forward thinking technical guy (you wouldn't expect that from a CEO of a guitar company!) besides being an avid SONAR user himself and a business genius. What allowed us to attempt this finally was building the whole delivery infrastructure for this model which is key to making it all work. We still have some growing pains obviously but we now have infrastructure to allow us to be orders of magnitude more responsive and release updates quickly. In one of the first releases we shipped a point update two or three days after including the development, testing and release management. As you probably know fixing bugs is easy its the test, approval and release management process (X versions of windows, localization, Y languages, etc) that is the typical bottleneck in such situations.
 
 

It's looking good from where I sit, Noel, my sincere complements to your team.

Noel Borthwick [Cakewalk]
The final approval to switch to this system came from no other than Henry Juszkiewicz our CEO, who is a really savvy forward thinking technical guy (you wouldn't expect that from a CEO of a guitar company!) besides being an avid SONAR user himself and a business genius.

Is Avid buying Sonar now?  Who knew?
 
:)

brundlefly

Bristol_Jonesey

Kylotan

brundlefly

Kylotan
WE CURRENTLY CANNOT USE THE DRUM MAPS AT ALL.

Shouting something does not make it true. If you reload the map, or reset the output of just one note number, the map will start working. It's only on initial load of a project with an existing map that they don't work. Yes, this makes switching projects frequently kind of a pain, but it's far from unusable.

So, you found a workaround, well done. This is hardly obvious and I wouldn't have found it myself. At the point where I posted, as far as I was concerned, this was true - the drum maps were not working, at all, in any project.

I'm afraid this isn't a workaround, at least it doesn't work for me.
I've tried with 3 different projects so far with zero success.
 

 
Sorry, I've been busy, and didn't have a chance to check back in. All I know is that when I saw the port/channel was blank at the bottom of the map, my first thought was to reset output ports, and I started by just doing one. When I saw port/channel was repopulated by doing that, I tested playback and found the whole map was working again. I tried one other project, and it worked there as well, so I'm not sure why it didn't work for you, but I would guess something else is going on in addition to the port assignment issue in your case.
 
I didn't realize no one had yet posted any workaround at the time or I would have been more gentle in my response. 
 

No need for any sort of apology. The first time I opened up a map which wasn't working, one of the keys had been reset from BFD2 to Rapture. Resetting the output port to BFD cause the map to work normally.
I then saved the project, closed it to do something else. When I reopened it, the port had gone back to Rapture, but setting it back to BFD this time had no effect.  I could trigger notes from within the map but not by running the transport.
That's the extent of my analysis so far, but I will carry on experimenting and see what happens

I haven't seen the ports reset to anything. Just blank.

I'd rather have a broken product and more updates monthly if you ask me.

Update:
 
I've just been experimenting with the dRum Map problem and I've found that if I select ALL of the output ports and reset them to BFD *even though they all currently read "BFD"* then the map triggers properly when running the transport.
 
So this is a workaround that does work for me.

Im still waiting for loop recording to be fixed

alewgro
I'd rather have a broken product and more updates monthly if you ask me.

Why?

Bristol_Jonesey
Update:
 
So this is a workaround that does work for me.

Does it still work when you reopen the project?