Neural Quad Cortex

  • The thing is, the FM3 costs €1,200. Also it is something like half the processing power of its larger format.

  • The thing is, the FM3 costs €1,200. Also it is something like half the processing power of its larger format.

    Thing is...


    Though there are no profiles of axe/helix I like in the RE (which honestly surprises me) this is not the same with the neural profiles we have on the RE.Some of these are quite good.I like them.So..I have an eye on this quad cortex.But it has to be really,really outstanding to make me think "further"..there is only a 1% chance I could change my mind on spending over 1500€ for a floorboard.

  • Thing is...


    Though there are no profiles of axe/helix I like in the RE (which honestly surprises me) this is not the same with the neural profiles we have on the RE.Some of these are quite good.I like them.So..I have an eye on this quad cortex.But it has to be really,really outstanding to make me think "further"..there is only a 1% chance I could change my mind on spending over 1500€ for a floorboard.

    You could download free trials of neural dsp vsts and try them out, as well. I myself have been split recently about whether to get a cortex or an fm3, actually. Currently more on the fm3 side largely due to thinking the amp sims are quite spectacular.


    With axe fx 3 I've nailed just about any profile I've liked best. FM3 is a bit different, due to lacking tone matching, but I've had good results nonetheless (not with fm3 but using axe fx 3 as I would fm3).


    Also, I wouldn't rely too too much on what I find on RE personally. I had a helix recently and compared the friedman amp to the analog equivalent. They were quite close, closer for some settings, worse for others. I've had the same experience with axe fx amp sims over and over -- even thinking some amp sims tested were closer to the amp than my own direct profiles shot of the same rig. The profiles I had found on RE were quite lacking for me, for many reasons.


    I've seen other cases as well. I'd say my experiences vary a lot at this point. But if I wasn't convinced fm3 has great amp modelling -- like really really good -- i wouldn't consider fm3 at all, certainly... Especially with all the comedic hiccups involved with that product lunch. Even now too many people are having issues that shouldn't be there at lunch even imo.

  • First, I had a 2120 for years. Sure, it had spill-over, and maybe it did use its 2nd processor for this purpose; however, in no way would I put my 2120 and KPA (or Axe Fx III) in the same sentence.


    Second, in this modern day and age we engineers have these things called Threads or tasks (depending on the operating system being used). You can accomplish the same thing without 2 processors.


    Third, The KPA does this and does NOT have multiple processors and does not have any audible switch time.


    My conclusion is that it is an implementation issue, not a hardware issue. If they have architected their firmware in a way that doesn't allow this, then it isn't the hardware's fault.


    My expert scoring on this ..... 10.0 on the BS - O - Meter. :)


    As for the buttons, I too have engineered testing rigs to test mechanical buttons. The issue is always that the machine isn't a foot and doesn't press the button the same way, or as hard.


    The best testing is a year in the field really. Short of that ..... re-use of off-the-shelf components that already have field hardened track records in the field (which is what KPA did).

  • yeah that post by them was hysterical. In doing my due diligence before buying the stage last week I enquirered on their forum about something in regards to snapshot management (can’t remember what I was trying to figure out) but I mentioned having owned the helix a couple years back and that the preset gap was the deciding factor to return it. So maybe I touched a nerve

  • It has dual core DSP ;)

    Lol. And here comes Damian to shoot me down 😜


    I don't know what processor the "quad cortex" uses, but it does suggest it has 4 cores 😁.


    Still, even a single core can task switch. I did it on a 68332. Any OS offers this . I am sticking with the "poor implementation" explanation for now.


    FWIW, what we are doing here is known as "user stories" in Product Management. You FIRST determine the way customers want a product to operate, THEN you design for it.


    As an example, guitar players don't have a requirement for a powerful multicore processor, they want it to start quickly, switch quickly, and have lots of available etc.


    I am not saying that this product doesn't have those features, only that the company appears to be heading into that line of reasoning.

  • Maybe the poor implementation comes with the territory of depending on object orientated platforms to code something so sophisticated as a firmware for a modeller. CK does things differently in that he developed the actual programming environment from scratch for the 56k Motorola inside the Kemper and thus has this thing as close to the metal as you can possibly get. It really is all about implementation and it helps immensely if you can code in Assembly too.

  • CK does things differently in that he developed the actual programming environment from scratch for the 56k Motorola inside the Kemper and thus has this thing as close to the metal as you can possibly get. It really is all about implementation and it helps immensely if you can code in Assembly too.

    As an example, guitar players don't have a requirement for a powerful multicore processor, they want it to start quickly, switch quickly, and have lots of available etc.

    All the modelers which will appear from now on will show what a genius tool the profiler is.

    Actually it is a very,very complex piece of tool in all its simplicity.


    Great response to different guitars.

    Seemless switching.

    Automatic volume leveling between all the rigs.

    Great surface UI for live gigs.

    Well though concept for connecting.To everything.Who has a second kemper can confirm this.


    All this above are the secret weapons of a modeler which can be chosen by tube amp freaks.And I don´t even speak about the sound quality.I don´t need to.


    Again..Every modeler which will be thrown at the market from now on will be better a real tool for musicians and not just "one more modeler which can do everything + more" but not the basic things a guitar player needs in the studio and on stage.

  • Maybe the poor implementation comes with the territory of depending on object orientated platforms to code something so sophisticated as a firmware for a modeller. CK does things differently in that he developed the actual programming environment from scratch for the 56k Motorola inside the Kemper and thus has this thing as close to the metal as you can possibly get. It really is all about implementation and it helps immensely if you can code in Assembly too.

    I agree. It is all about the implementation.


    I would argue that anyone that OOP is a bad tool for use in embedded systems. C++ OOP consumes many times as much ROM space and RAM space as straight C does. While it can execute just as fast, it usually doesn't simply because of the moving of a butt ton of memory object information around.


    It is amazing what the KPA accomplishes with its minimal processing and RAM.

  • I agree. It is all about the implementation.


    I would argue that anyone that OOP is a bad tool for use in embedded systems. C++ OOP consumes many times as much ROM space and RAM space as straight C does. While it can execute just as fast, it usually doesn't simply because of the moving of a butt ton of memory object information around.


    It is amazing what the KPA accomplishes with its minimal processing and RAM.

    The advantage can also be a disadvantage, depends on the perspective. Writing efficient C code which scales and has no memory issues is way more difficult than in C++. You really have to know what you are doing. C++ makes a lot of things easier and you can incorporate C code into a C++ project. So from my perspective, it is not an "either / or" but complements each other. One has to find to find the sweet spot where to draw the line. Typically, there's a C interface with a C++ wrapper. So you can call the functions implemented close to the hardware with a high-level interface. I would assume that Kemper did it similar or even like this. :)

  • I would argue that anyone that OOP is a bad tool for use in embedded systems. C++ OOP consumes many times as much ROM space and RAM space as straight C does. While it can execute just as fast, it usually doesn't simply because of the moving of a butt ton of memory object information around.

    Not sure if I get your point about object size right, but C++ is straightforward and transparent about what it does to object sizes and it has pretty much the same rules and tuning options as C does. Moving structure in C is as much consuming as moving objects/structures with the same set of fields in C++.


    Also there are compiler settings to turn off RTTI and exceptions (and the latter is widely used) if you don't need those . That'll make C++ OOP implementation identical to the simplest C OOP implementation.

  • The advantage can also be a disadvantage, depends on the perspective. Writing efficient C code which scales and has no memory issues is way more difficult than in C++. You really have to know what you are doing. C++ makes a lot of things easier and you can incorporate C code into a C++ project. So from my perspective, it is not an "either / or" but complements each other. One has to find to find the sweet spot where to draw the line. Typically, there's a C interface with a C++ wrapper. So you can call the functions implemented close to the hardware with a high-level interface. I would assume that Kemper did it similar or even like this. :)

    From my conversation with Christoph, he did all of the programming in assembly language.

  • From my conversation with Christoph, he did all of the programming in assembly language.

    This is probably true only for DSP part. If you look at crash logs / stack traces and diagnostics files many files are C/C++ headers, many functions are in Access:: namespace (maybe still remembering Virus times?), internally KPA uses sqlite as a storage for presets, profiles (embedded db, written in pure C). And KPA runs on top of some operating system (on ARM-based CPU), with sys calls, which would indicate that there is kernel / user space separation.

  • As I said earlier I'm also curious and competition is definitely good. I'm not a Kemper fanboy, I'm simply interested in playing the best amp emulations available. Having said that, this whole thing seems really suspicious to me. Its marketing is quite aggressive and is full of bullshit. Lets take the 2 GHz DSP for example. To my knowledge it is not really 2 GHz, it is simply a 500 Mhz quad-core chip. Of course 2 GHz looks better from a marketing standpoint. Also the neural network sounds really promising... but I'm very skeptical. Its basically a buzz-word nowadays and often there is no substance behind it. If the amp capturing part is really as groundbraking as hyped - don't you think it would make sense to demo it more thoroughly? We only heard a few samples/demos. Anyway - I hope it will be a good unit. But I do not have my hopes up, as I have also tried their plugins and... lets say I'm not impressed.