- I think it’s a particularly potent adding. This is where Dorico’s X-Maps can come into play. An X-Map for GA(SE) can be used creatively in the score: e.g.: Intro(1-4) or Main(1-16 ) or the intensity as a 2nd dynamic controller and much more …
2 Likes
Oh this is an interesting idea, but not sure I understand exactly, can you give an example?
I think he means one could use custom playing techniques and instructions linked to an expression map to trigger pattern pads. Since expression maps can send held or momentary keyswitch events it’s no problem.
1 Like
“next week take a look at this - elaboration”
I havent looked at the project and it might not be the problem, but it’s something to watch for…
Sometimes pattern and instrument pads have the same trigger note set and conflict.
To fix this set pattern pads to receive on a different port/channel.
Hm, not following. All the pads have to use the same triggers - MIDI notes, correct ? As evidenced that there’s a single piano keyboard on the bottom of the VST which triggers the different samples. Also it would be chaos and none of this would work if pads had different trigger sets.
The pads aren’t triggering here, I dragged the pad over which copies the MIDI into Dorico as music, which then in playback routes to the VST normally, with the Maps it appropriately triggers the correct samples.
A little spot checking of the regular map looks good, I suspect the brush map has a few issues is all.
Usually not a problem. It’s just something to be aware of, as some kits might well load up in a way where Instrument Groups can Conflict with Pattern Groups.
Examnple:
I’ve loaded a kit and pattern group called “Samba Trap” (This one is from the “Beat Agent” Library).
Notice it has some bass sounds assigned to pads G#1-B0 in the instrument tab.
I click the Pattern tab, and notice there are also Pattern pads assigned to G#-1 - B0.
By default GA SE seems to be in some sort of Omni mode (can accept over any channel), and accepts triggers for Pattern pads over the first GA MIDI input over any channel, so when the host sends G#-1 - B0, GA gives priority to the Pattern pads. User is expecting to hear bass bits, but instead hears an unexpected sound of the patterns triggering. He’s wondering why he can’t play the bass!
This is what I mean by pads ‘conflicting’.
To resolve the conflict one has options.
-
Set the patterns to be received over a unique GA MIDI input (port) by toggling this little icon on. (Some hosts might not support a plugin having multiple MIDI Ports)
-
Change the MIDI Channel that GA expects to be used for triggering Patterns.
right click here:
and pick a unique MIDI channel.
-
If the project isn’t using patterns at all, simply disable the pattern group.
Optionally one can empty out the pattern pads as well.
a. Right click a pattern pad.
b. choose reset all pads.
Now the pattern group is empty.
- Remap trigger events for conflicting pads. Usually not necessary, but it’s possible to remap the trigger events for any GA pad by toggling ‘use hardware controller mapping’ on in the instrument tab (little octagon icon with drum stick at lower right of the MPC layout), and right clicking a pad (works for both instrument and pattern groups).
1 Like
Ah, I took a closer look.
Loaded the same kit you have showing.
Yes, on this kit, it’s possible to suffer the trigger note conflict I’ve described for instrument pads C0 - B0.
Thanks, Brian, as ever. But on a Mac, I can’t load the vstpreset. Even browsing to the files in GA’s file browser, it just doesn’t appear.
Ah OK I’m seeing a little here, the confusing bit is that it doesn’t have pattern pads, but instrument pads which seems like an odd feature but anyhow. So GA works in that you can trigger the pads, or the instrument itself, and those can conflict which seems like a design flaw to me but anyhow.
Right, however turning off the pattern player as you said doesn’t fix it
Also that crash is C#2, not C0-B0
Which maps in the P-map as to the snare
But is imported into the score as a crash
So I’m corn-fused … Other than the P-map which is confusing me here with the C#2, Dorico is playing it back correctly, it’s just that the pad I imported from GA doesn’t have a C#2 in it. So where did Dorico get this from?
In GA press that Main 2 pad and watch the keyboard, C#2 isn’t hit and there’s no crash
FYI for the default setup in Dorico 5 the MIDI trigger regions trigger the patterns on MIDI channel 2 so that they don’t conflict with the Instrument pads. If you’re doing a manual setup then yes you might need to check the channel settings.
1 Like
This is because I need to map the ‘beater on’ to the drum kit. It’s still mapped to a ‘very low’ bass drum and that’s not in the kit definition so Dorico doesn’t know what to do with it…
I’ll change it and report back.
2 Likes
Great thanks John, that makes sense.
In other news I keep getting this error
FYI if you get that change the settings shown, best to double click Max Preload and setting it to 2000 MB works well (it’s maxing under 1600)
Perhaps, but it’s more of a necessary evil when considering the ‘evolution’ of the product. Had the entire plugin and all the content for it been developed fresh and entirely in the VST3 realm things might well look and work a bit different. Reality is that the plugin was born way back in 2009 with Cubase 5.
Groove Agent One was purely a MPC style kit player intended to complement Cubase/Nuendo. It came about before Cubendo had a ‘sample track’ of its own. Users could use Groove Agent to quickly and easily insert samples of choice into their projects and trigger them with ease and precision.
It didn’t host ‘loops/patterns’ at all internally. The user did all that in the DAW itself.
There was no such thing as VST3 protocol.
The concept ‘evolved’ to get the pattern and groove engine bolted on. VST3 didn’t exist yet. Many hosts of old couldn’t cope with ‘extra MIDI inputs’ at all.
As more features and abilities were added, that also introduced various possibilities for conflicts between the pattern and instrument pads to occur.
Of course, these things can be fixed in the GA ‘settings’, and/or kit or multi-kit presets themselves (how they are set when loading a kit), but it’s a general practice to leave the older presets ALONE and NOT ‘update/change’ them unless it is ‘vital’ to keeping them ‘functioning’ in newer hosts/OSes/etc.
Why? Legacy support. People open older projects and they don’t want things to be any different than their ‘original form’.
It’s a coin toss I guess. Steinberg could alter ‘default settings’ and even go back and revamp alot of those ‘kit presets’ so they take advantage of the newest hosts if they wanted (move the patterns, change the defaults for how they work, etc). Either way, people will complain.
End of the day, the plugin has what a user needs to ‘get it working’ in projects for all sorts of hosts, both ‘old and new’.
Some ‘design flaws’ are more like ‘bridges and solutions’ as ‘progress’ marches on.
1 Like
Yeah that was exactly my thinking, but it’s still a design flaw because they never redesigned it. FWIW my day job has largely been in software architecture, often for legacy systems, and I can spot the history of a app right away from it’s interface. DAW’s are a horror show, the problem is management never understands that starting from scratch is more often better than reusing some old train wreck - they always opt for repairing the haunted mansion (Conway’s Law is the other flaw - they never structure the teams properly).
I keep saying it but that’s why we’re so lucky here, these guys got a chance for a ‘do over’, which I’ve never seen happen. I get so much pleasure from using just for that reason.
I can feel your pain and see your side of the argument, but at the same time…one of Steinberg’s biggest selling points over the decades is that to this day, it still works with products that were introduced way back in nine-teen-eighty weird! Legacy support in Steinberg world has been way above average for the industry, if not ‘excellent’ in most of their products.
It can do things, and communicate with hardware that all the others ‘never could, and never will’.
If you ‘start from scratch’, all that legacy code is LOST.
Case in point…
Try to get ‘newer DAWs’ like Bitwig, or Live to work with real time sysex, RPN/NRPN stuff…good luck with that!
When I first started shopping for a DAW for Windows or Mac to replace my old Atari stuff, I looked at Mix Craft and loved it! Until, I wanted to hook up my ADAT, several tone modules and sequencers, and sync it all up. Didn’t have that code (MTC, SMPTE, couldn’t master or slave with any of that stuff), and never will.
To compound issues, there was General MIDI, but every dog in the race was competing to extend the protocols and standards in different directions, for different reasons. Roland did GS. Yamaha did XG. On and on the squabbles went on over which protocols and standards to embrace. DAWs were expected to have a go at supporting it ALL.
Add that the same people who’d spend 6k for a synth that could only make a few tones at a time, and another $200 for cables to hook it up would complain that $400 was just WAY TOO MUCH MONEY to spend on ‘software’.
Telling a musician that he can’t use his DX7 anymore without sacrificing a LOT of the features and abilities that DAWs and Sequencers could do 20+ years ago is kinda like saying, “Your 17th century Stradivarius Violin is obsolete! Trash it!”
Now days it’s true that a lot of that old equipment has been somewhat duplicated or re-imaged into all software products, but this has taken TIME. It hasn’t been cheap. And markets for the stuff are somewhat limited and niche (efforts involved might never really recoup the costs of doing so).
Give it another decade or so, and I think you’ll see more hosts get a ‘fresh start’, as by then, pretty much anything we once needed ‘black boxes and lengths of cable’ to do will come in a purely ‘software’ form (and be very affordable)…that adheres to some common ‘communications protocol’.
1 Like
Nope, that’s a solvable problem, been there done that on systems with 5+M SLOC which cost over a million a pop. Anyhow we digress …
I’d like to hope so, but case studies and personal experience are to the contrary. Look at VW, their train wreck is taking town the company with their EV system software and they’re still whacking at moles.
LOL: I use my DX7 to input MIDI into Finale, Dorico, and Cubase. 
1 Like
Ummhumm.
And they’ve been solving it by keeping the old code alive when they can. Funny that the ‘old code’ is often faster and way more efficient anyway, even if it’s running through ‘sand-boxed emulation layers’ (takes 16k to do things that modern software won’t even launch with no less than 4meg).
You had access to the code, and maybe even the people who originally wrote it. You had the spec sheets for how everything was supposed to work. Data on the various models and production runs.
Not always the case in the music/audio tech world. Especially with ‘host’ software. You can control the ‘communication subset’ between various ‘third party’ plugins, but what the various plugin developers do beyond ‘communicating/streaming’ with the host is ‘out of control’. Ya send out a dev kit for VST or whatever…but third parties can still do their own thing behind the com protocols. They can still ‘misinterpret’ how things should work. Etc…
Like the dreaded day when the ‘drivers’ break for a perfectly good piece of hardware. Even if someone with a little experience in cracking drivers and making fixes CAN and WILL do it…there’s still ‘legal issues’, distribution rights, work arounds with ‘driver signing’ so the kernel doesn’t reject it, and the list goes on.
So what does the typical modern DAW dabble with?
MIDI and it’s gradual evolution of ‘standards’ or lack thereof.
VST (several variants)
AU
ATX
WAV
AIF
MP3
MP4
AVI/MOV/ETC
XML
Dolby
ARIA
ATMOS
THX
GS
XG
ASIO
WDM
SMPTE
MTC
ADAT
SPDIF
Scads of remote controllers and all their protocols (Makie Univeral as one out of many examples).
Now people are even demanding analogue continuous voltage options in ‘modern daws’ at better/higher resolutions than MIDI can support…various companies are ‘competing’ to be the standard bearer (and perhaps nail down some patents along the way).
I could sit here all day and keep adding stuff to that list! Support it or no one wants the DAW, yet you have ‘limits and rules’ as to what you can change/redo. Various protocols and such to contend with…some of which might have libraries that are NOT open source (and even if you have the source you can’t change it without expensive-to-get permission).
So if you ‘start from scratch’…that’s many hundreds and thousands of ‘man hours’ in code, hardware, etc…
If one company had to ‘redo ALL of these protocols’ from scratch, it’d take all kinds of time. Cumulatively, all that stuff is many thousands of man hours, and millions of dollars in dev costs.
Sure, for some types of software you can recompile some things in newer compilers with some different flags. Set up some emulation stuff. Etc…but with a typical DAW, that’d get crazy complicated rather quickly!
It still has to be able to work in ‘real time’. Newer processors and motherboard get new instruction sets, but people still expect the stuff to run on older processors, and so on. Not so simple to release something out into the ‘wild’ that can be well supported on such a huge swath of possible user setups.
1 Like
Dat’s my point 
‘old code’ is often faster and way more efficient anyway
Sure but it comes with other burdens and issues, namely that it becomes a fossil and all that literally implies.
Yeah look, I’m a tired old hand at this stuff, appreciate the thoughts but there’s nothing new here and I could give you a dissertation on it if you wanted. Point is, I’m retiring to spend all my time in another useless activity which is composing!
1 Like