Hallo verehrte Kemper Community,
wäre es eigentlich grundsätzlich möglich in der aktuelle Darstellung der AMP Section im Rigmanager eine grafische Darstellung des im RIG hinterlegten AMPs zu implementieren?
zum Beispiel...
Hallo verehrte Kemper Community,
wäre es eigentlich grundsätzlich möglich in der aktuelle Darstellung der AMP Section im Rigmanager eine grafische Darstellung des im RIG hinterlegten AMPs zu implementieren?
zum Beispiel...
Hi,
dann müsste der Profiler beim Profilen noch ein Foto vom geprofilten Amp machen....... Oder habe ich da was falsch verstanden?
Es wäre doch nicht übel wenn man unter anderem im Editor auch Bilddateien hinterlegen könnte? Es bleibt schließlich jedem selbst überlassen ob man diese Möglichkeit nutzen möchte?
Andere Anbieter, z.B.“STL-Tones“, stellen den genutzten AMP in jeweiligem Plugin doch auch grafisch dar...?
Das würde aber wahrscheinlich bedeuten, das diese auch im Kemper abgespeichert werden müssen. Was wiederum beim Backup und synchronisieren ebenfalls hin und her geschaufelt werden muss. Ob der Kemper überhaupt diese Datenmenge packt und wie lange dann der Datenaustausch braucht?
Nur aus interresse, was genau ist der Hintergrund? Ich sehe hier nämlich überhaupt kein Mehrwert.
Es wäre doch nicht übel wenn man unter anderem im Editor auch Bilddateien hinterlegen könnte? Es bleibt schließlich jedem selbst überlassen ob man diese Möglichkeit nutzen möchte?
Andere Anbieter, z.B.“STL-Tones“, stellen den genutzten AMP in jeweiligem Plugin doch auch grafisch dar...?
Ja, aber woher soll der Kemper das wissen?
Nur aus interresse, was genau ist der Hintergrund? Ich sehe hier nämlich überhaupt kein Mehrwert.
War halt nur so ein Gedanke....
Das würde aber wahrscheinlich bedeuten, das diese auch im Kemper abgespeichert werden müssen. Was wiederum beim Backup und synchronisieren ebenfalls hin und her geschaufelt werden muss. Ob der Kemper überhaupt diese Datenmenge packt und wie lange dann der Datenaustausch braucht?
Nur aus interresse, was genau ist der Hintergrund? Ich sehe hier nämlich überhaupt kein Mehrwert.
Die Bilddateien werden in der Datenbank der Local Library auf der Festplatte hinterlegt...das sollte ausreichend sein vermutlich...
Die Bilddateien werden in der Datenbank der Local Library auf der Festplatte hinterlegt...das sollte ausreichend sein vermutlich...
Du kannst dir ja ausrechnen wie Groß die Datenbank dann wird.
Bei mir dauert es jetzt schon ca 20 Sekunden beim Starten bis alle Verzeichnisse und Datenbanken eingelesen sind.
Habe auch nie Verstanden warum man die RIGS als Blob in der Datenbank mit ablegt, statt nur die Meta Daten zu verwalten und die RIG Dateien einfach in ein Verzeichnis kopiert. So wie das viele Foto-Verwaltungsprogramme auch machen.
Du kannst dir ja ausrechnen wie Groß die Datenbank dann wird.
Bei mir dauert es jetzt schon ca 20 Sekunden beim Starten bis alle Verzeichnisse und Datenbanken eingelesen sind.
Habe auch nie Verstanden warum man die RIGS als Blob in der Datenbank mit ablegt, statt nur die Meta Daten zu verwalten und die RIG Dateien einfach in ein Verzeichnis kopiert. So wie das viele Foto-Verwaltungsprogramme auch machen.
Das stimmt auch wieder! Hatte ich nicht berücksichtigt...Danke für den Hinweis Yoda Guitar !
Es scheint dann ja doch nicht "so" einfach umsetzbar zu sein!?
Und sinnvoll ist mein Gedanke dann auch nicht wirklich, dass muss ich zugeben, wie bereits hofnar bemerkt hat!
Es ist halt nur so, dass jeder in einem RIG geladene AMP oder jedes Modul sieht gleich aus.
Letztendlich schaut man doch immer im Display, bzw. Editor nach mit welchem AMP,CAB ect. gerade arbeitet....
Letztendlich schaut man doch immer im Display, bzw. Editor nach mit welchem AMP,CAB ect. gerade arbeitet....
Jain, aber ich verstehe jetzt glaub deinen Hintergrund. Wenn man das mit den Amps machen würde, müsste man mit den Boxen und den Mikros weiter machen. Ich finde es spannender ein Profil zu testen und erst bei gefallen zu wissen was ich da habe. So habe ich schon Amps für mich entdeckt, die ich nicht mal kannte. Was später die Übersichtlichkeit betrifft, ersetze ich die Namen meist mit für mich eindeutigeren Namen.
Du kannst dir ja ausrechnen wie Groß die Datenbank dann wird.
Bei mir dauert es jetzt schon ca 20 Sekunden beim Starten bis alle Verzeichnisse und Datenbanken eingelesen sind.
Ich hab dann auch mal die Zeit gestoppt bis der KPA konplett einsatzbereit ist...ganze 48Sek bei einer DB von 11MB. ?
Ich hab dann auch mal die Zeit gestoppt bis der KPA konplett einsatzbereit ist...ganze 48Sek bei einer DB von 11MB. ?
By the way, je mehr Unterverzeichnisse du in der Local Library hast, je langsamer wird es.
Da jedes Unterverzeichnis seine eigene kleine SQL-Lite Datenbank Datei hat, die alle beim Starten geöffnet und gelesen werden müssen.
Das ist auch der Grund warum man keine Unterverzeichnisse durchsuchen kann.
Eigentlich ein schlechtes Software Design.
Da hat jemand mal schnell was implementiert ohne sich über die Auswirkungen Gedanken zu machen.
By the way, je mehr Unterverzeichnisse du in der Local Library hast, je langsamer wird es.
Da jedes Unterverzeichnis seine eigene kleine SQL-Lite Datenbank Datei hat, die alle beim Starten geöffnet und gelesen werden müssen.
Das ist auch der Grund warum man keine Unterverzeichnisse durchsuchen kann.
Eigentlich ein schlechtes Software Design.
Da hat jemand mal schnell was implementiert ohne sich über die Auswirkungen Gedanken zu machen.
Danke für den Hinweis!
Doch selbst wenn ich die Verzeichnisstruktur in der Local Library entsprechend anpasse, bleibt die Startzeit die gleiche.
Aus meiner Sicht liegt hier ein anderer Grund vor?
"Zu viele" RIGs in der Local Library schließe ich mal aus, wofür ist sie schließlich da?!
die Startzeit
es ist mir unklar, was die "Startzeit" bei dir bedeutet. Es gibt 1) reine Startzeit des Profilers, 2) reine Startzeit des RigManagers (ohne angeschlossenen Profiler), und 3) Startzeit von Profiler und RigManager zusammen.
je mehr Unterverzeichnisse du in der Local Library hast, je langsamer wird es
Ist es nicht so, dass die in den Unterverzeichnissen liegenden Rigs erst beim Draufgehen eingelesen werden?
Und lägen die Rigs in separaten Dateien, müssten diese alle lokalisiert, geöffnet und (bei Bedarf) eingelesen werden. Rigs sind keine riesigen Teile wie etwa Bild-Dateien. Insofern weiß ich nicht, ob das tatsächlich ein Problem ist, sie in der DB abzulegen.
es ist mir unklar, was die "Startzeit" bei dir bedeutet. Es gibt 1) reine Startzeit des Profilers,
Ich meine die Startzeit des Profilers. Die Startzeit des Rigmanagers ist meiner Meinung nach systemabhängig(Rechenleistung-PC oder Laptop)
Ich meine die Startzeit des Profilers.
ok, dann ist klar, dass die Local Library mit ihren Datenbanken NICHT beteiligt sind. Es handelt sich dann nur um die Anzahl der Rigs, die du im Profiler gespeichert hast. Die kann man reduzieren, indem man sie in die Local Library auslagert. Mein Stage braucht ca. 20 Sek. Für mich kein Problem.
ok, dann ist klar, dass die Local Library mit ihren Datenbanken NICHT beteiligt sind. Es handelt sich dann nur um die Anzahl der Rigs, die du im Profiler gespeichert hast.
Echt?
Ich hab gerade mal "48" RIGs auf meinem Kemper gespeichert. Diese Anzahl zu verwalten sollte doch wohl kein großer Akt für ihn sein?
Ich hab das Teil gebraucht mit knapp "750" RIGs gekauft, natürlich mit einer "älteren" Firmware-Release!
Ich glaube mich zu erinnern, dass er damals schneller war mit dem Starten.
Grundsätzlich ist das Ganze für mich kein Problem, ich nutze den Kemper nicht auf der Bühne sondern nur zu Hause.
Um nochmals auf meine Frage zu Beginn des Threads zurück zukommen....ich persönlich fände es irgendwie besser wenn man die Darstellung in der AMP Sektion anpassen könnte! Macht irgendwie was her, finde ich...! Platz wäre vorhanden....
Ist es nicht so, dass die in den Unterverzeichnissen liegenden Rigs erst beim Draufgehen eingelesen werden?
Und lägen die Rigs in separaten Dateien, müssten diese alle lokalisiert, geöffnet und (bei Bedarf) eingelesen werden. Rigs sind keine riesigen Teile wie etwa Bild-Dateien. Insofern weiß ich nicht, ob das tatsächlich ein Problem ist, sie in der DB abzulegen.
Die einzelnen Datenbankfiles (repositoryR2.db) in jedem Unterverzeichnis werden beim Start des Rigmanagers eingelesen um mindestens die Übersicht (links), ein Index sowie die Metadaten für die Suche aufzubauen. Je mehr Dateien geöffnet werden müssen je höher ist der Overhead. Wenn ein Rig dann aus der Local Lib selektiert wird um es an den Kemper zu schicken wird der MIDI Blob (den das ist eine Rigi in Wirklichkeit, eine SysEx-MIDI) gelesen und an den Kemper geschickt.