...imagine there would be a VST plugin subdirectory on the Kemper. Each of those countless FX would be candidates to be loaded into any FX slot. If a mono slot has been chosen, the Kemper would do an automagical mono wiring, otherwise stereo. Of course, the sometimes fancy GUIs of the plugins would not show up, but each parameter with its name and range of values, just like any other FX on its pages.
Stomp Slots to be VST compatible
-
I can say with 99% certainty that this will never happen. The Kemper isn't a VST host, and it doesn't have the processing power or RAM to be one.
-
I can say with 99% certainty that this will never happen.
101%
-
The Kemper isn't a VST host, and it doesn't have the processing power or RAM to be one.
The latter is technically nonsense.
VST is very lightweight and it is running on computers since 1996. Compared to those processors the Kemper is a true super-computer. If a system can handle real-time transposing with formant shifts - like the Kemper does - it can handle a VST-Host in dozends of plugins in chain. And VST is ultra simple - implementation wise. And ultra-efficient if you are in the domain of C/C++ anyway, like the Kemper is.
Furthermore: Christoph Kemper explained the reason why he invented the profiling in an interview. He said, modelling each and every amp is just too time-consuming. The profiling can be done by the user, so it reduces the load of the Kemper staff.
A truely genious engineer's approach, me thinks.
Now, there are so many user requests for more, better, different FX for the Kemper on this forum. Some are even already complaining about that fact.
The VST-interface is the *same* basic idea as the profiling-approach! It would take load from the Kemper-staff and expand the possibilities of a live-on-stage sound to ground-shaking change in the world of guitar amps. There are so many free, outstanding, innovative, genious and 100% stable VST-plugins out there. While the Kemper team is developing one new effect for just the Kemper, there are 100+ VST FX released by the community.
But all right, according to G String its 101% sure this will never happen. No big deal for me, I am mostly a studio guy.
-
...imagine there would be a VST plugin subdirectory on the Kemper. Each of those countless FX would be candidates to be loaded into any FX slot. If a mono slot has been chosen, the Kemper would do an automagical mono wiring, otherwise stereo. Of course, the sometimes fancy GUIs of the plugins would not show up, but each parameter with its name and range of values, just like any other FX on its pages
You're watching too much badly researched hacker movies...
-
Put a Intel NUC with a cheap ASIO audio interface in the loop of the kemper .... and that it
-
You're watching too much badly researched hacker movies...
Am I evil? I am man, yes I am!
-
The latter is technically nonsense.
VST is very lightweight and it is running on computers since 1996. Compared to those processors the Kemper is a true super-computer. If a system can handle real-time transposing with formant shifts - like the Kemper does - it can handle a VST-Host in dozends of plugins in chain. And VST is ultra simple - implementation wise. And ultra-efficient if you are in the domain of C/C++ anyway, like the Kemper is....
It has 128MB of RAM and a couple of 400MHz processors. Those are pretty big limitations when it comes to running software that was intended for desktop PCs with multiple processors running at several GHz. On top of that, the Kemper OS is written in assembler and the processors are specialized for DSP, so I have to imagine that makes implementing a VST host even more difficult.Many VST effects are also going to involve latency, so have fun playing live.
-
Those are pretty big limitations when it comes to running software that was intended for desktop PCs with multiple processors running at several GHz.
Tell me the name of such a VST. I am not talking about a VSTi (like a huge Sampler, which doesnt make sense at all in a guitar amp), I am talking about delays, choruses and verbs or such neat little things.
The fastest Intel PC processor at that time was about 200 MHz. And it worked. Nowadays you can add 50+ of the VSTs in question into a PC with i7 and the taskmanager will not even show 1% more processing load.
The VSTs in question demand close to NO MEMORY. Even my decent IR-Reverb with uncompressed pulses is using < 1MB.
"On top of that, the Kemper OS is written in assembler and the processors are specialized for DSP, so I have to imagine that makes implementing a VST host even more difficult."
VST is almost nothing but DSP. SO it perfectly fits The little overhead of loading such a plugin is like loading a DLL and less difficult compared to loading a RIG or PERFORMANCE. I would draw my hat if the core sound engine of the Kemper is really in assembler. Kudos. But I have seen enough error messages from the Kemper which smelled like C-Runtime. Which makes perfect sense for the enviromental tasks like file handling and such. And if so it would really make hosting VSTs very easy.
And if you think latency is a show stopper here, you have never used those.
-
Compared to those processors the Kemper is a true super-computer
...mmmmhhhh... the cpu of the kpa is an 120Mhz....
-
On top of that, the Kemper OS is written in assembler and the processors are specialized for DSP, so I have to imagine that makes implementing a VST host even more difficult.
...mmmmhhhh... the cpu of the kpa is an 120Mhz....
From a couple of 400 MHz processors to one single 120 MHz in just 5 posts...
I give up. It wont be implemented anyway. Just 5 posts more and the Kemper has no processor at all...
-
Just 5 posts more and the Kemper has no processor at all...
This made me larf!
-
me too!
-
Two more
-
From a couple of 400 MHz processors to one single 120 MHz in just 5 posts...
I give up. It wont be implemented anyway. Just 5 posts more and the Kemper has no processor at all...It has a pair of 400MHz DSP chips. I didn't see anything about the CPU itself, so it could well be 120MHz. Maybe you should look at the specs yourself before claiming that it would be ridiculously easy for the Kemper to do things?
- VSTs are written in languages like C++ for use on Windows and Mac. Kemper's OS has absolutely nothing to do with Windows or Mac, so you can't just take VSTs and throw them on there. You need a program in the Kemper that would, for each VST you load, act as a wrapper and translate everything. It would have to map all of the VST's parameters to the interface knobs, since it can't display the plugin's GUI. Processor-wise, that's not a simple task.
- The simplest VSTs in my plugin folder take up about 500KB of storage space. That's as much as 70 profiles. If they're limiting us to 1000, it's because there isn't a ton of storage space on the KPA.
- I just opened my DAW and added three plugins to a track - GChorus, ReaComp, and TDR Proximity. They aren't very big, but those three still used 5MB of RAM. The Kemper has 128MB total; that's not much.
- As I mentioned, plugins add latency. DAWs can compensate for this by pre-delaying your tracks. The Kemper can't do that. At all.
-
To be fair, the Kemper's FX add latency too, albeit a tiny amount each.
Also, loading a small-footprint plugin would be comparable, RAM and CPU-usage wise, to instantiating a Kemper effect of similar flavour, wouldn't it? IOW, it wouldn't be a RAM and CPU demand over and above an effect-slot filled Kemper; it'd be an "exchange" - swapping out an existing slot's algorithm for another, in effect, if you'll excuse the pun.
It may well be that a small price in efficiency would have to be paid due to the fact that VST/AU plugs aren't Kemper-native, necessitating a translation layer, but then, all this said, there's one roadblock that no amount of speculation or clever coding can overcome:
101%
I'm not sure how you guys are reading this, but I'm taking it as possibly the firmest "no" I've seen on the forum thus far.
Condolences to the OP, but it ain't gonna happen, nor should it need to IMHO. New effects and updated algorithms seem to always be on the horizon for us anyway, and we're able to make requests as well. Lucky us, I say!
-
To be fair, the Kemper's FX add latency too, albeit a tiny amount each.
Also, loading a small-footprint plugin would be comparable, RAM and CPU-usage wise, to instantiating a Kemper effect of similar flavour, wouldn't it? IOW, it wouldn't be a RAM and CPU demand over and above an effect-slot filled Kemper; it'd be an "exchange" - swapping out an existing slot's algorithm for another, in effect, if you'll excuse the pun.
It may well be that a small price in efficiency would have to be paid due to the fact that VST/AU plugs aren't Kemper-native, necessitating a translation layer...
The Kemper's own effects are coded to run efficiently on the Kemper and make use of the internal DSP chips. VSTs have the luxury of running on high-powered computers so they can afford to be a little beefier. Most of them don't make use of DSP chips, as far as I know, so they're doing a lot of that processing themselves which is, again, less efficient. That's not something a translator can fix.
For comparison, I opened two different versions of TSE 808 in my DAW - the 64-bit version, which is what my system runs, and the 32-bit version. Just creating a wrapper to run the 32-bit version is using 20% more CPU, and 32-bit Windows to 64-bit Windows is fairly straightforward. Running a Windows VST on the Kemper is orders of magnitude more difficult, because a Windows .dll needs all sorts of Windows functions to run. The Kemper's wrapper would have to replicate all of those.
-
Ah... thank you, Lokasenna.
So when I said:
It may well be that a small price in efficiency would have to be paid due to the fact that VST/AU plugs aren't Kemper-native, necessitating a translation layer
... I was obviously underestimating just how big a price it would be.
-
Lokasenna, there seem to be too completely different VST worlds we are living in. I am using VST FX while tracking, mostly for monitoring purpose, but I in the past I also tracked with VST being virtual amps, in real time, as understood. I can see no reason why this should not work in the Kemper. In example: a look-ahead compressor VST is extremly cool, but of course not able to be used in realtime tracking and hence has to be avoided. But my own EQ-filters do have one sample of latency, it cant be better in the Kemper OS stomp FX world.
And again: if a processor can handle one channel pitch shifting it can handle 50+ instances of VSTs being delays or EQ or such.
VSTs are written in languages like C++ for use on Windows and Mac.
...On top of that, the Kemper OS is written in assembler...
This brings me to a serious topic. I might have overlooked something.
Firstly: C++ is a machine independand language. It has NADA to do with Mac or WIndows or any other OS. The more lightweight VSTs are written in C and not C++, though, which is again OS-independand. But you can also write them in Assembler or PASCAL, as long as you can produce a proper binary for the OS in question. The VST-specification is just an interface you have to follow, again independand of OS and even programming language.
They have to be compiled and linked to be a binary for a certain OS, though, i.e. LINUX. That means, that one source code of a VST can (and actually mostly is) delivered for more than one OS.
Now, in the Kemper World the basic software is called OS - operating system. I did not take this literally. I assumed the OS is actually LINUX. Which is lightweight and efficient. If the Kemper has really its own operating system then things are not as easy as I thought. Namely that would mean that anybody who released a VST would have to release this again for the Kemper OS to make it work. (The load for the Kemper VST-Host is still minimal, no wrappers for each VST or such, the VST-Host IS THE wrapper for all VSTs existing for that OS)
Lets call this a show stopper.
But not any of the other technical excuses from above. Never tell a software engineer "this is not possible, because..."
I kindly apologize for this unrealistic feature request and promise to never do something like this again.
-
The developer's heaven should be that Kemper provides a SDK that allows third party to develop (or port existing VST) FX on the kemper.
