Arturia MiniV3 (V-Collection) -Problem

  • Ersteller doppelstern
  • Erstellt am
D
doppelstern
Registrierter Benutzer
Zuletzt hier
31.07.21
Registriert
15.07.21
Beiträge
8
Kekse
0
Hallo Leute

Ich besitze u.A. die Arturia V-Collection 7.
Der darin enthaltene "MiniV3" ist die beste Minimoog-Emulation die ich kenne.

Allerdings beherbergt der "MiniV3" einen bösen Fehler, wodurch er leider quasi unbrauchbar wird.
Bei der Version "MiniV2" tritt dieser Fehler nicht auf!

Es geht darum, das der aktuelle MiniV3 (in Cubase) seine Pulsbreiteneinstellungen verliert,
wenn sich unterhalb der MiniV3-Spuhr eine Spuhr mit dem "Kontakt" von Native Instruments befindet.
Ein äussert seltsamer Fehler!
Von dem Problem betroffen sind alle drei Oszillatoren des MiniV3, wenn als Basiswelle eine Rechteckwelle
eingestellt wird und hierbei die Pulsbreite der Recheckwelle geändert wird.
Speichert man das Cubase-Projekt ab und läd es erneut ein, so verliert der MiniV3 die manuell eingestellten
Pulsbreitenwerte.
Seit dem kürzlich erschienenen V-Collection-Update, wobei auch der MiniV3 ein Update erfahren hat,
tritt dieser Fehler erst ab dem zweiten (!) Ladevorgang eines Cubase-Projekts auf,
was die ganze Sache noch komischer macht.

Ich würde ja auch gerne lachen, aber stattdessen ärgere ich mich so langsam darüber,
das es Arturia seit Monaten nicht hinbekommt diesen Fehler zu beheben,
wodurch für mich der MiniV3 im Grunde unbrauchbar geworden ist,
denn die Pulsbreitenwerte sind oftmals massgeblich Soundbestimmend (!)
aber spätestens beim zweiten laden des Projekts ist der Sound des MiniV3 wieder komplett verändert.

Ich habe hier einen Videoclip erstellt, wo ich das Problem genauer zeige.

http://www.alphawaves.de/video.html

Bitte nicht wundern, wenn euer Browser vielleicht meckert, da es keine https-Seite ist.

Der Clip ist in deutscher Sprache.
Er wurde vor einigen Monaten erstellt.
Daher sind die hier verwendeten Softwareversionen nicht auf dem aktuellen stand.
Der besagte Fehler tritt jedoch (nach wie vor) auch bei den aktuellen Softwareversionen auf.



Grüsse @ all :)
 
Eigenschaft
 
Krass.
Hast du als Workaround mal versucht, dass geänderte Preset im Mini zu speichern?
 
Hi Froschi
Nein, das ganze testweise als Preset zu speichern habe ich noch nicht versucht.
Hatte auch wirklich genug zu tun um das Problem überhaupt ersteinmal reproduzierbar zu machen
und dann noch die vielen Mails mit Arturia, Steinberg und Native Instruments.
Die aktuelle Situation sieht so aus, das Arturia den Fehler in ihrem Mini-Plugin bestätigt hat
und sie an einer Problemlösung arbeiten,
jedoch können sie den Fehler wohl scheinbar nicht beheben ohne zuvor gewisse Programmierdetails
über den Native Instruments "Kontakt" zu erhalten.
Und Native Instruments wird diese wohl sicherlich nicht freiwillig an seine Konkurrenten herausrücken.
Bleibt zu hoffen, das Arturia das irgendwie auf die Reihe kriegt.
 
Grund: Nachtrag
Zuletzt bearbeitet:
Auf meine Anfrage an Arturia, warum mein Post gecancelt und als Spam deklariert wurde
erhiehlt ich eine Entschuldigung und in Folge wurde mein Post dort wieder freigeschaltet.
 
Und warum muss eine Kontakt-Spur (MIDI- oder Instrument-Spur?) unbedingt unter die MiniV3-Spur?
 
Ich würde versuchen mal das Ganze mit zwei unterschiedlichen Midi Kanälen laufen zu lassen. Also z.B. 1 und 2 - also beide Spuren nicht auf dem gleichen Midi Kanal.
Topo :cool:
 
Unterschliedliche Kanäle habe ich natürlich auch versucht. Brachte nichts.

Auch habe ich nun versucht, die Änderungen der Pulsbreite in ein Preset zu speichern.
Die Pulsbreitenwerte werden korrekt im Preset gespeichert.
Läd man anschliessend das Projekt erneut ein, ändern sich die Pulsbreitenwerte des Presets jedoch wieder.
Oszillator eins und zwei haben dann immer den Wert 50 und Oszillator 3 immer den Wert 0.
Das Problem bleibt also bestehen, ob ich meine Änderungen nun als Preset speicher oder nicht.
Es sei denn, ich gehe hin und lade das Preset nach dem laden des Projekts erneut manuell ein.
Das müsste man dann allerdings nach jedem laden eines Projekts und ggf. bei jedem MiniV3-PLugin durchführen.
 
Der Fehler ist bei mir reproduzierbar (mit C 10.0x).
Sobald ich Kontakt lade, tritt der Fehler auf. Egal wie viele andere Spuren/Instrumente ich geladen habe.
Scheinbar überschreibt/ Kontakt Daten-Felder vom Mini Moog, was Kontakt nicht machen sollte.
Daher würde ich den Fehler bei NI suchen.

Topo :cool:
 
  • Interessant
Reaktionen: 1 Benutzer
Wenn kein Instanz von Kontakt 5 geladen ist, tritt das Problem also nicht auf?

das würde sonst bedeuten das Cubase ist, sobald Kontakt 5 im Projekt nach dem MiniV3 geladen wird, nicht mehr in der Lage einige Parameter vom MiniV3 richtig zuzuordnen wenn das Projekt geladen wird (vielleicht wegen identer Plugin IDs oder ähnlichem und der Art wie Cubase die Plugin Paramente intern im Projekt speichert), das würde erklären warum es mit der älteren Version vom MiniV2 nicht auftritt (andere Plugin ID),
Ich würde nun mal testweise versuchen, wie es sich mit unterschiedlichen Kontakt Versionen verhält, zb ob das Problem nur bei Kontakt 5 auftritt oder auch bei Kontakt 6.

wie dann genau @topo geschrieben hat, scheint es so als wenn Kontakt dann die Einstellungen vom MiniV3, was er eigentlich nicht sollte, bzw Cubase sollte wohl eher in der Lage sein das richtig zuzuordnen, was es aber scheinbar in diesem Fall nicht kann (vermutung wegen identer Plugin IDs ode dergleichen).

Cubase lädt immer strikt von oben nach unten, wenn es ein Projekt lädt, daher wäre sich das so zu erklären warum es einmal beim laden funktioniert und einmal nicht (danke für dein gut erklärtes Video @doppelstern )
wenn du also im Projekt Kontakt immer oberhalb deiner MiniV3 platzierst, wäre das zumindest ein Workaround wie du das Problem übergehen kannst.

@topo das mit den Plugin IDs ist quasi was wir auch mal hatten mit dem Fabfilter Plugin als VST2 und VST3
 
Zuletzt bearbeitet:
@Signalschwarz
Und warum muss eine Kontakt-Spur (MIDI- oder Instrument-Spur?) unbedingt unter die MiniV3-Spur?

Ich weiss ja nicht wie du vorgehst wenn du einen Song produzierst,
aber ich beginne mit dem ersten Track und dann kommen weitere hinzu.
Welche Instrumente das sein werden zeigt sich erst im laufe der Zeit.
Damit man später einen besseren Überblick behält und rationeller arbeiten kann, werden bei mir ab einer
gewissen Anzahl von Spuren (...warum antworte ich eigentlich auf eine so komische Frage?...)
die Spuren in einer sinnvollen und übersichtlichen Reihenfolge verschoben / gruppiert.
Die Details zu erklären erspare ich mir an dieser Stelle.
Jedenfalls werden bei mir Spuren sinnvoll sortiert / gruppiert.
Das verschieben von MiniV3-Tracks die notgedrungenderweise oberhalb aller Kantaktspuren
platziert werden müssen(!), verwirft mir teilweise meine langgewohnte übersichtliche Arbeitsweise
bzgl. der sinnvollen und rationellen Anordnungen und Gruppierungen von Spuren.

Für mich als zahlender Kunde und Anwender des Arturia MiniV3-Plugins ist es ausserdem eine Zumutung
mir vorschreiben zu lassen, an welcher Stelle im Sequenzer ich das PlugIn zu platzieren habe,
nur damit es auch ordentlich funktioniert.

Desshalb ist meine ganze laberrei bezüglich deiner Frage an dieser Stelle in meinen Augen eigentlich überflüssig.
 
Die Details zu erklären erspare ich mir an dieser Stelle.
Jedenfalls werden bei mir Spuren sinnvoll sortiert / gruppiert.
Das verschieben von MiniV3-Tracks die notgedrungenderweise oberhalb aller Kantaktspuren
platziert werden müssen(!), verwirft mir teilweise meine langgewohnte übersichtliche Arbeitsweise
bzgl. der sinnvollen und rationellen Anordnungen und Gruppierungen von Spuren.
das kann ich sehr gut verstehen, ich arbeite genauso und eine Ordnung im Projekt ist mir auch wichtig.
Falls es dich tröstet, bei UAD Plugins gibt es ein ähnliches Problem, die haben zwar einen Algorithmus eingebaut das die Plugins je nach DSP Auslastung in Tetris Manier in die freien DSP Steckplätze hieft, aber das funktioniert beim Projektstart auch nicht und man bekommt Fehlermeldungungen das Plugins nicht geladen werden können weil kein freier DSP Speicherplatz vorhanden zu schein sei, aber das ist nur die halbe Warheit, eben weil hier der Algorithmus zur DSP Verteilung noch nicht eingesetzt hat, was hier abhilfe schafft, ist das man DSP Starke Plugins am Anfang des Projekts setzt und nicht am Ende (ich hab zb alle mein FX Send Kanäle immer ganz rechts im Mixer gehabt, das gab dann dauernd PRobleme, damit, nun sitzen sie ganz links im Projekt, werden als erstes beim Projektstart geladen und nun funktionierts ohne Probleme,) war auch für mich eine Umgewöhnung aber ein Workaround mit dem ich leben muß, wenn ich nicht alle meine Plugins überprüfen will welche deaktiviert wurden

Aber wir sind ja nun dem ganzen ein wenig auf der Spur warum es sich so verhält.. im Grunde ist es eine verkettung ungünstiger Umstände was zu diesem Verhalten zwischen Cubase, MiniV3 und Native Instruments Kontakt 5 führt. wo eigentlicher keiner der 3 Parteien so richtig Hautpschuld hat, so sehe ich die Situation nach dem aktuellen Stand.
 
eine verkettung ungünstiger Umstände
...na das trifft doch den Nagel genau auf den Kopf *lol
Also gleich nachdem ich den Bug reproduzieren konnte (vor etwa 5 Monate!), habe ich ja alle beteiligten Unternehmen darüber ausgibig informiert.
Steinberg, NI und Arturia wissen also davon und letztendlich hat mir Arturia den Fehler in ihrem Plugin bestätigt, - allerdings nur "um acht Ecken herum",
also irgendwie auch nicht wirklich, denn so wie ich das verstanden habe spielen hier Teile eines für Arturia unbekannten Programmcodes des Kontakt auch eine entscheidene Rolle
um das Problem bei Arturia lösen zu können und NI wird darüber vermutlich keine Informationen rausrücken.

Mein Vorschlag an Arturia war, das Arturia prinzipiell doch nur die relevanten Unterprogramme (also Programmcode-Abschnitte) der MiniV2 und MiniV3 -Versionen miteinander zu vergleichen bräuchten.
So müsste der Fehler doch relativ schnell auszumachen sein, da bekannterweise der Fehler im MiniV2 nicht auftritt.
Dieser grandiose Vorschlag wurde vom Arturia-Support an das Entwicklerteam weitergeleitet *grins
Aber mal ohne Quatsch: ich würde so vorgehen! Die relevanten Unterprogramme beider Versionen miteinander vergleichen.
 
Zuletzt bearbeitet:
@doppelstern
hast du schonmal ausprobiert ob es bei den beiden anderen Versionen von Kontakt 5 genauso passiert (8out, 16out), es könnte ja sein das diese zb eine andere Plugin ID haben.
und wie gesagt, mal testweise die aktuelle 6er Version von Kontakt ausprobieren (vielleicht gibts die als Demo? oder zumindest dann den kostenlosen Kontakt 6 Player)
 
Der Bug tritt auch auf im Verbund mit Kontakt 5 16out und Kontakt 5 8out auf.
Ebenso beim Kontakt 6 Player. Über die Kontakt 6 Vollversion kann ich nichts sagen
da ich diesen nicht besitze.

Getestet habe ich u.A. auch das deaktivieren des ASIO-Treibers.
Aber auch ohne ASIO-Treiber das selbe Problem.

Übrigens habe ich bereits im Januar die Problematik auch im Steinbergforum gepostet.
Hier der Link:
https://forums.steinberg.net/t/cubase-projekt-lad-einige-synth-parameter-nicht-korrekt-ein/684295/21
Dort habe ich auch einiges vom Mailverkehr mit den Softwareherstellern gepostet.

Holger Steinbrink (den dürften wohl viele kennen) teilte mir mit, das nach seinem Test der Fehler ebenso auf seinem Mac auftritt.

Via PC-Direktverbindung habe ich einen NI-Supportmitarbeiter an meine PC rangelassen.
Er hat sich den Fehler also quasi direkt und Live auf meinem PC angesehen. Konnte aber auch keine Erklärung oder gar Lösung anbieten.
 
Zuletzt bearbeitet:
  • Interessant
Reaktionen: 1 Benutzer
Man könnte als Workaround noch schauen, was passiert, wenn du den MiniV3 nicht direkt in Cubase in eine Spur lädst, sondern über ein anderes Plugin, was VSTi laden kann.
Also Cherry Audio Voltage Modular https://docs.cherryaudio.com/cherry-audio/plug-in-host als Beispiel läd selber VSTis, ich könnte mir vorstellen, das würde das Problem umgehen, wenn du ein Plugin hast, was das kann.
 
  • Gefällt mir
Reaktionen: 1 Benutzer

Ähnliche Themen


Unser weiteres Online-Angebot:
Bassic.de · Deejayforum.de · Sequencer.de · Clavio.de · Guitarworld.de · Recording.de

Musiker-Board Logo
Zurück
Oben