No drum maps for GA1’s new content ?
Were there drum maps for previous content?
I am on mac.
Bought the full version of Cubase 7 (boxed).
Installed it and then Cubase 7.01 update.
I only can choose the GM drum map.
There seem to be no other drum maps installed.
When i insert GA1 on a instrument track and want to use a drum map for a GA1 preset, i can only choose the GM map.
On the Cubase 7 install DVD, there was no additional content (say: drum maps) to install, AFAIK.
Also, odd that there is no default cubase folder to place drummaps in.
While there are default folders for project templates and so on.
Sorry to say but Steinberg could have done a better job about drum maps, it’s all confusing for me.
Just my 2 cents.
I’d like to see a standard Percussion Map installed as part of the program but alas this would require industry agreement.
You mean besides the industry standard GM Drum Map that the industry agreed on.
GM2 should do it.
GAO1 already does
Instead of just needling emotive, here is the deal. You are confusing the concept of an industry standard map which already exists, with the layout chosen by the people making the kits and their choice of ignoring that standard. Yes, it would be nice to get a map for each kit, but it also doesn’t take that much effort to use an old map and edit for the kit. I mean seriously, they are small maps. Try keeping maps for fully articulated kits in SSD, BFD etc…
That’s right, and that’s why a custom XML editor in Cubase would be a solution.
After all Cubase is meant to be a pro application for pro users, and yet we “need” to use a clunky application UI to make important adjustments to settings, whether they are within a single project or project wide.
Surely this can be developed as an interface similar to the preferences/key commands window(s).
Look at programs such as XMLSpy, each field is an entity and a number of options can be selected from a list or changes can made directly to the data, with multiple choices using attributes.
It’s just the thing what Cubase needs in my view.
There’s already an XML editor in Cubase specifically for building drum maps that is faster than using an xml editor. XMLSpy would be a horrible solution to a single element problem. Open the damn editor and type in a name for each key. If you want to use xmlspy, open the drum map in XMLSpy and edit away. It is XML after all.
<DrumMap>
<string name="Name" value="BFD XFL - WFL 1958 Kit"/>
<list name="Quantize" type="list">
<item>
<int name="Grid" value="4"/>
<int name="Type" value="0"/>
<float name="Swing" value="0"/>
<float name="MaxDiff" value="0"/>
<int name="Tuplet" value="1"/>
<int name="Move CC" value="0"/>
</item>
</list>
[quote=“]JMCecil”]
XMLSpy would be a horrible solution to a single element problem.
[/quote]
I am merely offering up an example to demonstrate that due to excellent, forward looking support in Cubase (and steinberg apps in general) for XML, it makes sense to develop a global editor for those who’d rather not mess round with copying files from install to install or who would rather retain some familiarity around program usage, as any files generated would be wholly compatible, i.e. there would be no parsing errors, sharing via networks is simplified and binary information can invoke external applications.
I am merely offering up an example to demonstrate that due to excellent, forward looking support in Cubase (and steinberg apps in general) for XML, it makes sense to develop a global editor for those who’d rather not mess round with copying files from install to install or who would rather retain some familiarity around program usage, as any files generated would be wholly compatible, i.e. there would be no parsing errors, sharing via networks is simplified and binary information can invoke external applications.
[/quote]
You are so full of crap. And Im an idiot for responding.
Is the issue here really personal, e.g. what Cubase represents to one person but not another?
The application can be anything it needs to be and there is nothing stopping the SB talentfull developers from implementing new solutions to long standing problems.
Many users have expressed frustration around having to delve into the application data folder and remember, it’s not about engineers vs dj’s.
Not to mention, requests for finer-grained preference editing.