audio sequencer mit bpm

[freak911]

hi,
ich arbeite in meinem schulprojekt z.Zt. an einem audio sequencer in delphi..
wir sind noch in der phase der anforderungsdefinition, trotzdem stellt sich mir
schon die frage wie man das herzstück: das abspielen von samples in einem 4/4 taktmuster
und akurater bmp-zahl realisieren kann... wer ideen hat bitte nicht zögern!!
falls genug interesse besteht werde ich das ganze projekt im weiteren verlauf und
seinen versionen hier posten und diskutieren. Danke im vorraus!!!

[mischerr]

Also ich würde es mit einem Thread versuchen, der mittels QueryPerformanceCounter, QueryPerformanceFrequency und / oder GetTickCount nichts anderes macht, als der eigentlichen Anwendung per SendMessage das nötige Timing liefert.
Wenn du einen Sequenzer schreibst, dann werden ja wohl auch mehrere Spuren laufen die für Midi oder WAV-Samples zuständig sind. Vielleicht sollte auch hier je Spur ein Thread für das Abspielen / Aufzeichnen zur Verfügung stehen.
Ist aber nur ne Idee, die man vielleicht mal testen sollte...

Grüsse!

[dizzy]

Die Idee mit dem Thread für's Timing ist net schlecht, wobei das an sich auch der Timer aus der MMSystem.pas ähnlich gut aufgelöst erledigen könnte.
Aber pro Spur einen eigenen Thread zu erzeugen wäre nicht mehr so elegant. Laut OH ist eine praktikable Thread-Anzahl pro Prozess auf einer SingleCPU 16. Threads erzeugen bei einer gewissen Häufigkeit nicht zu vernachlässigen Overhead den man bei dieser Art der Anwendung nicht so gut gebrauchen kann
So ziemlich alle Sequenzer die nicht mit MIDI-Daten arbeiten, sondern mit Synthesizern und/oder Wave-Samples verwenden einen Buffer von mehreren Millisekunden Länge, in den kontinuierlich das Mixdown rein gerendert wird, und vom Player-Subsystem sukzessive ausgelesen. Je größer der Puffer, desto sicherer ein durchgehender Klang, aber auch längere Reaktionszeiten auf z.B. Buttonclicks wie Play oder Stop.
Aber das ist die übliche Praxis.

Grundsätzlich gälte es schon mal logisch zwischen Taktung, Tonerzeugern (Waves/Synth.), Mixersystem, ggf. FX-System (auch ggf. Spurbezogen oder Mastereffekte), und die Player-Schicht zu trennen. Dann ist es leichter einzelne Subsysteme zu bearbeiten, ohne dass sich Änderungen durch den gesamten Code ziehen (Stichwort: Strenge OOP).

gruss,
dizzy

[mischerr]

Ah, das mit dem Buffer klingt interessant! Und das gibt keine Performanceprobleme? Z.B. 64 Spuren oder mehr laufen, wo z.B. 48 WAV wiedergeben und dort noch Effekte draufliegen? Das Hauptproblem scheint mir hier die Koordination beim Füllen dieses Buffers...
@freak: Sicher ein interessantes Projekt, das interessant wäre hier weiterverfolgt werden zu können...

[SirThornberry]

Zum Buffer - Wenn jemand Pause klickt wird das sofort ausgeführt da nur die ausgabe gestoppt wird, hätte ja keinen sinn bei sowas erst alles aus dem Buffer abzuspielen und diesen dabei leer laufen zu lassen. Anders sieht es aus wenn man in einem Lied springt (position ändert). In so einem Fall leere einige Programme einfach den buffer und somit ist der sprung auch sofort zu hören. Bei richtig guter Software wird dann noch ein extra Treiber mit ausgeliefert der im Kernelmodus läuft und somit auch aussetzer verhindert. Standardmäßig wird mit Waveout der Ton ausgegeben (hoffe ich irre mich nicht), besser ist allerdings den Ton mit DirectSound auszugeben da der WaveOut-treiber nicht der stabilste ist und beim umschalten zwischen Fenstern sonst aussetzer zustande kommen können.