1536k Bit/s, .wav, sollte in 44.1 gesampelt sein, 47,26min, 521Mb, Dateiname: Custard_26-09-20.wav
zumindes bei DMXC2 waren da wenn ich mich recht errinnere einige Einschränkungen.
1536k Bit/s, .wav, sollte in 44.1 gesampelt sein, 47,26min, 521Mb, Dateiname: Custard_26-09-20.wav
zumindes bei DMXC2 waren da wenn ich mich recht errinnere einige Einschränkungen.
Hast du mal probiert, die Datei in ein mp3 (zum Beispiel mit einer Bitrate von 320 kBits/s) zu konvertieren und dann in DMXControl 3 einzufügen?
1536k Bit/s
Wie gesagt, probier hier mal die 14xx kB/s.
Ich habe jetzt irgend eine X belibige MP3 genommen damit geht es. Also war wohl einfach Qualität des Liedes zu hoch oder das Stück an sich zu lang. Ich werde es bei Gelegenheit weiter auskuntschaften.
Bisher soweit ganz gut. Gibt es den schon grobe zeitliche Ansätze wann die Funktion mit Audioanalyse und Extras eingegliedert? Ist das überhaupt noch geplant? Alleine in Bezug auf z.b. jetzt Weinachten wäre es deutlich leichter und schneller zu händeln.
Danke schon mal für den Gedankenansatz, hat echt geholfen.
Ahhh mir fällt da gerade noch etwas ein. DMXControl 3 ist eine 32bit-Anwendung. Diese kann daher nur eine gewisse Menge an Speicher adressieren (in der Realität so um die 1,7GB). Beim Laden einer Audiodatei wird jedoch eine volle FFT-Analyse durchgeführt. Das wird für zukünftige Versionen von DMXControl 3 benötigt (*hust* Timecodeplayer
), weshalb das schon in den aktuellen DMXControl 3-Versionen enthalten ist (sonst könnten wir aktuell noch keine Audiodateien abspielen). Bei der FFT-Analyse fallen aber während der Verarbeitung einige Daten an, die gerade bei großen Audiodateien dazu führen können, dass der Speicherbereich von DMXControl 3 erschöpft ist (das ist aktuell noch nicht optimiert worden). Ich habe ein Projekt, bei dem ich eine fast 14 minütige Wave-Datei verwende (siehe hier den entsprechenden Bericht: Live@Work - 19_KW02 - Die Weihnachtsgeschichte aus anderem Blickwinkel). Mit diesem kratze ich tatsächlich an dieser Grenze
Ich muss da erst den Kernel starten und das Projekt im Kernel per Kommandozeilenparameter laden. Wenn die FFT-Analyse durch ist, kann ich dann auch die GUI verbinden
Das könnte bei dir auch das Problem sein. Schau mal in den Kernel, was der sagt. Der meldet sich mit einer Warnung, wenn die Audiodatei nicht geladen werden kann, weil bei der Analyse der Speicher ausgeht.
Danke für den Hinweis. Werde ich wenn ich am Wochenende wieder zuhause bin mal gucken was in der Kernel geschrieben steht wenn ich versuche das zu laden.
Tritt der Effekt auch auf wenn man viele Stücke hintereinander laden läßt? Bzw. Gibt es da dann eine ähnöiche Begrenzung?
Hintergrund dazu ist das ich ein mal im Jahr einen Orts ansässigen Verein unterstütze der ein ca. 4Stündige Aufführung macht mit nem Haufen Musik die Quasi das Programm zu der Aufführung ist und was dementsprechend mit Effekten und Lochtstimmungen zu den richtigen Zeitpunkten untermalt wird. Und das ist dann Quasi 1Wochen mit 8 mal der gleichen Aufführung. Wo unter anderem Licht auch zur Auftrittssignalisierung genommen wird.
Und zudem hat mich die Rentierparty dazu angestiftet das ich mir auch so eine Geile Weinachtslichtshow zuhause aufbauen möchte die nicht nach 5 min zu Ende sein soll.
JPK ist eigentlich auch irgendwie eine Zeitschaltuhr/Wochenplaner in Planung?
Das Problem ist, dass man leider nicht so sehr voraussagen kann, ab wann der Effekt auftritt. Da natürlich alle Daten (und zwar wirklich alles, was das Programm zum Arbeiten braucht) Platz benötigen, kann schon ein Fenster von DMXControl 3 den Unterschied machen. Deshalb lässt sich da keine allgemeine Aussage treffen. Du kannst ja mal so ein bisschen den Speicherbedarf des Kernels und der GUI im Taskmanager beobachten. Natürlich wird von den Entwickler versucht, mit der Zeit solche Speicherfresser etwas zu reduzieren. Ein Beispiel war da auch das alte Input Assignment. Neben dem Fakt, dass das Öffnen des Fensters unglaublich langsam war, haben es auch schon ein Paar Leute geschafft, alleine mit diesem die Grenze zu knacken. Aber ja, bei sehr sehr großen Dateien kann das ein Problem sein.
JPK ist eigentlich auch irgendwie eine Zeitschaltuhr/Wochenplaner in Planung?
Eine Zeitschaltur ist schon eingebaut
Aber an anderer Stelle, als man das vielleicht vermuten würde. In der Cuelist gibt es einen Trigger, der heißt RTC, oder ausgeschrieben "Real Time Clock"
Wähle diesen aus, stelle eine Uhrzeit bei der Trigger Value ein und solange die Cuelist läuft, wird diese Cue um die angegebene Uhrzeit ausgeführt.
Ein Wochenplaner ist hingegen noch nicht enthalten. Das könnte ich mir aber gut als Plugin vorstellen. Vielleicht hat da je jemand Lust drauf (und vor allem die Zeit), das zu programmieren.
Hallo JPK
hier wie versprochen der Auszug aus der Kernel. Die ist natürlich wie schon erwartet am meckern. Ich kann mit dem was da steht nicht viel anfangen, aber ich denke mal das ihr damit was anfangen könnt. Nebenbei hab ich die zu dem zeitpunkt bestehende Systemauslastung die mehr oder minder im Standby ist.
LG Neofighter
QuoteEin Wochenplaner ist hingegen noch nicht enthalten. Das könnte ich mir aber gut als Plugin vorstellen. Vielleicht hat da je jemand Lust drauf (und vor allem die Zeit), das zu programmieren.
Wenn mir irgendwer mal zeigt/erklärt wie das grundsätzlich funktioniert mit dem Programieren, ich habe grade unter der Woche abends sehr häufig Zeit und langeweile.....
Und ja es ist mir bewust das das nichts ist was man von jetzt auf gleich erlernt und ich mich da grade sehr weit aus dem Fenster lehne.![]()
![]()
Ich glaub bevor ich hier n neues Thread eröffne hänge ich mich ganz frech hier mal mit ran :o)
Hätte da mehrere Anliegen
1. kommt es mir nur so vor oder ist die Beaterkennung im Audio Analyzer im Vergleich zum Beat Detection Plugin von DMX Control 2 extrem ungenau; um nicht böse zu sagen: einfach nur sch**** ?! Hab schon alle möglichen Algorithmen durch aber keiner davon funktioniert zufriedenstellend. Warum das halbwegs passen (von 100% redet hier keiner) sollte kommt gleich im nächsten Schritt.
2. Ich würde gerne meine Strobos im Takt blitzen lassen. In DMXC2 war das kein Problem. Da hatte ich einfach einen Step "Strobes An" und einen "Strobes Aus"; der Step "Strobes An" hatte eine Haltzeit 0,1s und der "Strobes Aus" ganz einfach die Haltezeit "Beat".
irgendwie bin ich zu doof das in DMXC3 umzusetzen. Wie muss das da aussehen? Hab da irgendwie grad n Hirnknoten
Ich habe mal bei mir geschaut:
| Name | Auslöser (Trigger) | Auslösewert (Trigger value) | Überblendung (Fade) | Verzögerung (Delay) |
|---|---|---|---|---|
| Cue 1 | beat | 1 | 80ms | 0ms |
| Cue 2 | wait | 60 ms | 1s80ms | 0ms |
Für den Blitz-Effekt sind die Überblendzeiten natürlich bei 0. Trägst du die aber ein, dann bekommst einen taktgesteuerten Pulseffekt.
PS.: Auch wenn es vom Titel her in die gleiche Richtung geht - inhaltlich war der Thread hier anderes gelagert. Eventuell lagere ich deine Frage noch nochmal aus. Mal schauen. Falsch wäre es nicht gewesen, einen neuen Thread zu starten. ![]()
Soweit so gut, die Szenenliste passt. Aber wieso ist die Beaterkennung im Vergleich zur BeatDetection von DMXControl 2 so grottig? Ich hab mal auf zwei baugleichen Rechnern die gleiche Audioquelle via Mischer drauf gegeben; auf dem einen Rechner DMXControl2 mit dem BeatDetection Plugin und auf dem anderen DMXControl3 mit Audio Analyzer um das ganze mal objektiv vergleichen zu können. Was Beaterkennung angeht ist das alte Plugin deutlich genauer (also nicht nur so ein Empfinden). Und ja ich habe an den Einstellungen ziemlich viel rumprobiert; auch verschiedene Algorithmen.
Kann man nicht irgendwie den Algorithmus aus dem alten Plugin in den Audio Analyzer holen? Ich weiß dass die Funktion erst seit dem letzten Update wieder mit drin is; aber mit dem aktuellen Stand ist gerade diese Beat-Strobe Geschichte einfach nicht brauchbar, weil es mehr einem Zufallmuster gleicht und überhaupt nicht zur Musik passt (und hätte noch andere Anwendungen wo das eigentlich wichtig wäre)
Danke für deinen Hinweis dazu.
Ich hatte das bereits schon mal angemerkt. Es wird daran gearbeitet das Plugin zu verbessern. Wir werden das Thema intern noch einmal aufgreifen. Das kann aber eine weile dauern, bis wir dafür eine Lösung haben.
Gruß
Nutzer99