Posts by ToH2002
-
-
I'm not getting into another "I am right and you are wrong" type of debate...
Just asking the question: who actually provided some helpful information to the OP?
Hint: it wasn't any of the "this post is rude" commenters...
-
I think most people find an answer of "RTFM" as rude.
To me it depends on what else is in the post - since jock actually posted some helpful information and not just "RTFM", I personally wouldn't interpret that post as rude - there is also a friendly interpretation "read the fine manual", after all.
But that's just me, generally assuming people are well-intended - until they disappoint me too much...
-
A little disrespectful to be honest 😉
The OP has been a member since 2015 so probably know soon their way around the Kemper by now.The clip above posted by jock is actually an extract of the "what's new in 11.0" - so quoting it should probably not be seen as disrespect, rather a friendly hint that there is information on things that have CHANGED that can be found in the "11.0 addendum" document in the manual downloads section. This one around MIDI channel is pretty relevant, since it is actually a "breaking change", i.e. it makes your Kemper behave differently from before.
"Knowing your way around the Kemper" doesn't really help when things get changed by Kemper - that actually causes things "not to work anymore".
To address the OP's issue: the 11 beta update causes any settings you have made to the MIDI receive channel to get lost and reset to "omni". To fix this, you simply need to re-make that setting in System Settings-->Global MIDI channel; change it from "omni" to your required MIDI channel.
Love & peace,
Torsten
-
I've built and programmed a number of Arduino-based MIDI devices - my favorite platform is the Teensy. You can program it using the Arduino toolchain; it is relatively cheap and available in a number of variants, depending on your need to connect switches, knobs etc, and it can be set to act as a standard PC keyboard or as a MIDI device (among other options), so it's ideal to create all kinds of little helpers for the studio or live, e.g. to convert a simple Digitech / TC electronics 3-button footswitch to a MIDI or keyboard device.
Haven't built or tested anything specifically for the Kemper, but connecting these thingys to Windows PCs or Android tablets works a charm - they act as class-compliant MIDI devices.
And the flashing is just the normal procedure of loading your code to the device from the Arduino toolset - no "lesser-known flashing-software" required.
-
When I send this ...
1: C0 0C 00 [Program Change] chan 1 val 112: C0 0B 00 [Program Change] chan 1 val 12
3: C0 0C 00 [Program Change] chan 1 val 11
Why does the Stage load Performance 3 slot 2, Perf 3 Slot 1, Perf 3 slot 2 ?Display MoreBut in theory..
1: C0 0C 00 [Program Change] chan 1 val 10
2: C0 0B 00 [Program Change] chan 1 val 11
3: C0 0C 00 [Program Change] chan 1 val 10
Should recall Perf 3 Slot 1, Slot2, Slot1.
As I want it too.
1. you should stop sending program changes as three-byte commands. A program change only has two bytes according to the MIDI specification. First byte is the command and the channel, second byte is the 7-bit program number. The additional zero is not needed. A well-programmed implementation of a MIDI program should ignore it, but why send additional unnecessary data?
2. your reading of hex values is off. 0C is hex for 12, 0B is hex for 11. So your program changes (translated in to logical numbers by adding +1) are 13, 12, 13. And definitely not 11, 12, 11 , and also not 10, 11, 10 -> this can't be right at all! Are you sure this is what you are actually sending?
When I send these hex program changes to my Stage (without the additional 00), I get correct results: Performance 3, slot 3 for C0 0C, and slot 2 for C0 0B. And Slot 3 correctly shows logical program change 13 (hex 0C + 1 = 13) on screen, while slot 2 shows logical program change 12 (hex 0B + 1 = 12) - all is correct and working as designed.
If you want to select Perf 3 Slot 1, you need to send logical Program change 11, which in hex is C0 0A (0A is hex for decimal 10 - for logical numbers add 1, which makes 11)
One remark on Bank Select MSB/LSB:
It also appears to me it is also just ignoring the MSB or LSB as they are redundant
Bank Select commands are always stored in the device in preparation for the next program change, and the currently selected bank stays set until a new bank select comes along. So if currently bank 0 is selected and you send another bank select 0/0, this just keeps everything as it is - essentially, sending additional bank selects of the same bank changes nothing. In that sense, it is functionally redundant - what else would you expect to happen?
As long as you stay within the same bank, sending bank selects ahead of a program change isn't strictly necessary. And once you cross into bank 1 and stay in bank 1, again no further bank selects after the first one would be necessary. But in general, for remote switching in performance mode, I would advise to always send bank select before program change, unless you absolutely KNOW you are going to stay within one bank for the whole session...
Cheers,
Torsten
-
Sowohl das Kemper Kabinett als auch das Power Kabinett sind im Prinzip analoge FRFR Boxen, oder?
Sind in sich nicht wirklich "flat" (also FRFR) - aber der Kemper "weiß", wie das Frequenzprofil des Kabinet ist und kompensiert das entsprechend per Software, damit das "flat" wird.
Wenn Du auf dem Monitor und as der PA gleich klingen willst, dann müsstest Du das Kabinet auch als FRFR nutzen, also KEINEN Imprint-Modus ("Monitor Cab Off" im Kone-Modus). Damit sollte das Kabinet genau so funktionieren wie eine "normale" FRFR-Box - aber du verlierst auch den "Amp-In-The-Room"-Effekt, der speziell über die Nutzung der Imprints entsteht. Dann geht Dir halt der spezielle Nutzen des Kabinets verloren und Du bezahlst für etwas, das Du gar nicht verwendest.
Dann wäre es tatsächlich sinnvoller für Dich, gezielt die passende FRFR-Lösung zu suchen - da gibt es ja eine Menge Optionen, vom einfachen Monitor-Wedge bis hin zu spezialisierten Gitarren-FRFRs zu ziemlich ambitionierten Preisen, von Herstellern wie Friedman, Mission oder Laney. Aber auch PA-Boxen werden gerne genutzt, z.B. die Yamaha DBR oder DXR Serie.
Der Stage ist auf jeden Fall eine super-praktische Lösung - auf die Bühne werfen, anschließen - feddich!
-
Mit dem Panorama spielen ist aber natürlich auch so eine Sache
Das mit dem "Raum im Mix" meinte ich eher frequenzbezogen als bzgl. Stereobild - ein guter Mix muss auch mono funktionieren.
Und live halte ich eh wenig von irgendwelchen Stereotricks - das Maximum ist für mich, die Position der Musiker auf der Bühne im Stereopanorama dezent(!) nachzubilden.
Raum im Mix ist für mich erst mal eine sinnvolle Aufteilung des Frequenzspektrums - wenn sich in den Mitten Gesang und zwei Gitarren im gleichen Band herumdrängeln und untenrum Kick, Bass und Palm-Mutes herummulfen, dann wird's echt mühsam....
-
Hat jemand ne Ahnung warum? Weniger Kompression?
Kompression ist der hauptsächliche Faktor. Aber was auch mitspielt ist das Frequenzspektrum - je stärker Du verzerrst, um so mehr nähert sich Dein Sound einem durchgängigen "Rauschen" an, das eigentlich nur noch Matsch erzeugt. In Summe über Kompression und Frequenzspektrum erzeugst Du dann eigentlich eine Rausch-Fläche 😎
Wenn's wirklich so viel Gain sein soll, dann muss man einerseits gut am EQ spielen, dass man gezielt etwas herausziseliert, was im Mix noch Platz hat... Zum anderen geht's dann um Arrangement und Spielweise - es gibt Songs, da spiele ich im Chorus ganz gezielt High-Gain-Powerchords als "Fläche" - die sollen sich nicht durchsetzen, sondern eher einen "Teppich" legen, damit der Gesamtsound voller ist. im Verse wird's dann deutlich sparsamer - kurze, rhythmische Impulse mit ausreichend "Luft" dazwischen, um den Vocals mehr Platz zu lassen und eher den Rhythmus zu akzentuieren - das klappt auch mit High Gain.
Und für Lead-Parts finde ich High Gain für melodische Lines eigentlich extrem gut - mehr Sustain, mehr "Singen". Wenn ein Solo eher rhythmisch, dynamisch, aggressiv sein soll, dann bügelt zu viel Gain allerdings die Attacks platt - wenn alles nur noch ein Brei in der gleichen Lautstärke wird, dann tust Du Dich schwer mit der Dynamik.
Das mit dem "Durchsetzen" ist für mich eher eine Frage des guten Arrangements - wenn jedes Instrument eine klare Rolle und einen klar zugewiesenen Raum im Mix hat, dann muss man sich auch nicht durchsetzen - das ist nur dann nötig, wenn sich mehrere Instrumente/Stimmen im gleichen Frequenzbereich (und in der gleichen Panoramaposition) drängeln. Durchsetzen klingt für mich mehr nach "gegeneinander" spielen als "miteinander" spielen...
-
Könnte der Alternative Input damit Probleme haben?
Laut Handbuch ist der Alternative Input TRS symmetrisch (im Gegensatz zum vorderen Input, der nur TS unsymmetrisch ist) - genau wie der Return Input. Auch die Impedanz ist bei Alternative und Return die gleiche, also sollte ein symmetrischer Stereo-Return ohne Probleme funktionieren.
-
In der Anleitung steht das die Return Input Klinkenbuchse eine TRS-Buchse ist.
TRS muss nicht immer Stereo sein - im Pro-Audio-Bereich ist TRS-Klinke typischerweise ein symmetrischer Mono-Anschluss (außer beim Kopfhörer-Ausgang😉).
Dritte Belegungs-Variante: Insert in einer Buchse (typischerweise bei Mischpult-Kanälen) - da ist der Ring das Send- und die Spitze das Return-Signal.
Wenn bei einer (nicht-Kopfhörer-) Buchse nichts anderes angegeben ist, dann bedeutet TRS normalerweise ein symmetrisches Signal.
-
SEND call for rig name F0 00 20 33 02 7F 43 00 00 01
You might want to add that final F7 at the end of the sysex...
-
Do any of you have the codes or "request string parameter" addresses for Current Rig Name: Next Rig Name; Previous Rig Name, when in Browser mod
The address for the current rig name is 00 01 - as shown above and also in the MIDI parameter documentation. There is no access to previous or next rig via MIDI as far as I know - that's not something typically accessible via MIDI. Typically, you can access what is currently loaded (performance or rig)
If you want to display previous and next rig, your best option is to grab all rig names first - step through all rigs and request the current rig name, then store them in your program. Now that you have all rig names, you can simply react to the current rig selected.
No idea if the Player has the same MIDI implementation as the Toaster, Rack or the Stage - best to try requesting the current rig name via sysex and see if there's a useful reply from the Player...
-
My findings on string parameter addresses
Great stuff!
I assume these are the "request string parameter" values (two-byte addresses) with the function code $43 - correct?
The strings I was looking for are in the "extended string parameter" area - the name of the current performance and the names for its individual slots. It looks like these need to be requested via function code $47, using 5 byte addresses instead of two bytes.
So the addresses I know so far are (all hex)
00 00 01 00 00 - Performance name
00 00 01 00 01 - Slot 1 name
00 00 01 00 02 - Slot 2 name
00 00 01 00 03 - Slot 3 name
00 00 01 00 04 - Slot 4 name
00 00 01 00 05 - Slot 5 name
Identifying all these extended addresses by trial-and-error may be a bit tedious, so I'm not really going to attempt it, since I have what I need with these six addresses. Still a pity that Kemper won't publish them but rather leave it to users to play detective..,.
-
All documentation available to you can be found on our website.
OK, in other words this means that the extended parameters aren't documented - or only documented for internal use?
Would be a pity, TBH - this is a powerful feature...
-
is this info of any use to you?
hey slateboy
thanx for the info - yes, that thread is eminently useful. I have already found that one after a lot of googling, not having gotten anything useful here so far.
The link in the thread to the original discussion ("DIY pedal board...") seems to be broken, but a bit of googling also yielded that original.
With the help of that one, I was able to get a functioning sysex request going to get the name of the current performance and the names of its slots:
F0 00 20 33 00 00 47 00 00 00 01 00 <slot number> F7
Slot number 0 = Performance name
I have no clue where user digitalflip found the correct extended parameters - definitely very useful!
This sysex request works nicely for my purposes, so I can get going with my project, but the state of documentation is still unsatisfactory. I'm still hoping that Burkhard or someone else from Kemper will pitch in and provide more complete documentation, especially of the extended parameters that go beyond the basic two-byte NPRNs.
Cheers,
Torsten
-
what are you trying achive with Sysex
read my original post - don't want to repeat myself....
-
This is not about NRPR - NRPN is relatively straightforward.
This is about sysex messages to extract string parameters.
It's just that Sysex parameters are organuzed using NRPN addresses.
-
Where can I read more about this bandwidth thingy?
TBH, USB bandwidth is mostly a non-issue, as long as you don't run oodles of audio channels. You can run more than 100 audio channels in parallel over a USB 2 connection, so as long as you have a dedicated USB port for your audio interface, bandwidth is typically not an issue.
If we look at a typical audio stream of 48 kHz with 24 bits resolution, this gives us a data rate (bandwidth) requirement of 1,15 megabits per second. USB 1 has a capacity of 12 Mbit/s, so it is good enough for stereo or four channels, but more will drive it to its limits.
When we get to USB 2.0 (high-speed) , we have a bandwidth of 480 MBit/s, so sending 40 and more channels over USB 2.0 is not really a problem - with this, you address most realistic usage scenarios.
-
There is a very nice eBook to address all kinds of audio performance issues on PCs. It is called "Glitch Free" and was written by Brad Robinson, the creator of Cantabile (a great VST instrument host). Its recommendations aren't Cantabile-specific, but relevant for any audio application (DAW or other) that relies on continuous throughput without interruptions.
Here's the link to the eBook: https://www.cantabilesoftware.com/glitchfree/
I've been able to get all my audio systems to pretty much rock-solid performance at low latencies (128 samples) using these recommendations and a bit of common sense...
My audio interfaces are mostly RME - Babyface or Fireface UCX / UFX - RME has a well-deserved reputation for rock-solid performance, also on Windows systems.
Cheers,
Torsten
