NDSP Quad Cortex

Translating a user preset from plugin to QC seems like it should be relatively simple. Especially so because they already translated all the factory presets. Because NDSP hasn't built the most trustworthy record, the fact that they didn't also do user presets at the same time seems...odd

200.gif


Translating a preset from plugin to QC makes a ton of sense. There are plenty of bands who record with tones they want to then tour with.

I think translating a preset from QC to plugin could be quite the task, and I don't even see it as particularly desirable. I could see it working if you could create a preset with a "style". So QC style, Plini X style, Gojira X style, etc. The styles/templates would lock you into those signal chains. Seems possible, but not particularly useful imo.
 
But the whole selling point of the NDSP plugins is that they're pretty with brand/artist brandings.
Is it? I thought it was that they sound great, are easy to use, AND are pretty with brand/artist brandings. If they were just pretty and branded and sounded like ass and were a pain to use they wouldn't sell well at all. Probably.
 
I don't really know how to reconcile these observations. To me, it all boils down to: what exactly was JNC expecting or hoping for? A full-screen recreation of each plugin? How would you manage mixing/matching and routing in that scenario? Thematically matched parameter pop-ups on the QC screen? White space, color selections, etc. would likely detract from usability on a screen this size.

NDSP needs to get the preset thing resolved. It's going to be a round peg/ square hole scenario, and these are usually solved by compromising for least-common denominator. IMO support of multiple plugin suites on one monolithic MFX device was a "be careful what you wish for" proposition from the word go. It would have been an entirely different proposition if there were a single QC plugin suite inclusive of everything on QC, a la Helix Native. In absence of that, early adopters would have been better served by demanding more discrete native blocks be added to the QC, and encouraging NDSP to drop pursuit of plugin "compatibility" altogether. But that's all water under the bridge now.
JNC hasn’t been using the QC for multiple years, obsessively discussing online about how the plugin compatibility will be implemented—that’s you and me. So yeah, he’s gonna take a look at the plugin implementation like a normal person and have the response of “meh, feels like it could’ve been better” for the same reason your assessment is "a round peg/ square hole scenario… be careful what you wish for.” You’re criticizing him for… what exactly, not being you or me? ¯\_(ツ)_/¯
Is it? I thought it was that they sound great, are easy to use, AND are pretty with brand/artist brandings. If they were just pretty and branded and sounded like ass and were a pain to use they wouldn't sell well at all. Probably.
Instead of pretending I wrote one sentence, read the rest and it’ll make sense. :hugitout
 
I think they do have an incentive: If the hardware doesn’t compete with the competition in the same pricerange, they will go out of business. No matter what goodies they sell in the plugins…if the hardware standalone doesn’t compete…game over. For this same reason, i have little worries that all the good stuff will end up behind a pay wall.
They are in a business where the competition goes forward…if you don’t have development teams building their expertise today….you will not be capable to catch up tommorow.

Besides that…even though there is a usergroup that would buy the QC again as is today (me included), there is obviously a market out there that demands content in higher quantities. If you have the hardware, and the capabilities to create that…that’s low hanging fruit any business would want to harvest.

Plus…they were very clear in their ambition…I’d expect them to have learned their lesson what raising false expectations cost. TINA is about creating accurate models…which in my mind means aimed at creating Coros amp models..cause their plugins are more about artist sounds.

In my mind the odds that they gonna hit the turbo button look good…time will tell
I hope so , honestly I think if they could just have one good update at quarter , that would be a resonable time frame that no one could complain or 3 a year every 4 months , I am curious to see what they do as they are promising new and amps and devices
with 3.2 show up with a Tone King Imperial , Fortin Spring Verb , Synth in other words are they going to start grabbing single items from the plug in inventory to address the quick content turnaround
 
Translating a user preset from plugin to QC seems like it should be relatively simple. Especially so because they already translated all the factory presets. Because NDSP hasn't built the most trustworthy record, the fact that they didn't also do user presets at the same time seems...odd

View attachment 26173

Translating a preset from plugin to QC makes a ton of sense. There are plenty of bands who record with tones they want to then tour with.

I think translating a preset from QC to plugin could be quite the task, and I don't even see it as particularly desirable. I could see it working if you could create a preset with a "style". So QC style, Plini X style, Gojira X style, etc. The styles/templates would lock you into those signal chains. Seems possible, but not particularly useful imo.

Yeah QC to plugin I get it because you could be including blocks not in the core plugin or in a different signal path. But Plugin to QC is using a fixed signal path, blocks that would be present on the QC, and presumably is one of the main selling points of plugin integration. (syncing your recording presets) They also have the cloud infrastructure to store the presets to user accounts. :idk

There must be some other technical hurdle that they didn’t feel was worth holding up everything over.
 
JNC hasn’t been using the QC for multiple years, obsessively discussing online about how the plugin compatibility will be implemented—that’s you and me. So yeah, he’s gonna take a look at the plugin implementation like a normal person and have the response of “meh, feels like it could’ve been better” for the same reason your assessment is "a round peg/ square hole scenario… be careful what you wish for.” You’re criticizing him for… what exactly, not being you or me? ¯\_(ツ)_/¯

Instead of pretending I wrote one sentence, read the rest and it’ll make sense. :hugitout
I'm not criticizing him; I'm just saying that his observations aren't fully thought out. Which you're also saying, albeit from a different angle.

When someone tells me they don't like something, I always press them to tell me what they would like instead.
 
Yeah QC to plugin I get it because you could be including blocks not in the core plugin or in a different signal path. But Plugin to QC is using a fixed signal path, blocks that would be present on the QC, and presumably is one of the main selling points of plugin integration. (syncing your recording presets) They also have the cloud infrastructure to store the presets to user accounts. :idk

There must be some other technical hurdle that they didn’t feel was worth holding up everything over.
So I'm looking at the Plugin Presets on the QC (which I really wish wasn't cordoned off away from the other Preset libraries, by the way) and I see that the layout of blocks on the rows is always identical: pre-effects on row 1; route to row 3; row 3 is amp/ cab/ post-effects in a fixed order. All NDSP has to do is write a function that confirms this is so in any given QC preset. If and only if a preset has this "thumbprint", it should be easy enough to transfer back and forth between the plugin.

I say "easy enough" knowing full well that that's what you say to enrage a software developer. (See also: "why don't we just...") What I mean is, it's certainly possible. :D
 
Plugin Presets on the QC (which I really wish wasn't cordoned off away from the other Preset libraries, by the way)
Speaking of which... I can't find anyway to select Plugin Presets from Cortex Control. Am I missing something obvious here? Can it be that this is actually not possible??
 
So I'm looking at the Plugin Presets on the QC (which I really wish wasn't cordoned off away from the other Preset libraries, by the way) and I see that the layout of blocks on the rows is always identical: pre-effects on row 1; route to row 3; row 3 is amp/ cab/ post-effects in a fixed order. All NDSP has to do is write a function that confirms this is so in any given QC preset. If and only if a preset has this "thumbprint", it should be easy enough to transfer back and forth between the plugin.

Seems like it might be a support nightmare “why aren’t my presets syncing to the plugin”…

”you aren’t running it in the required signal flow”
“you’re using a block that’s not in the plugin”
“you’re John Cordy”

I think it would be cool with the right user education though. Plugin to QC syncing though eliminates all those variables.
 
Seems like it might be a support nightmare “why aren’t my presets syncing to the plugin”…

”you aren’t running it in the required signal flow”
“you’re using a block that’s not in the plugin”
“you’re John Cordy”

I think it would be cool with the right user education though. Plugin to QC syncing though eliminates all those variables.
I think this might be why the Plugin Presets were cordoned off in their own menu section, though. NDSP could make those and only those QC presets transferable between the plugins, and make it impossible to move blocks, change routing etc. while using those Presets.

Now that I'm paying closer attention, I think this is where they're headed. When you're working with a Plugin Preset on QC, you can't save it in place; you can only save it to a different location in the (non-plugin-specfic) Preset folders. So I'm guessing "Plugin Presets" will be like a staging area that will transfer back and forth with PC/Mac plugins, while potentially more inclusive/ less compatible presets will be saved off to the previously existing Preset Libraries. Kind of weird... but functional.
 
Back
Top