PLUGIN: LiveFX-Klon

Moin - ich melde mich mal wieder aus der Versenkung ;D

Da nun auch web.de DMXCmails lustig in den Abfall verschiebt (oder ein Spassvogel da nachgeholfen hat :o) posaune ich mal nun ein paar Kleinigkeiten in die Öffentlichkeit. Auf diesem Server ist der Kram ja sicher

==============================

Source in D4 - bringt also nur begrenzt was. Deswegen hier genaue Funktionsbeschreibung:
(mit IF D<->VB komme ich nicht voran...)

LiveFX erzeugt Bewegungen und Verläufe mit ziemlich geringem Daten/Rechenaufwand, da es außerhalb des Cue-Konzeptes agiert. Es macht einen Grosteil von ecues Effect-Engines aus. Es sollten sich beliebig viele ch einbinden lassen. In meinem PoC habe ich auf 24 limitiert.
Kern ist ein Ringpuffer (entweder Byte oder Word wenn intern 16bit). Auf diesem Array bewegt sich ein Schreibkopf der den Output einer Seedfnkt (zB.: Sinus, Dreieck, Square, Spike,...) in eine Zelle schreibt und dann den Pointer verschiebt.
Für jeden ch gibt es einen Lesekopf, der die Daten aus dem array aufnimmt, ausgibt und dann auf das nächste Feld angesetzt wird. Der Abstand der Leseköpfe zueinander vermittelt lustigerweise den Eindruck der Geschwindigkeit. Zu große Abstände zerstören jedoch das Muster und lassen es chaotisch wirken.
Ich treibe den Ringpuffer konstant mit einem 60ms-Timer (threaded).

Die Seedfnkt sollte periodisch verlaufen. Die Auflösung der Fnkt nimmt Einfluss auf Geschwindigkeit. Falls der Ringpuffer so dimensioniert wird, dass exakt eine Periode darin Platz findet, sollte man die Erzeugerfunktion+Schreibkopf soagar nach einer Füllung abwürgen können.

Entscheidend ist es, dem Schreibkopf einen Offset von ch*Abstand mitzugeben, sodass der schreibkopf direkt vor den Leseköpfen herläuft. So wirken sich Änderungen ohne Latenz aus.

Ich denke, alles wichtige beschrieben zu haben. Der nette Farbverlauf ist bereits aus der Tut-Matrix bekannt. Das funzt auch hier wunderbar.

Bei techn. bitte posten oder PN.
Was den Sinn/Nutzen angeht: Ecue wird sich was dabei gedacht haben - und ich mags auch ;D

Hendrik

Was mir gestern noch einfiel: Man könnte ja - falls der Ringbuffer auf eine Periode dimensioniert wurde - ihn gleich zu Beginn (bzw. bei jeder Änderung) auf einen Rutsch vollschreiben und dann wie oben beschrieben auslesen.
So spart man sich den Schreiboffset

Hendrik

Das Problem ist, den Ringpuffer auf genau eine Periode auszulegen. Bei einem Sprung zwischen Anfang und Ende wirds sonst hässlich - andererseits ist das Lichttechnik und kein PA...

Über den Timer könnte man dann auch noch zusätzlich Einfluss auf Geschwindigkeit nehmen.

Sehr interessant ist auch, die Nullage zu definieren und die Amplitude der Schwingungen: So lässt sich exakt z.B. eine Scannerwelle auslegen

================================
Ringpuffer: array[0..99] of word;
Nullage: byte;
Amplitude: integer;

Ringpuffer[i]:= Nullage + Amplitude*sin((1.6*10^-3)*x);

Du hast den Trick noch nicht ganz verstanden:

Es gibt ein (globales Array) auf dem die Seedkurve aufgetragen wird.

Jeder Kanal hat einen Lesekopf auf diesem Array:

ch1:= Ringbuffer[i];
ch2:= Ringbuffer[i+Offset];
ch3:= Ringbuffer[i+Offset*2];
...

if i > 'Ringbufferlänge' then i:=0;

bei den Offsets:
if (i+Offset*y) > 'Ringbufferlänge' then (i+Offset*y):= (i+Offset*y - 'Ringbufferlänge');

Durch Inkrementieren von i wird der Ringbuffer angetrieben. Somit kannst du mal schnell 100ch ohne großen Rechenaufwand versorgen. (Das ist ja grad das Geniale, warum ich das hier poste ;D)

Hendrik

invers direction:

if invers then
begin
i:=i-1;
if i =0 then i:='RL';
end
else
begin
i:=i+1;
if i > 'RL' then i:=1;
end;

Hier hast Du Deine Omma ;D

Jep. Wer sagt denn, dass nicht mehrere Instanzen davon laufen können?

Auch der Modulator liegt im Bereich des Möglichen - die Frage ist nur, ob die Zielgruppe dann nicht die Krise kriegt...

Stefan:
Wenn D schon hakelt wie Sau - wie steht's mit VisualC? Ich bin ja für alles offen - aber VB als Maschi... Wozu soll das gut sein?? Diese Zeitinvestition macht für mich einfach keinerlei Sinn...
BTW: Was für Szenentypen? Dies steht außerhalb des Cue/Szenenkonzepts...

Hendrik

zu VB:
Keiner möchte Dir vorschreiben, in welcher Sprache du zu arbeiten hast. Die jetzige Plugin-Referenz zwingt jedoch Anwender darin zu werkeln (property_get...). Falls dem nicht so ist, bin ich zu blöd, um einen workaround zu finden...
Wenn also D schon hakelt, wäre ich dankbar wenn C++ als Alternivsprache für Plugins zu Verfügung stehen würde.

zu den Szenen:
Diese Engine steht außerhalb des von Dir genannten Konzeptes: Das Fading von Szenenarrays ist bei 4-20ch und geringer Parallelisierung sicherlich ein gängiger Weg, den alle nutzen. Für massive Parallelisierung verhält sich aber die hier beschriebene Engine erheblich performanter und einfacher. (Zum Spaß ist das bestimmt nicht bei der Oma und ecue verbastelt worden...)
Falls eine Einbindung ins Befehlskonzept erwünscht ist: Launch eines Presets bestehend aus seed, speed, amplitude und position per Befehl.

Vielleicht wird es so ja klarer:
http://www.ecue.tv/liveFX.36.0.html

Dann meinen wir ja beide das Gleiche ;D

Was D angeht: Diese Geschichte ist doch sowieso eher was für VC (keine wirklich tolle GUI...). Stehen da die Chancen der Zusammenarbeit besser oder ist das genauso Neuland?

Hier jetzt über den Sinn zu streiten ist eh nicht sinnvoll - ich wollte endlich mal ein Plugin (mit)schreiben und ich hielt das für ganz unterhaltsam.