Thanks Paul! Since yesterday, I created one myself and after much trial and error, got it to work. I should have waited a day. LOL I figured out that the trim was needed, along with the fact that every slot had to be accounted for. The concatenation was easy enough, but I like your vlookup better than what I did on the fly. The only problem that seems to persist for me with both my spreadsheet and yours is that extra commas are generated at the end of lines 1 & 2 of the CSV after export. It’s easy enough to edit out with a text editor but would be nice if I could skip that step.
I’m really trying to wrap my head around the best way to manage my drum maps across projects since I do a lot of drum editing in Cubase rather than BFD 3.5. Plus, I now have an Alesis Strike Pro kit in my (small) studio for when I have players in, and would like to center my maps around that kit along with additional kit pieces and all articulations available in the Cubase DRM for access when editing. Hopefully, I can have one primary DRM file that can be applied to most or all BFD presets that will translate. I think I might be there, but haven’t really put the process through enough paces to be 100% sure. I think where I was getting into trouble was that some of my Cubase projects were created and edited before I had my DRM in place. I’m not sure that I have a way to translate those maps to mine, so I’m probably out of luck for any after the fact standardization.
My plan would be to have one DRM setup with the full kit, including some standard percussion pieces/slots and then build additional DRM files for special percussion separate tracks. Obviously BFD 3.5 presets don’t always include as many kit pieces as I have in my DRM, but so far the translation seems that it might be OK and added pieces fall into place well enough with the mapping already configured in the DRM file.
Thanks again, and if you happen to have any thoughts about what I described above, I would love to hear them.
I can’t say with certainty that all BFD3 drum kits use completely consistent mapping, but I have confirmed that drum maps for 8 widely selected presets from the Core Kit match up with presets from Crush, Dark Farm, Horsepower, Jazz Noir and Oblivion.
The BFD3 manual includes a short chapter titled “BFD3 Key Map Reference” which lists the default key mapping used by the software.
Can someone please help me? I discovered “CubaseDrumMapEditor” thanks to this post, but I have a problem.
When I export a drum map from the program in CSV format, it’s ok.
But when I open the drum map with Open Office Calc, I change the name of a sound, save it…
If I import the CSV file into CubaseDrumMapEditor, I get the error you see in the photo.
Maybe I’m saving from Open Office Calc incorrectly, or am I opening the file incorrectly? In the other photo, you can see how I load it. Maybe I’m using the wrong font? The hyphenation options?
Thank you very much for trying out CubaseDrumMapEditor and for sharing the details of the issue.
I really appreciate you taking the time to test it and report this behavior.
I’ll investigate this problem and see what’s causing the error when importing CSV files saved from OpenOffice Calc.
Please give me a little time — I’ll get back to you as soon as I have more information.
Hi,
The error happened because after editing the CSV in OpenOffice/LibreOffice Calc, some number fields were saved as blank cells. The app couldn’t read those blanks and showed an import error. We’ve updated the app to handle CSV files from Calc correctly (blank numbers are now handled safely).
Hi,I appreciate your effort and the idea, unfortunately as you can see, as soon as I change the name of a sound on open calc, when I import the list on your program it still gives me an error, I don’t understand
I also don’t understand why, when I open a Cubase list from your program to edit it, the list is read in a different order, not the correct one. I haven’t found a way to manage the order with your program; the order I use follows the notes on the keyboard:
C1, C#1, D1, D#1, E1, etc.
Sorry for the many messages but I’m testing, so the first problem seems to be solved, because I removed the “Tabulation” option, now if I import the CSV, the program reads everything correctly
Now there is an even more serious problem, the list created on your program is not read correctly by Cubase, as you can see in the photo on the left, the list that is seen in your program is completely different from the one that is seen on Cubase on the right, it seems that Cubase has copied or read the sound “TEST 14” for several times, God how frustrating all this is
Hi, In your screenshot I can see the leftmost “Display” column showing many duplicates (e.g., several C-2 entries). That column must not contain duplicates or gaps.
Because my tool keeps the Display column read-only, any duplication must already exist in the drum map or CSV file you imported. Could you check, in Calc or any other editor, whether rows were copied or otherwise modified so that the Display column now contains duplicate values?
Hi, I also noticed these duplicates, but it is a problem between Cubase and your program, as you can see in the photo, I created a map on Cubase JUNO-D Test 13-10, I imported it on your program, but it is imported with all those duplicate values, inside the Display column, I don’t understand
Hi,
We discovered a critical misinterpretation of Cubase’s DrumMap specification that was causing data inconsistencies. The issue has been resolved, so please try the new version. Data exchange between Cubase, this tool, and CSV editors should now work seamlessly.
Here I am, I appreciate your effort, but I’ve found another bug.
So now DRM import and export between your program and Cubase works.
However, I have a bug when I export the CSV file to work with Open Office Calc. When I decide to import the file back into your program, the “Display” column is messed up or out of order.
This only happens when exporting and importing, without necessarily opening the file and editing it with opencalc.
Thank you for reporting this bug.
The issue has been fixed. The problem was that when importing CSV files, the Pitch values were being reset to sequential row indices instead of reading the actual Pitch values from the CSV.
Hi, everything’s finally okay now. I’m happy to have helped improve this software. It seems strange to me that no one has encountered these problems so far. Maybe only a few people use it?
Thank you for everything. If there are any other problems or suggestions, I’ll let you know. Have a good evening and enjoy the music.
