NDSP Quad Cortex

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.
 
Can anybody explain 3.0's Dynamic Latency Compensation to me as if I were an idiot? Or maybe as if I weren't an idiot? What exactly is it doing, I mean.
 
Can anybody explain 3.0's Dynamic Latency Compensation to me as if I were an idiot? Or maybe as if I weren't an idiot? What exactly is it doing, I mean.

Every block introduces latency to the signal path. If you run multiple paths in parallel and the total latency is not the exact same for all, you'll start getting phasing issues when those paths are merged together again.

IIRC, both Fractal and Helix already do this for you out of the box.
 
Every block introduces latency to the signal path. If you run multiple paths in parallel and the total latency is not the exact same for all, you'll start getting phasing issues when those paths are merged together again.

IIRC, both Fractal and Helix already do this for you out of the box.
That's what I figured. So if I'm not running multiple paths (with the same input), then I can, in some cases, minimize latency by turning this off?
 
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.
Or they could make the block order editable in the plugin in a limited manner. Most of the time the only things that could move are effects.

It should not be that difficult to figure out a plugin converter both ways when the plugin signal path is pretty straightforward. Just put everything in series to go from QC to plugin and then spread to two DSPs in series for plugin to QC.
 
Back
Top