Seite 15 von 22

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 28. Jan 2017, 11:48
von DOSferatu
zatzen hat geschrieben:Das ist natürlich ziemlich genial wenn man mehrere Bildschirmseiten nutzen kann. Ich glaube bei EGA
geht das auch.
Wichtig ist ja nur, daß der Speicher ausreicht. Man kann theoretisch auch im MCGA den "Bildanfang" verändern - nur daß man nur maximal 4,8 Zeilen "unten" noch hätte, danach geht das Bild von vorn los.
zatzen hat geschrieben: Mode-X hat ja, wenn ich nicht irre, auch den Vorteil wirklich quadratischer Pixel.
Naja, das liegt weniger am Mode-X, sondern eher daran, daß man durch den Mode-X auch Auflösungen größer als 320x200 erzeugen kann, z.B. 320x240, was dem Seitenverhältnis 4:3 emtspricht.
(Anmerkung: Ich habe für meine Sprites eine Option, diese entsprechend dem Bildverhältnis automatisch strecken/stauchen zu können - das kann man z.B. benutzen, wenn die Sprites sich drehen, dann sieht es etwas besser aus.)
zatzen hat geschrieben:Aber ich bin ersteinmal so im Trott mit MCGA, dass ich wohl die 64000 Byte opfern werde.
Bzw. etwas weniger, siehe meine Methode für das Scrolling.
Ja, ich könnte sehr vieles, was ich hier schon habe, auch wieder verbessern - allerdings will ich endlich mal wieder ein Spiel bauen und da muß ich auch einfach mal einen Schlußstrich unter manche Units setzen und sie als "vorläufig fertig" definieren. Man kann auch später immer noch an so Units feilen - ich neige dazu, mein Zeug abwärtskompatibel zu bauen.
zatzen hat geschrieben:Das mit der Scanline klingt interessant, und ich würde mich für ein Spiel auch mit sichtbaren 320x160
zufrieden geben. Allerdings brauche ich ja, zumindest für zweidimensionales Scrolling mit ZVID,
rundherum unsichtbare Fläche. Das ist natürlich alles andere als optimal, ich habe lediglich momentan
nicht die Nerven dazu, ZVID ein Clipping zu verpassen.
Ich hätte dazu einen Vorschlag - weiß nicht, ob er Dir gefallen wird:
Gehen wir mal davon aus, daß der Umstand, daß ein Sprite sich am Bildrand tummelt, eher die Ausnahme statt die Regel ist. Da könnte man doch eine (vielleicht etwas langsamere, dafür aber den Rand berücksichtigende) Subroutine bauen, die nur in dem Fall aktiviert wird, wo dies nötig ist und ansonsten die schnelle ohne Clipping.

Was für eine Art Spiel schwebt Dir denn so vor, das Du machen willst? Welches Genre? Oder ist das noch geheim und soll eine Überraschung werden?
zatzen hat geschrieben:Es ist eine Weile her, aber den AdLib-Trick habe ich auch einmal gelesen, es war ungefähr so:
Man stellt z.B. auf einem Kanal einen Sinus ein, stellt eine bestimmte Frequenz ein, startet
den Ton auf diesem Kanal und setzt in dem Moment, wenn der Sinus auf dem höchsten Punkt
ist, die Frequenz auf null. Danach kann man durch variieren der Lautstärke digitalen Sound
abspielen.
Ja, so ähnlich hatte ich das auch im Gedächtnis. Und so ähnlich funktioniert übrigens auch der Trick mit dem PC-Speaker.
zatzen hat geschrieben:Ich weiss nur nicht mehr genau, welche Auflösung der Lautstärkeparameter hat, 16 Stufen wären ein bisschen wenig.
Naja, soweit ich weiß, kann der SoundBlaster 16 Stufen (alte Soundblaster 8 Stufen).
zatzen hat geschrieben:Ich habe mir prISM 0.11 gerade angesehen und habe schonmal begriffen, wie man einen Klang defininiert und Noten setzt. Ich glaube, damit kann man gut arbeiten, wenn man einmal "drin" ist.
Schön, daß sich meine ganze Mühe wenigstens etwas gelohnt hat. Und ja, ich weiß, daß ein Tracker-Musiker hier wahrscheinlich erheblich "umdenken" muß. Ich hatte anfangs noch gedacht, eine "Tracker"-Ansicht in prISM einzubauen, aber ISM ist so unterschiedlich zur regulären MOD-Struktur, daß ich darin (so eine Ansicht einzubauen) kaum noch Vorteile erkenne. Ein MOD-zu-ISM Konverter wäre noch eher möglich. Aber - wie ich bereits erwähnt habe - sehe ich darin nur die "Gefahr", daß man dann nur noch MODs damit wandelt, somit vollständig auf Samples setzt und den Synthesizer außen vor läßt - was genau das Gegenteil von dem wäre, was ich eigentlich mit ISM bezweckt habe.
zatzen hat geschrieben:PLAYBOX finde ich auch sehr schön, schon ein recht komplexes Stück mit einem gewissen "8 Bit" Charme. Allein daher finde ich, dass ISM sehr viel Sinn macht.
PLAYBOX ist nicht in ISM gemacht - es ist mein uraltes MSX-Format, das keine "Instrumente", Laufstärken u.ä. zuläßt und es ist damals für PC-Speaker (nicht "digital") gemacht worden. Meine dazugehörige Musikroutine spielt die Stimmen so ab, daß immer im Wechsel die Frequenzen der Stimmen auf dem Speaker ausgegeben werden (so wie auch z.B. bei Xenon 2).
Und PLAYBOX ist nur 2-stimmig und hat nur ein "Instrument".
Erklärung dazu:
Damit ich etwas "Material" habe, habe ich mir einen Konverter geschrieben, der MSX in ISM wandelt und dabei am Anfang irgendwelche Standardwerte für die "Instrumente" und Lautstärke setzt.
(MSX hatte solche Parameter nicht, weil es ja nur das eine Instrument kennt. - aber MSX hatte auch schon Sprünge, Schleifen, Transponieren usw.)
Will sagen: Mit ISM selbst kann man natürlich besseres machen als PLAYBOX.ISM (Das ist übrigens die Titelmusik von meinem gleichnamigen Spiel - auf meiner Webseite im Bereich MS-DOS/Spiele zu finden.)
zatzen hat geschrieben:Vielleicht hast Du oder jemand einen Musikwunsch den ich in prISM umsetzen würde.
Spontan fällt mir erst einmal nichts ein. Hm... Vielleicht eine der Musiken von Lemmings? Die fand ich immer recht schick.
zatzen hat geschrieben:Das wäre mir die Erfahrung wert, allerdings brauche ich für sponante Improvisationen doch eher einen Tracker, deshalb würde ich in prISM nur etwas programmieren, das schon steht.
Naja - verstehe ich zwar nicht ganz, da man ja auch in prISM nachträglich Befehle einfügen/löschen kann, so daß man auch später noch daran herumändern kann. Aber mir ist natürlich klar, daß diese Ansicht gewöhnungsbedürftig ist - weil gleichzeitig gespielte Bereiche NICHT mehr nebeneinanderstehen und man nicht einfach zwischen zwei Noten eine weitere setzen kann, ohne die Längen der anderen Noten anzupassen für gleichbleibende Gesamtlängen.

Ich selbst hatte nicht damit gerechnet, daß prISM SO seltsam und ungewöhnlich für PC-Musiker sein würde - aber es ist natürlich verständlich: Der Mensch ist ein Gewohnheitstier und jahrzehntelange Tracker-Erfahrung wirft man auch nicht "mal eben so" über Bord, nur weil da ein neues komisches Sound-Konzept um die Ecke kommt, das zu nix kompatibel ist außer zu sich selbst.
zatzen hat geschrieben:Für ZSMPLAY schreibe ich gerade einen "Starter" oder wie ich es nennen soll. Ich habe
mich ja durch die Archive gegraben und mittlerweile ein paar hundert Module konvertiert.
Deshalb wollte ich schon allein für mich ein Programm haben, das die Dateien mit
Titeln usw. auflistet und sortiert, und aus dem man dann den Abspielvorgang starten kann
oder sich auch eine Playlist zusammenstellt.
Klingt gut!
zatzen hat geschrieben:Ich wollte es ursprünglich spontan "zsmshell"
nennen, aber meine Recherche ergab dass eine Shell vielmehr soetwas wie eine
Kommandozeilen-Konsole ist. Also, wenn jemand noch einen besseren Namen
hat als "ZsmPlay Starter", würde ich mich über Vorschläge freuen.
Soweit ich weiß, bezeichnet man solche Dinge heutzutage als "Frontend".

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Di 7. Mär 2017, 21:51
von zatzen
Hier der neue ZSMPLAY-Release, Version 0.04


Neuerungen am Format:

- Die Samples liegen nun im 4 Bit Delta Format vor und werden über eine nichtlineare Tabelle
in Echtzeit dekodiert. Zusammen mit der Patternkomprimierung und der Sample-Optimierung,
bei der nicht gespielte Teile von Samples und auch eventuell vorliegende stille Enden der
Samples entfernt werden, ergeben sich nun sehr viel kleinere Dateien und dementsprechend
weniger Speicherbeanspruchung.
Die Einschränkung der Klangqualität ist je nach Sample minimal und sehr tolerabel, im
ungünstigeren Fall kommt es zu erhöhtem Rauschen oder andererseits zu verstärktem Aliasing
bei eigentlich sehr klaren Samples.

- Die Lautstärke hat jetzt 16 logarithmische Stufen.
Die logarithmische Skalierung war schon eine gute Entscheidung, allerdings waren 8 Stufen
zu wenig, aber mit 16 Stufen sind diese nun kaum noch hörbar bzw. werden alle vorhandenen
Lautstärken mit akzeptierbarer Genauigkeit wiedergegeben.

- Es wird das Datum gespeichert und die Song-Message


Änderungen am Player:

- Die größte Änderung ist die Umstellung auf 4 Bit Delta Samples.
Darunter leidet natürlich die Performance, und der Player ist nun mit Sicherheit langsamer
als die Vorgängerversionen. Allerdings dürften 4-kanälige Module noch flüssig auf einem 386er
abgespielt werden können. Nur für deutlich mehr Kanäle wird es einen 486er brauchen.
Für ein Spiel würde ich aber sowieso einen 486er voraussetzen, und andererseits könnte
ich mich dabei auch auf 4 Kanäle beschränken.

- Man kann nun zwischen 11, 22 und 44 kHz Mixfrequenz wählen.
Standardmäßig ist 44 eingestellt, ich weiß aber nicht ob das alle Soundblaster mitmachen.
Außerdem könnte man probieren, ob Module mit sehr vielen Kanälen bei 11kHz noch auf
einem 386er laufen.
44100 Hz bieten allerdings die beste Klangqualität, es entsteht praktisch kein Aliasing und
der Klang ist vergleichbar mit dem eines Amigas, auf dem die Kanäle hardwareseitig gemischt
werden.
Der Performance-Unterschied zwischen 11 und 44 kHz ist nicht etwa, wie man erwarten
könnte, Faktor 4, sondern eher nur 2.

- Die Änderung von 8 auf 16 Lautstärkestufen habe ich eher provisorisch umgesetzt, es kam
ein Sprungbefehl und ein bisschen Arithmetik in einer der inneren Schleifen dazu. Ich könnte
das durch eine Tabelle lösen, diese würde allerdings 8K beanspruchen.
Das ist zumindest mein spontaner Gedanke, vielleicht geht es auch anders.

- Der DMA Puffer wird nun vernünftig eingerichtet (Danke an wobo)

- Der Player startet nun sauber (erster Pufferinhalt nicht doppelt)

- Soundblaster-Parameter lassen sich per /BLASTERbbbid bestimmen


Neuigkeiten bzgl. der Anzeigen:

- Der Tänzer ist in Rente und musste der Sample-Aktivitäts-Anzeige sowie der neuen
Channel-Anzeige weichen. Die Patternanzeige gibt es in dieser Version auch nicht mehr.
Denkbar für die die Zukunft wäre eine Patternanzeige wie im Tracker, also vertikaler
Verlauf, in einem extra Modus. Dafür müsste ich allerdings einen Prefetch der Pattern-
daten einrichten, der fürs bloße abspielen aber nicht benötigt wird.

- Scope mode macht jetzt Linien statt Punkten. Durch drücken von "H" (für Hold) kann
man die Anzeige einfrieren um die Wellenformen in Ruhe zu betrachten. Das war für mich
sehr hilfreich beim debuggen der Schleifenroutine.

- Neuer Modus: Sample Details, u.a. Größenangabe und genaue Abspielfrequenz

- Zeilenweise Anzeige der Song-Message (bei einigen Modulen lediglich die Sample-Namen)

- "Sample Data Processing Rate" gibt den gesamten 4-Bit-Delta-dekodier-Umsatz pro
Sekunde an, bei einem einzigen Sample auf 8192 kHz gespielt ergäbe sich eine Rate von 4K.

- CPU Anzeige: verfärbt sich ins Rote, wenn die Performance schwach wird. Grob umgesetzt
durch einfaches Zählen der übrigbleibenden Idle-Cycles.

Es hat sich noch ein bisschen mehr verändert, aber das dürfte selbsterklärend sein.

Danke an dieser Stelle auch nochmal an DOSferatu, der mir viele fortschrittliche
Vorgehensweisen in Pascal und Assembler sehr verständlich vermittelt hat.


Für den Player habe ich noch ein Frontend geschrieben, ZSMSTART, es listet die Dateien
mit Titel usw. auf und man kann diese bequem starten und auch eine Playlist erstellen.
Auch ist dort die manuelle Soundblaster-Konfiguration möglich, wie auch die Wahl der
Mix-Samplerate. Die Konfiguration wird beim Verlassen gespeichert, ebenso die Playlist.


Ich habe u.a. das offizielle modarchive(.org) durchstöbert, auch um für mich selbst neue
interessante Module zu finden. Dort habe ich gerade die Kategorien Sonderzeichen, Ziffern,
A und B hinter mir gelassen und es haben sich schon über 1000 mit ZSM kompatible Module
angehäuft.
Ich habe davon einige (310) ausgewählt und dem Paket hinzugefügt.
Übrig bleiben noch die Kategorien C-Z, und das sind 24 Stück. Wenn ich so vorgehe wie
bisher dann gibt es noch 6 Vierergruppen, aus denen ich am Ende jeweils um die 250-300
herausfiltere.
Diese Begrenzung kommt daher, dass der Starter momentan auf 2000 Dateien beschränkt
ist, um für den Player noch genug Heap übrig zu lassen.
Es macht aber auch so Sinn, die vielen Module etwas auszusieben.

Hier nun die ZIP:
http://www.zatzen.net/zsmp004b.zip
9,6 MB, entpackt 11,7 MB.
Man kann sehen, dass sich die neuen ZSMs nicht mehr so gut komprimieren lassen.
Die 4 Bit Samples haben wohl eine höhere Informationsdichte.

Der Sourcecode ist wie immer dabei, so habe auch ich immer einen offiziellen Release im
Internet gesichert. Ihr könnt den Player gerne wieder "forken", für andere Anwendungen
wie in Spielen würde ich allerdings gern vorher noch einmal Hand anlegen, um die ganzen
Routinen und Variablen zu entfernen, die nur der Anzeige bei ZSMPLAY dienen.
Ansonsten bitte nichts verändern und bei eigener Verwendung der Player-Routinen "Credits"
geben.
Diese müssen meinerseits natürlich auch an die ganzen Musiker gehen, deren Module ich zu
ZSM konvertiert habe, allerdings sind die meisten ja auch mit Namen in den ZSMs erwähnt,
soweit das die MODs und S3Ms hergaben.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Do 23. Mär 2017, 19:19
von DOSferatu
zatzen hat geschrieben:Hier der neue ZSMPLAY-Release, Version 0.04


Neuerungen am Format:

- Die Samples liegen nun im 4 Bit Delta Format vor und werden über eine nichtlineare Tabelle
in Echtzeit dekodiert. Zusammen mit der Patternkomprimierung und der Sample-Optimierung,
bei der nicht gespielte Teile von Samples und auch eventuell vorliegende stille Enden der
Samples entfernt werden, ergeben sich nun sehr viel kleinere Dateien und dementsprechend
weniger Speicherbeanspruchung.
Ich habe mir den Sourcecode nicht angeschaut - größere Sourcen von anderen schaue ich mir
nicht an, da brauche ich normalerweise zu lange um durchzusehen/alles nachzuvollziehen.
Daher meine Frage: Du packst die Samples 4-bit Delta, was ja bedeutet, daß um die Amplitude
für Stelle (Frame) X zu kennen, vorher alle 0 bis X-1 durchgelaufen sein müssen, da Delta ja immer jeweils
zum vorhergehenden Frame referenziert. Liegen die Samples während des Abspielens in diesem
4-Bit-Format im Speicher? Wenn ja, wie regelst Du das, wenn im Sample (für höhere Frequenzen)
mehrere Frames übersprungen werden müssen? Da müssen ja trotzdem die "Zwischenframes" berechnet
werden, sonst stimmt ja das neue Frame nicht.
Oder werden die Samples beim Laden des Musikstücks entpackt und liegen dann 8-Bit im Speicher?
zatzen hat geschrieben: Die Einschränkung der Klangqualität ist je nach Sample minimal und sehr tolerabel, im
ungünstigeren Fall kommt es zu erhöhtem Rauschen oder andererseits zu verstärktem Aliasing
bei eigentlich sehr klaren Samples.
Also ich für meinen Teil kann da nicht im geringsten meckern. Es klingt für mich alles sehr gut -
meist sind weniger Stimmen besser als mehr Stimmen - bei zuvielen Stimmen wird es Soundbrei.
Ich muß sagen, daß Leute oft mit 4 Stimmen und einer Handvoll kleiner Samples oft die viel
besseren Stücke gemacht haben als die mit 12 oder 16 Stimmen und ganz vielen großen Samples.
Außerdem werden oft von so Leuten die mehreren Stimmen (also wenn es 8 oder mehr sind) nur
(total lame) benutzt, um einen Teil lauter zu machen, indem mehrere Stimmen das gleiche
Spielen - weil sie wohl zu faul sind,das über Lautstärkenabgleiche zu machen. Das erfordert im
Endeffekt mehr Rechenzeit und mehr Stimmen, wo es nicht nötig wäre.
Das ist natürlich kein Fehler von ZSM, sondern von den entsprechenden MOD-Komponisten.
Aber im Großen und Ganzen hast Du gute Stücke ausgesucht - manche haben schon fast
Suchtfaktor.
zatzen hat geschrieben: - Die Lautstärke hat jetzt 16 logarithmische Stufen.
Die logarithmische Skalierung war schon eine gute Entscheidung, allerdings waren 8 Stufen
zu wenig, aber mit 16 Stufen sind diese nun kaum noch hörbar bzw. werden alle vorhandenen
Lautstärken mit akzeptierbarer Genauigkeit wiedergegeben.
Und das klangliche Ergebnis kann sich hören lassen und rechtfertigt alle Deine Engine-/Design-
Entscheidungen vollends.
zatzen hat geschrieben: Allerdings dürften 4-kanälige Module noch flüssig auf einem 386er
abgespielt werden können. Nur für deutlich mehr Kanäle wird es einen 486er brauchen.
Für ein Spiel würde ich aber sowieso einen 486er voraussetzen, und andererseits könnte
ich mich dabei auch auf 4 Kanäle beschränken.
Ich habe (leider) keinen 386er und kann daher nichts dazu sagen. Allerdings habe ich schon
mitbekommen, daß mein Zeug (das ich immer mit "Mindestanforderung 386er) anpeise auf
einem wirklichen 386er eher sehr lau performt.
Ich bin mir nicht sicher, üb mein ISM-Kram auf einem 386er bei der Generierung der Sounddaten
überhaupt noch annehmbare Performance leistet, also so, daß die Daten fertig werden, bevor
der Puffer abgespielt ist UND noch Luft bleibt für restliche Dinge (Grafik, Steuerung).
Da sehe ich ZSM klar vorweg, das wird meiner groben Einschätzung nach wesentlich mehr
performen - und auch auch langsameren Maschinen.
zatzen hat geschrieben: - Die Änderung von 8 auf 16 Lautstärkestufen habe ich eher provisorisch umgesetzt, es kam
ein Sprungbefehl und ein bisschen Arithmetik in einer der inneren Schleifen dazu. Ich könnte
das durch eine Tabelle lösen, diese würde allerdings 8K beanspruchen.
Das ist zumindest mein spontaner Gedanke, vielleicht geht es auch anders.
Darunter kann ich mir nicht so richtig etwas vorstellen, wieso eine Skalierung auf 16 Stufen
zusätzliche Sprungbefehle braucht... Aber es kommt eben auch darauf an, daß das Ganze in
ein bereits bestehenden System integriert wurde - vielleicht blieb keine andere Möglichkeit,
das kann ich nicht einschätzen.
zatzen hat geschrieben: - Der DMA Puffer wird nun vernünftig eingerichtet (Danke an wobo)
Hätte ich damals auch schreiben können, aber Wobo hatte es bereits ausführlich und verständlich
erklärt - dem war nichts hinzuzufügen.
Mir war dieser eklige Umstand dieses Pagings bereits von Anfang an bewußt und ich hatte daher in
ISM eigens eine Subroutine zum reservieren von Speicher mit diesen Vorgaben eingebaut.
zatzen hat geschrieben: - Der Player startet nun sauber (erster Pufferinhalt nicht doppelt)
In prISM wird der erste Puffer scheinbar immer nicht gespielt (wenn mit Blaster, bei Speaker gehts).
Ich muß irgendwie noch rausfinden, was ich da verbocke. Wenn man ein Stück darin abspielt, klingt
der allererste Ton oft zu kurz.
zatzen hat geschrieben: - Soundblaster-Parameter lassen sich per /BLASTERbbbid bestimmen
Man könnte ja auch (wenn vorhanden) die BLASTER-Umgebungsvariable auslesen.
zatzen hat geschrieben:Neuigkeiten bzgl. der Anzeigen:
Ich zitiere das mal nicht alles, will aber mal allgemein festhalten: Die Ausgabe finde ich sehr gelungen. Intelligent gegliedert, übersichtlich, dabei nicht aufdringlich. Angenehm für's Auge und informativ für's Gehirn.
zatzen hat geschrieben: Danke an dieser Stelle auch nochmal an DOSferatu, der mir viele fortschrittliche
Vorgehensweisen in Pascal und Assembler sehr verständlich vermittelt hat.
Immer gern. Ich muß auch zugeben, die 4Bit Samples "indirekt" zu speichern und dann
quasi mit Delta-Packing und entsprechender Skalierung - darauf bin ich nicht gekommen.
Die Idee finde ich interessant. Ich habe ähnliches zwar mal vor ein paar Jahren für ein
Projekt (einfach gesagt, eine Art Datenstream-Logger) gebaut, hatte aber noch nicht den
Einfall, derartiges für Klangdaten zu verwenden.
zatzen hat geschrieben: Für den Player habe ich noch ein Frontend geschrieben, ZSMSTART, es listet die Dateien
mit Titel usw. auf und man kann diese bequem starten und auch eine Playlist erstellen.
Auch ist dort die manuelle Soundblaster-Konfiguration möglich, wie auch die Wahl der
Mix-Samplerate. Die Konfiguration wird beim Verlassen gespeichert, ebenso die Playlist.
Sehr bequem und praktisch. Ich liebe es[tm].
zatzen hat geschrieben: Ich habe u.a. das offizielle modarchive(.org) durchstöbert, [...]
Ich habe davon einige (310) ausgewählt und dem Paket hinzugefügt.
[/quote}
Wie bereits erwähnt, sind da viele sehr beeindruckende Dinge dabei.
(Deine Version des Entenlieds macht übrigens auch viel mehr her als mein Test-Entenlied.)

Wenn ich das Klangvolumen, die Klarheit und die ganz allgemeine subjektive Qualität
vergleiche, schneidet Dein ZSM in jeder Hinsicht um Längen besser ab als mein ISM.
(Da fühlt man sich fast geneigt, ISM/prISM wegzuschmeißen und in künftig geplante
Spiele lieber eher ZSM einzubauen...)

Man merkt, daß Du aus der "Sound-Ecke" kommst und Dich mit Musik und Klangtheorie
beschäftigt hast und auskennst. Ich dagegen versuche nur immer, daß die Welle möglichst
so aussehen soll wie sie eingestellt wurde und daß auch die restlichen Parameter die
entsprechend geänderten Daten liefern - alles rein mathematisch. Ich bin schon erstaunt,
daß mein Zeug überhaupt noch nach etwas klingt, das sich so ähnlich wie Musik anhört,
bei diesen Voraussetzungen, bzw bei dem ganzen Ansatz von ISM. Ich habe von der ganzen
Theorie überhaupt keine Ahnung. Ich wüßte nicht mal, wie ich meinen Kram in Dezibel
umrechnen kann und beim Arbeiten mit prISM probiere ich so lange rum, bis der Zahnschmelz
aufhört abzubröckeln, das ist kein richtiges Komponieren...

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Do 23. Mär 2017, 22:27
von zatzen
Zunächst einmal: Ich finde ISM absolut nicht "wegschmeissenswert".
Es hat seinen eigenen Charme und kann, wenn ich nicht irre, komplexere
Klänge erzeugen als es mit ein paar Mini-Samples (ein paar dutzend Bytes als
Schleife) in ZSM möglich wäre.
Mein Problem ist nur das "komponieren" in prISM. Auch wenn ich in Deinem
Thread geschrieben habe, die Erfahrung wäre es mir wert, muss ich doch
gestehen, dass mir die intuitive Erstellung von Musik damit etwas schwer
fallen würde.
Ich brauche beim "Komponieren" diese redundanzüberladenen Patterns,
zumindest hat sich das bei mir so eingeprägt, innerlich habe ich mir bei
der meisten Musik eine gerasterte Zählweise angewöhnt, meistens
16tel-Einheiten. Es gibt also für mich gar nicht wirklich mehr Notenlängen,
sondern vielmehr Positionen, an denen sie ihren Anfang und ihr Ende haben.
Das ganze Trackerprinzip ist ja wie die Walze einer Spieluhr...
Das MOD-Format ist nun aber auch eines der ersten dieser Formate und
hat wohl auch der Einfachheit halber keine Patternkomprimierung.
Nun *könnte* man die Musikdaten bei ISM auch als eine Kompression
verstehen, bloß eine ziemlich intelligente, weil vom User speziell so definiert.
Worauf ich hinaus will: Wenn Du mehr Musik für ISM willst, dann könnte man
doch mal an einen Converter, oder vielmehr an einen Compiler denken.
Zumindest Unterhaltungsmusik ist redundanter und strukturierter als man
auf den ersten Blick denken mag. Man könnte schon Wiederholungen finden,
indem man die Musikdaten halbnotenweise durchscannt, und dann vielleicht
noch weiter prüft, ob diese Wiederholung sich auch auf ganze Noten ausweiten.
Die speziellen Eigenschaften von ISM würden so trotzdem genutzt, denn
ISM kann Unterprogramme und viele Dinge die z.B. ZSM nicht kann.
Das würde also bedeuten, dass Deine Mühen, diese Funktionen in ISM
einzubauen nicht umsonst waren, sondern sie würden genutzt, auch
wenn man z.B. ein Trackerfile (mit stellvertretenden Samples) reingibt -
und am Ende könnte ein ISM rauskommen das wie per Hand programmiert
ist. Wahrscheinlich gefällt Dir so eine Idee immer noch nicht.
Bloß würde ich persönlich eher Zeit in so einen Compiler investieren,
anstatt ein Stück erst im Tracker zu programmieren und dann
"mit Papier und Bleistift" in prISM umzusetzen, letztlich würde ich,
abgesehen von Effekten, nicht viel anders machen als der Compiler.
Nochmals, es geht mir nicht darum, ISM obsolet zu machen, sondern
lediglich darum, Musik intelligent und die ISM-Features nutzend zu
konvertieren. Mit ein bisschen Brute Force müsste da schon was
zu machen sein, und vielleicht würde so ein Compiler sogar Dinge
"sehen", die man als Mensch beim direkten Programmieren in prISM
übersieht. Ob der Editor prISM dadurch an Bedeutung verlieren würde
weiss ich nicht. Es wäre vielmehr so, dass Du einfach zusätzlich mehr
Musik für Dein Format hättest.
Wir könnten da gerne zusammenarbeiten, wenn Du Dich dazu durch-
ringen kannst, und das ganze Dir nicht zu sehr gegen den Strich geht.
Ich fände es schade, wenn ISM nicht weiter wächst.
Man kann es so sehen:
ZSM reduziert die Patterngrößen indem die Events (z.B. Sample abspielen)
mit so wenigen Bits wie möglich beschrieben werden. Das geht soweit,
dass zwei gleiche aufeinanderfolgende Noten nur ein Bit benötigen.
Es ist also eine effektive Schrumpfung der redundanten Daten.
Eine gewissermaßen idiotensichere Methode, man gibt rein was man
will und es kommt das kleinstmöglichste raus.
ISM kann durch seine Programmiersprachen-ähnliche Auslegung auch
sehr speichersparend sein, verlangt aber vom User eine entsprechende
Vorgehensweise. Bzw. lässt sich diese gar nicht umgehen, da nach
Notenlängen und nicht nach Positionen im Pattern vorgegangen wird.
ISM bietet aber im Gegensatz zu ZSM nicht diese idiotensichere
Automatisierung an. Was bei ISM denkbar wäre, wie oben schon gesagt,
wäre ein Scannen eines redundant notierten Musikstücks nach Wiederholungen
usw. Ich hatte an soetwas auch bei ZSM gedacht, habe es aber bislang nicht
umgesetzt, weil ich mit der bisherigen Kompressionsrate der Patterns
zufrieden war und diese sich auch für Stücke ergibt, die sehr wenig
Redundanz haben. Diese gibt es aber kaum und deswegen könnte man
die Unterprogramme bei ISM für Redundanzen nutzen.
Wie gesagt, als zusätzliches Tool, einem Compiler von entsprechend
vorbereiteten Tracker Dateien, oder vielleicht auch MIDIs.
Wenn Du möchtest.


zu den 4-Bit-Samples:

Die liegen als 4 Bit im Speicher, als 8 Bit würde es ja keinen Sinn machen,
da hätte ich nur Platz auf dem Datenträger gespart und mir dafür die
Klangqualität eingeschränkt.
Ich halte in einem 8-Bit-Register immer die Phase (den aktuellen entpackten
Sample-Wert), und diese ändere ich durch Addition der aus der Tabelle
gelesenen Delta-Werte. Die Tabelle ist:

Code: Alles auswählen

(0, 1, 2, 4, 8, 16, 32, 64, 128, 192, 224, 240, 248, 252, 254, 255)
Dank des Überlaufs brauche ich nur positive Werte, und kann z.B. mit 255
von 0 auf 255 springen oder auch von 1 auf 0. Oder, vielleicht besseres
Beispiel, ich komme mit einer 16 z.B. von 120 auf 136, oder aber auch
von 250 auf 10, wofür man eigentlich eine -240 bräuchte, die es als
signed byte nicht gibt.
Diese Tabelle (die ich im Programm wegen Schnelligkeit direkt als 256 Words
angelegt habe, es wird immer direkt ein 16 Bit Register beladen, so spare
ich mir jeden zweiten Speicherzugriff) ist exponentiell - ob es dem Klang
zuträglicher gewesen wäre sie als halben Kosinus anzulegen habe ich nicht probiert.
Beim Konvertieren der Samples nach 4 Bit probiert der Konverter alle Tabellen-
werte durch und nimmt dann denjenigen der den geringsten Fehler ergibt.
Von diesem evtl. fehlerbehafteten Wert ausgehend wird das nächste Delta
gesucht usw.

Aber zum Durchlauf:
Praktischerweise unterstützt ZSM weder rückwärts Abspielen noch Sample Offsets.
Und für Schleifen habe ich ein Stütz-Byte für die Phase am Schleifenanfang.
Das mit den "Zwischenframes" war etwas schwierig, ich bin aber doch relativ
schnell zu einer Lösung gekommen:
Ich habe ja zu jeder Zeit die aktuelle Position im Sample. Also bilde ich jeweils
die Differenz zur Position davor. Im Grunde ist das sogar alles was ich wissen
muss, die Differenz, nicht einmal die Position - die Position im 4-Bit Stream
wird anderswo gemerkt.
Anhand der Differenz, nur Vorkomma, weiss ich nun, wie oft ich die Phase in diesem
Schritt aktualisieren, also den nächsten Wert aus den 4-Bit-Daten lesen muss und
aus der Tabelle. Bei einer Differenz von 0 muss ich selbstverständlich nichts
tun und jegliche Aktivität in der Schleife wird übersprungen.
Bei allen anderen Werten geht der Weg weiter in eine entrollte Schleife, diese
habe ich bis zu 7 Durchläufen realisiert, und es wird per Sprungtabelle jeweils
in den Teil der Schleife gesprungen, auf den noch so viele Durchläufe folgen
wie gebraucht werden.
Bei den Schleifen war es etwas fummelig bis auch die paar-dutzend-Byte Schleifen
den richtigen Tune hatten und auch alle Samplewerte im richtigen Bereich blieben.
Die Rechenzeit fürs Entpacken der Samples ist unabhängig von der Mix-Samplerate
und hängt nur mit der Samplerate der Samples selbst zusammen.
Trotzdem ist der Player mit 11 kHz deutlich schneller als mit 44, und das sagt mir
dass man evtl. noch etwas an den Mischroutinen außerhalb der entrollten Schleifen
drehen kann. Vielleicht liegt es sogar am Clippen und Shiften des 16 Bit Puffers,
und das folgende Überführen in den 8 Bit Puffer, obwohl ich das bisher als das
kleinste Übel angesehen habe.
Mir fällt gerade auf, dass es bei 11 kHz passieren könnte, wenn Samples sehr
hoch (> 77 kHz) gespielt werden (was durchaus vorkommt), dass der Player
dann abstürzen müsste... Evtl. erweitern...

Bisher hatte ich 8 Lautstärke-Stufen und habe diese durch einfaches
Shiften umgesetzt. Damit lassen sich aber nur Lautstärkestufen von 6 dB
realisieren, und das ist doch etwas zu grob.
Für die doppelte Auflösung musste ich jetzt Zwischenstufen einfädeln,
und das habe ich vorerst so gemacht:

Code: Alles auswählen

  mov ah, dl
  mov cl, 0; @voldata_full:
  test cl, 1
  jnz @vol_odd
  mov cx, ax
  sar cx, 2
  sub ax, cx { AX * 0,75 }
  @vol_odd: { 15, 13, 11, ... }
  sar ax, 0; @voldata:
DL ist die Phasenlage, d.h. der entpackte Wert aus den 4-Bit.
Der Geschwindigkeit halber lösche ich AL nicht, man wird es praktisch nicht hören.
@voldata_full: hier wird selbstmodifizierend die Lautstärke 0-15 reingeschrieben
@voldata: selbstmodifizierend der Shift-Wert, wird oben außerhalb der Schleifen
aus der 0-15 Lautstärke berechnet.
Bei geraden Lautstärken (14, 12, 10, ...) muss ein Viertel abgezogen werden.
Ziemlich viel Code für so eine simple Sache... Vorher sah das so aus:

Code: Alles auswählen

  mov ah, dl
  sar ax, 0; @voldata:
Und etwas später natürlich in den 16 Bit Puffer schreiben und die Position
weiterzählen:

Code: Alles auswählen

  add es:[di], ax
  db 66h; db 081h, 0c7h, 002h, 000h, 0ffh, 0ffh { add edi, 0ffff0002h }
Ich habe es irgendwie nicht hinbekommen, "db 66h; add di, sonstwas und dw 0002h etc."
zu definieren, oder irgendwie mit word ptr, daher habe ich das als einzigen Byte Code
hingeschrieben, den ich mir auf der Seite https://defuse.ca/online-x86-assembler.htm
erstellt habe.

AH als Phasen"träger" benutzen geht leider nicht, weil die
Phase ja durch das Shiften zerstört werden würde.


BLASTER: ZSMPLAY liest die Umgebungsvariable aus, aber nachdem das bei Wobo nicht
funktionierte habe ich noch eine Option zur manuellen Konfiguration eingebaut.

Ich hätte jetzt nicht damit gerechnet, dass Du sagst, dass sich ZSM evtl. für Spiele
eignen würde, zumindest nicht, nachdem diese Version nun langsamer ist.
Ich hatte/habe selber Zweifel, am liebsten wäre mir etwas, das sogar auf
einem 286er in einem Spiel funktioniert. Aber ich glaube soetwas hat es
nie gegeben, also MOD+Spiel auf einem 286er, ich kann mich nur an VGA-
Copy erinnern, wo im Intro ein MOD über den PC Speaker gespielt wurde.

Ich selber kenne Dezibel vor allem aus der Tonwelt, und da merkt man sich über
die Zeit so ein paar Dinge, wie dass 6 dB einer Verdopplung der Amplitude entsprechen,
in der Verstärkertechnik aber 3 dB mehr schon eine Verdopplung der Leistung sind.
Ansonsten ist das Dezibel eine Größe, die man auf alle Bereiche anwenden kann
wo man einen Wert mit dem anderen vergleicht. So glasklar war mir das bislang
auch nicht, obwohl ich ständig wie selbstverständlich damit umgehe.
Hier mal eine einfache Formel: Nehmen wir mal ein p als Zeichen für das
Verhältnis, was wir in dB ausdrücken möchten, dann gilt: p = 10 * log (a / b) dB .
Wenn also a 1 ist und b 2, dann ergeben sich hier -3,01 dB. Das wäre aber
jetzt leistungsbezogen, für Tontechnik spielt vielmehr die elektrische Spannung
eine Rolle und da rechnet man mit 20 * log( a / b ) und es ergeben sich logischerweise
-6,02 dB. In der Praxis rundet man das dann oft auf -6 dB.
In meinem Player habe ich auch so gerechnet, folgender code:

Code: Alles auswählen

db := trunc(20 * ln(vumeter / 256) / ln(10));
Praktisch an dB ist, dass man Quotienten bzw. Verhältnisse fortan mit Addition
und Subtraktion behandeln kann. -6 dB ist praktisch gesehen bei Schallwellen
immer die Hälfte, +6 dB das doppelte, und 0 dB der Bezugspunkt, also sozusagen 1.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 1. Apr 2017, 16:40
von wobo
Hallo Zatzen,

nur ein ganz kurzes Mini-Feedback: Ich habe gerade Deinen neuen Player (v0.04) getestet. Auf dem Test-PC (Celeron433,64MB,ESS-Audio,FreeDos 1.0) lief alles und auf Anhieb problemlos. Meine komischen BLASTER-Werte wurden auch einwandfrei erkannt.

Ich konnte wunderbar mit 11, 22 und 44kHz vermixen. Der Player gefällt mir auch noch wie vor sehr, sehr gut - sowohl was die Farbnutzung wie auch die Informationsdarstellung angeht.

Beeindruckend finde ich vor allem die Klangqualität - und das sind echt als 4-bit-Samples?
Wenn ich mit Version 0.03 vergleiche, dann finde ich nur, dass so Sachen wie Hi-Hat etwas schwächer klingen (was aber mich überhaupt nicht stört!), wenn sie alleine zu hören sind (also keinen anderen Stimmen dazu gemixt werden. Bei allen anderen Klängen merke ich überhaupt keinen Unterschied zwischen der 4-bit und der 8-bit Version. Wow - hätte ich nicht gedacht!
Das Sample-Format ist also ein ZDPCM (Zatzen Delta Pulse Code Modulation) :-)?

Die Trackerfiles sind jetzt ja auch wirklich lächerlich klein. Das ist ja bald schon AdLib-Größe :-)

Kompliment - hat mir wieder sehr gut gefallen.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 1. Apr 2017, 18:08
von zatzen
Hallo wobo!

Bei 11 kHz mixen muss man aufpassen, dass man kein Modul erwischt,
bei dem die Samples höher als 77 kHz abgespielt werden. Das würde
zu unerwarteten Programmabläufen führen. Ich muss die entsprechende
entrollte Schleife entweder verlängern oder vom Gebrauch von 11 kHz
mischen abraten oder vorher im Player die Note-Tables durchchecken
und ggf. die Frequenzen begrenzen, was kein großer Akt wäre. Es
käme natürlich dann zu falschen Tönen.

Dass Hihats solo schwächer klingen als mit Begleitung kann ich so nicht
nachvollziehen, aber diese könnten schwacher klingen weil bei 44.1 kHz
weniger Dreck reinkommt, oder aber andererseits durch das Delta-Format
bei hohen und lauten Frequenzen eine gewisse Degradierung möglich ist.
Samples können ja selbst hoch ausgesteuert sein aber dann nur leise
abgespielt werden.

Ich selbst war auch erstaunt über den 4-Bit-Delta Klang, schliesslich hat
mich das motiviert, die Sache umzusetzen, auch wenn ich dafür Performance
opfere. Nennen würde ich das Sample-Format, wenn ich denn einen Tracker
schreiben würde der sowas schreiben und lesen kann .ZSS, für "Zatzen Simple
Tracker Sample". Dass es Delta mit exponentiellen Stufen ist würde ich einfach
mal unterschlagen.

Freut mich, dass es gefällt.
Und für mich macht es mit der nun erreichten geringen Größe auch den
Sinn, den ich ursprünglich erreichen wollte.

Ich bin auch schon wieder am konvertieren, Kategorie C vom modarchive,
bislang 100 Stücke, aber die meisten sind eher nervig. Aber da kommt noch
viel.
Übrigens, Ihr setzt mich nicht unter Stress oder so, ich mache das aus ganz
eigenem Antrieb heraus - sollte ja klar sein dass es Spass macht, für das
eigene Format "Futter" zu suchen und nebenbei immer mal wieder auf
wirklich tolle Musik zu stoßen.

Die nächste Player-Version soll noch mehr Anzeige-Modi haben, irgendwie
fühle ich mich mit der derzeitigen Version noch etwas "blind".
Ein Pattern Mode soll dazukommen, bei dem man sehen kann wie die
Events von unten nach oben scrollen, und dafür muss ich einen Prefetch
einbauen. Das bedeutet eine grundsätzliche Änderung an Routinen wie
read_row, es muss alles in ein Array gespeist werden (je Zeile auch
jeweils die ganzen Daten die der Player anzeigt) und dann muss
gewählt werden, welche Position des Arrays für die aktuell zu spielende
Zeile gelten soll. Aber ich denke es wird sich lohnen und mich noch
für weitere Darstellungen inspirieren.
Aber ich merke gerade, darüber muss ich noch ein bisschen nachdenken.
Das ganze gäbe eine ziemliche Datenkopiererei, da muss ich mir noch
was einfallen lassen.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 2. Apr 2017, 14:01
von DOSferatu
Ich merke gerade, daß ich schon wieder eine Zeitlang nicht geantwortet habe. Das muß ich schnell mal nachholen.
zatzen hat geschrieben:Zunächst einmal: Ich finde ISM absolut nicht "wegschmeissenswert".
Seufz... Schön, daß Du das so siehst...
Aber - gegenüber professioneller Klangerzeugung ist ISM wohl quasi einfach Müll.
zatzen hat geschrieben:Es hat seinen eigenen Charme
Naja, so kann man's auch nennen, wenn man's freundlich umschreiben will...
zatzen hat geschrieben:und kann, wenn ich nicht irre, komplexere Klänge erzeugen als es mit ein paar Mini-Samples (ein paar dutzend Bytes als Schleife) in ZSM möglich wäre.
Naja, die alleinige *Möglichkeit*, "alles mit allem" zu kombinieren bedeutet ja nicht zwangsläufig, daß bei allem dabei auch etwas Sinnvolles/Anhörbares herauskommt.
zatzen hat geschrieben:Mein Problem ist nur das "komponieren" in prISM. Auch wenn ich in Deinem Thread geschrieben habe, die Erfahrung wäre es mir wert, muss ich doch gestehen, dass mir die intuitive Erstellung von Musik damit etwas schwer
fallen würde.
Ich brauche beim "Komponieren" diese redundanzüberladenen Patterns, zumindest hat sich das bei mir so eingeprägt, innerlich habe ich mir bei der meisten Musik eine gerasterte Zählweise angewöhnt, meistens 16tel-Einheiten. Es gibt also für mich gar nicht wirklich mehr Notenlängen, sondern vielmehr Positionen, an denen sie ihren Anfang und ihr Ende haben.
Das ganze Trackerprinzip ist ja wie die Walze einer Spieluhr...
Ich weiß - deshalb nenne ich das Ding ja auch oft "Nicht-Tracker". Die ganze Arbeitsweise von ISM würde es ziemlich umständlich machen, eine tracker-artige Ansicht einzubauen und dann noch quasi "live" zu komponieren und abzuspielen. Hier müßten ständig die "Abstände" intern in Längenparameter gewandelt werden - außerdem ist ISM auf "mehrstimmige Blöcke" (was in Trackern Patterns sind) gar nicht "vorbereitet". Desweiteren sind "Effekte" - bis auf das Portamento - in ISM quasi gar nicht umgesetzt, sondern müßten "programmiert" werden - quasi als "Unterprogramm". Ich habe auch schon hin und her überlegt - man könnte für ein "Trackerformat" quasi einen vordefinierten "Rahmen" (in ISM-Daten) bauen, der z.B. aus einer Reihe von aufeinanderfolgenden "Unterprogramm-Aufrufen" einen Sequenzer simuliert. (Mit Kombinationen von PAD und NEW oder TRK Befehlen wäre dies möglich, auch für größere Reichweiten.)
Allerdings müßte die ganze Zeit eine "Prüfung" mitlaufen, die dafür sorgt, daß die Abspiellängen der "Patterns" gleich bleiben - in ISM haben die Patterns ja keine Spuren, bzw nur immer eine Spur, die Stimmenzuordnung passiert ja außerhalb von ISM. Die Geschwindigkeiten müßten auch synchronisiert werden - denn man kann diese normalerweise jederzeit ändern.
Und außerdem müßte ich dazu mal zusätzlich einen "Instrumenten-Editor" einbauen. Da je max. 128 Samples und 128 Instrumente erlaubt sind, wäre so der Wert für das "Instrument" 8 Bit und am obersten Bit würde entschieden, ob Instrument/Sample. Aber eigentlich wollte ich den Einsatz von Samples sparsam bis gar nicht haben - was dem geübten Tracker-Musiker wohl nicht gerade sehr entgegenkommt.
Mir erschien die Aufteilung/Darstellung wie in ISM/prISM immer die plausiblere, da jeder "Musiker" im Orchester seine Stimme spielt und damit nur die eine Stimme hat - unabhängig von den anderen. Zusammen klingt es dann wie Musik...
Aber ich kann natürlich die Einwände verstehen/nachvollziehen.
MÖGLICHERWEISE lasse ich mich irgendwann mal hinreißen, eine zweite, parallel entwickelte Version (und kompatible) von prISM (mit anderem Namen) zu bauen, bei der die entsprechenden Subroutinen auskommentiert sind und durch eine Tracker-Darstellung ersetzt werden (beides gleichzeitig wird einfach nichts - das braucht zuviel Programm-Speicherplatz). Aber dazu muß ich erst einmal die Zeit finden und mir ein wirklich brauchbares Konzept dazu einfallen, das mich selbst überzeugt.
zatzen hat geschrieben:Das MOD-Format ist nun aber auch eines der ersten dieser Formate und hat wohl auch der Einfachheit halber keine Patternkomprimierung.
Nun *könnte* man die Musikdaten bei ISM auch als eine Kompression verstehen, bloß eine ziemlich intelligente, weil vom User speziell so definiert.
Naja, mir ging es hier nicht maßgeblich um Kompression. Ich sage mal so: Der "Programmklotz", der ISM-Daten abspielt, ist etwas über 16 kByte (reiner Maschinencode) groß, dazu kommen noch die Subroutinen, die für das Laden/Integrieren (in den Samplestack) zuständig sind, sowie verschiedene Tabellen. Ich schätze mal, daß ISM so insgesamt schon 32 kByte belegen könnte - da ist die Größe der ISM-Datenfiles wohl subjektiv.
Ich sage es mal so: Da ISM quasi nicht zum Bauen von "Orchestermusik" oder "Musik zum einfach anhören" gemacht ist, sondern hauptsächlich zur Verwendung in Spielen gedacht ist (und somit eher für "Hintergrundmusik") wird im Spielprogramm sowieso eine reservierte Größe für Sounddaten festgelegt werden müssen, damit, egal welche Musik geladen wird, trotzdem der Speicher noch ausreicht. Gleiches gilt für Grafikdaten (inkl. Sprites), Levels, Steuerdaten usw.
Hier könnte man zwar auch "dynamisch" vorgehen, d.h. für größere Levels oder aufwendigere Grafik dafür für das Level "sparsamere" Musik benutzen oder umgekehrt für aufwendigere Hintergrundmusik dafür an Levelgröße und Grafik sparen... aber ich wollte so etwas erst einmal vermeiden.
Somit wird wohl anfangs einmalig Speicher für die "größtmögliche Musik" reserviert werden, ebenso für die restlichen Dinge. Während der Laufzeit des Spiels soll möglichst kein "gigantisches Speichermanagement" passieren - denn das könnte die Performance oder sogar die Funktionalität des Spiels beeinträchtigen
zatzen hat geschrieben:Worauf ich hinaus will: Wenn Du mehr Musik für ISM willst, dann könnte man doch mal an einen Converter, oder vielmehr an einen Compiler denken.
Naja, daran GEDACHT habe ich schon. Bei einem Compiler würde ich ja nur bereits bestehende Musiken benutzen. Da aber bestehende Musiken quasi vollständig in MOD-Format und dessen Derivaten vorliegen, würde dabei *ausschließlich* auf Samples gesetzt werden - also wäre dies erst einmal keine Option. Und ja - ich habe sogar schon darüber nachgedacht, eine "Sample-Analyse" zu entwickeln, die Samples in ISM-Synthesizer-Daten wandelt, mit wählbarer Qualität: so daß niedigste Qualität wäre, EINE allgemeine Welle mit EINmaligen ADSR-Werten als Resultat zu haben - ein "ISM-Instrument" und die höheren Qualitäten bis zu einer Granularität von 1/128 Sekunden-Teilen so "Wechsel" zu haben, so daß ein Ton quasi von einer Subroutine mit "Daten-Wechseln" abgespielt würde. Ja, ich weiß: Das klingt verrückt...

Desweiteren will ich in Spielen definitiv NICHT bereits bestehende Musiken von woanders klauen und benutzen - sondern natürlich neue Musiken haben.
zatzen hat geschrieben:Zumindest Unterhaltungsmusik ist redundanter und strukturierter als man auf den ersten Blick denken mag. Man könnte schon Wiederholungen finden, indem man die Musikdaten halbnotenweise durchscannt, und dann vielleicht noch weiter prüft, ob diese Wiederholung sich auch auf ganze Noten ausweiten.
Das würde bei so einem Konverter sowieso gemacht werden.

Aber wie gesagt: Sowohl ein Konverter als auch ein Compiler würde voraussetzen, daß die Musik erst "woanders" entwickelt wird und "woanders" hat meines Wissens keinerlei Optionen für Software-Klangsynthese sondern immer nur für Samples. Korrigiert mich, wenn es anders ist.
Achja: Mein vor Jahren selbstgeschriebener C64-Emulator kann übrigens C64-Musik "grabben" - kein Hexenwerk: Er schreibt die Werte, die in die Register des SID geschrieben werden, zusätzlich in ein File, natürlich immer mit den Zyklen, die zwischen den Befehlen vergehen (sonst macht's ja keinen Sinn). Die meisten C64-Spiele sind getimed, oft auf den Rasterzeilen-Interrupt, damit Musik und Scrollen/Sprite-Multiplexing sich nicht in die Quere kommen. Somit könnte man die "großen Sprünge" herausfinden und die Sachen in 50Hz oder 60Hz - Schritte gliedern und daraus dann Musikdaten für ein DIng wie z.B. ISM (das sowieso eher wie ein Soundchip funktioniert) konvertieren...
zatzen hat geschrieben:Die speziellen Eigenschaften von ISM würden so trotzdem genutzt, denn ISM kann Unterprogramme und viele Dinge die z.B. ZSM nicht kann.
Naja, wenn man sowieso so ein Ding wie ein "Programm" aufzieht, sind Sprünge, "Unterprogramme" und ähnliches ja kein Hexenwerk. Das ganze Ding ist meiner Denkweise geschuldet - für mich ist alles "Befehl + Parameter", egal, was es ist.
zatzen hat geschrieben:Das würde also bedeuten, dass Deine Mühen, diese Funktionen in ISM einzubauen nicht umsonst waren, sondern sie würden genutzt, auch wenn man z.B. ein Trackerfile (mit stellvertretenden Samples) reingibt - und am Ende könnte ein ISM rauskommen das wie per Hand programmiert ist.
Naja, wie gesagt - immer diese Samples...
zatzen hat geschrieben:Wahrscheinlich gefällt Dir so eine Idee immer noch nicht.
Um das nicht falsch zu verstehen: Mir geht es nicht darum, daß ich unbedingt Leute dazu bringen will, prISM zu benutzen und es mir irgendwie um die Zeit/Mühe, prISM zu bauen leid tut, wenn es nicht benutzt würde. prISM ist nur das Frontend, um überhaupt etwas zu haben, ISM-Files zu entwickeln.

Das komplette "Datenblatt" von ISM-Befehlen/Daten und vom ISM-Fileformat ist ja quasi öffentlich - und es würde mich nicht einmal stören, wenn jemand anderes etwas besseres/besser benutzbares als prISM programmiert, um ISM-Zeug damit zu benutzen/abzuspielen. Ich bin irgendwie mehr so ein "Engine-Bastler". Oberflächen-Tools sind nicht gerade meine Stärke und ich habe einfach versucht, ein einigermaßen sinnvolles Bedienkonzept bei prISM einzuhalten. Aber ich bin mir bewußt, daß es, gerade was das Entwickeln von Oberflächen angeht, viel talentiertere Leute gibt, die viel intuitiver benutzbare Systeme auf die Beine stellen können.
zatzen hat geschrieben:Bloß würde ich persönlich eher Zeit in so einen Compiler investieren, anstatt ein Stück erst im Tracker zu programmieren und dann "mit Papier und Bleistift" in prISM umzusetzen, letztlich würde ich, abgesehen von Effekten, nicht viel anders machen als der Compiler.
Naja, ich habe auch damals, bei meinem alten "MUSIX" Programm die Musiken immer gleich dort eingegeben - ich mußte da nie vorher "mit Papier und Bleistift" die Musik konzipieren. Mir hat es immer gefallen, Tonsequenzen einfach wiederverwenden zu können, transponiert/schneller/langsamer usw. ohne die gleiche Sequenz immer und immer wieder eingeben zu müssen - auch für so Begleitstimmen, wo sich so Sequenzen immer und immer wieder wiederholen, das würde mich ohne Ende nerven, das alles immer neu tippen zu müssen - wenn die gleiche "Percussion-Sequenz" für ein anderes Melodiestück wiederverwendet wird, müßte ich ja bei so Patterns das dann nochmals eingeben, da bei Patterns alle Stimmen "zusammenhängen" - da könnte ich nie mal Begleitungen, Melodien, Instrumente usw. austauschen, ohne alles etliche Male immer wieder neu einzugeben... Das hätte mich damals schon genervt und heute würde es mich noch mehr nerven.

zatzen hat geschrieben:Nochmals, es geht mir nicht darum, ISM obsolet zu machen,
Hatte ich auch nicht angenommen.
zatzen hat geschrieben:sondern lediglich darum, Musik intelligent und die ISM-Features nutzend zu konvertieren.
Naja, schon allein die ganzen "Interface"-Features, die ja gerade bei Spielen so brauchbar wären, würden schonmal wegfallen. Und der Software-Synthesizer, der quasi ca. 70% des Codes von ISM ausmacht, würde komplett ungenutzt bleiben, dafür stattdessen die nur "der Vollständigkeit halber angeflanschte" Sample-Option überbeansprucht werden - inklusive des enormen Speicherverbrauchs, den Samples nunmal mit sich bringen.
Für Spiele nutze ich ja nur den Heap (also 600 kByte +X) : Und nein - 200 kByte Speicher (oder sogar mehr) alleine für Samples sind da für mich keineswegs akzeptabel - und darauf läuft es bei vielen MODs ja leider oft hinaus...
zatzen hat geschrieben:Mit ein bisschen Brute Force müsste da schon was zu machen sein, und vielleicht würde so ein Compiler sogar Dinge "sehen", die man als Mensch beim direkten Programmieren in prISM übersieht.
Das ist natürlich richtig - aber wie es in ISM klingt, würde man immer erst jeweils nachher hören.
zatzen hat geschrieben:Ob der Editor prISM dadurch an Bedeutung verlieren würde weiss ich nicht.
Wie bereits oben erwähnt: Mir geht es ja gar nicht um prISM. Aber wenn ich ein Format entwickle, das zu nichts kompatibel ist, muß ich ja auch ein Entwicklungstool bauen, um es zu editieren. Und ja: Ich bin mir sicher, daß die Bedeutung von prISM dann genau Null wäre - weil es ja einfacher ist, MODs zu konvertieren, als sich auf dieses neue Formatkonzept einzulassen. Wie in einem anderen Beitrag erwähnt, bin ich mir durchaus bewußt, daß die meisten Leute sowieso schon wenig Zeit haben und froh sind, in ihren bekannten Tools überhaupt heutzutage noch etwas zu Wege zu bringen - sich auf ein komplett anderes Konzept umzustellen würde quasi ein "fast bei Null anfangen" erfordern - das ist mir schon klar.
zatzen hat geschrieben:Es wäre vielmehr so, dass Du einfach zusätzlich mehr Musik für Dein Format hättest.
Ach naja, darum geht's mir nicht. Wie bereits erwähnt, brauche ich ja nicht "bereits vorhandene Musik", nur um zu hören, wie sie in der extrem reduzierten Qualität von ISM klingt - weil ich "bereits vorhandene Musik" (also seit 20-30 Jahren allseits bekannte MODs u.ä.) sowieso nicht plane, in meinen Spielen zu verwenden. Wie bereits oben angesprochen: ISM existiert nicht "um seiner selbst willen", es war nie als ein "Standalone-Musik-System" gedacht, sondern von vornherein als eine Möglichkeit, in meine Spiele endlich die bisher immer noch fehlende Komponente - Hintergrundmusik und Soundeffekte - einzubauen.
zatzen hat geschrieben:Wir könnten da gerne zusammenarbeiten, wenn Du Dich dazu durchringen kannst, und das ganze Dir nicht zu sehr gegen den Strich geht.
Gegen Zusammenarbeit habe ich prinzipiell nichts einzuwenden, auch wenn ich es im Computerbereich noch nie gemacht habe. Ich habe aber keine Ahnung, wie so etwas vonstatten gehen würde, da wie gesagt, bisher immer nur Einzelkämpfer gewesen. Wie man vielleicht schon bemerkt hat, tue ich mich äußerst schwer mit Kompromissen - bzw damit, meine Kompromisse durch andere Kompromisse zu ersetzen...
zatzen hat geschrieben:Ich fände es schade, wenn ISM nicht weiter wächst.
Naja - ISM ist kein Kunstwerk, sondern nur "Mittel zum Zweck". Mir ist einfach nichts besseres eingefallen.
zatzen hat geschrieben:Man kann es so sehen:
ZSM reduziert die Patterngrößen indem die Events (z.B. Sample abspielen) mit so wenigen Bits wie möglich beschrieben werden. Das geht soweit, dass zwei gleiche aufeinanderfolgende Noten nur ein Bit benötigen. Es ist also eine effektive Schrumpfung der redundanten Daten. Eine gewissermaßen idiotensichere Methode, man gibt rein was man will und es kommt das kleinstmöglichste raus.
Naja, ZSM ist ja quasi kein neues Konzept der Klangdatenerzeugung, sondern nutzt die gleiche Klangdatenform (track-/patternbasiert) wie MOD und seine Derivate - es reduziert lediglich die Größe der Daten und reduziert etwas an der Qualität, um weiteres Packen zu ermöglichen.
zatzen hat geschrieben:ISM kann durch seine Programmiersprachen-ähnliche Auslegung auch sehr speichersparend sein, verlangt aber vom User eine entsprechende Vorgehensweise. Bzw. lässt sich diese gar nicht umgehen, da nach Notenlängen und nicht nach Positionen im Pattern vorgegangen wird.
ISM packt quasi gar keine Daten, sondern ordnet sie von Anfang an komplett anders an als es in MODs getan wird, funktioniert also nicht track-/patternbasiert. Datenreduktion war hier nicht der Hauptgrund.
Das bißchen Packen beim Speichern der Musikdaten (im File) geht über stumpfes Lauflängen-Packen nicht hinaus und dient eigentlich nur dazu, lange NOP- oder QQQ-Sequenzen einzudampfen - bei anderen Befehlen ist es eher selten, daß so viele identische aufeinander folgen, daß sich Packen hier lohnt. Ein anderer Unterschied ist die Softwaresynthese, die bei MOD-artigen Formaten (bis auf wenige Ausnahmen) quasi nicht genutzt wird.
zatzen hat geschrieben:ISM bietet aber im Gegensatz zu ZSM nicht diese idiotensichere Automatisierung an.
So ist es.
zatzen hat geschrieben:Was bei ISM denkbar wäre, wie oben schon gesagt, wäre ein Scannen eines redundant notierten Musikstücks nach Wiederholungen usw.
Naja - eigentlich wird umgekehrt ein Schuh draus:
Ich fand es einfach blöd, Daten zwanzig mal einzugeben, nur damit es nachher ein Parser/Packer erkennt und auf ein mal reduziert - da gebe ich die doch lieber selber bloß ein mal ein... Das war schon bei MUSIX so und bei prISM habe ich das so weitergemacht. Da ist meine Denkweise wohl zu unterschiedlich zu der von so Tracker-Musikern, keine Ahnung...
zatzen hat geschrieben:Ich hatte an soetwas auch bei ZSM gedacht, habe es aber bislang nicht umgesetzt, weil ich mit der bisherigen Kompressionsrate der Patterns zufrieden war und diese sich auch für Stücke ergibt, die sehr wenig Redundanz haben. Diese gibt es aber kaum und deswegen könnte man die Unterprogramme bei ISM für Redundanzen nutzen.
Naja, wie oben erwähnt: Erst Redundanzen schaffen und sie dann zu komprimieren war mir zu aufwendig, da habe ich lieber gleich kaum redundant eingegeben.
zatzen hat geschrieben:Wie gesagt, als zusätzliches Tool, einem Compiler von entsprechend vorbereiteten Tracker Dateien, oder vielleicht auch MIDIs.
Wenn Du möchtest.
Wie schon erwähnt: Ich habe kein Problem damit, wenn jemand etwas zusätzliches brauchbares baut - die Beschreibungen der Befehle und des Fileformats sind offen.
zatzen hat geschrieben: zu den 4-Bit-Samples:
Die liegen als 4 Bit im Speicher, als 8 Bit würde es ja keinen Sinn machen,
da hätte ich nur Platz auf dem Datenträger gespart und mir dafür die
Klangqualität eingeschränkt.
Macht Sinn.
zatzen hat geschrieben: Ich halte in einem 8-Bit-Register immer die Phase (den aktuellen entpackten
Sample-Wert), und diese ändere ich durch Addition der aus der Tabelle
gelesenen Delta-Werte. Die Tabelle ist:

Code: Alles auswählen

(0, 1, 2, 4, 8, 16, 32, 64, 128, 192, 224, 240, 248, 252, 254, 255)
Dank des Überlaufs brauche ich nur positive Werte, und kann z.B. mit 255
von 0 auf 255 springen oder auch von 1 auf 0. Oder, vielleicht besseres
Beispiel, ich komme mit einer 16 z.B. von 120 auf 136, oder aber auch
von 250 auf 10, wofür man eigentlich eine -240 bräuchte, die es als
signed byte nicht gibt.
Ja, das hattest Du schon erwähnt. Hätte ich genauso gemacht. Angst vor Überläufen ist was für "Hochsprachen-Trottel mit angeschalteter Überlauf-Prüfung"... Für mich ist 255 immer gleichzeitig -1, je nachdem, wo ich es gerade benutze. Vorzeichen sind nur eine Frage der Einstellung...
[...]
zatzen hat geschrieben:Beim Konvertieren der Samples nach 4 Bit probiert der Konverter alle Tabellen-werte durch und nimmt dann denjenigen der den geringsten Fehler ergibt. Von diesem evtl. fehlerbehafteten Wert ausgehend wird das nächste Delta
gesucht usw.
Ja, auch das hätte ich genauso gemacht.
zatzen hat geschrieben: Aber zum Durchlauf:
Praktischerweise unterstützt ZSM weder rückwärts Abspielen noch Sample Offsets.
Und für Schleifen habe ich ein Stütz-Byte für die Phase am Schleifenanfang.
Das mit den "Zwischenframes" war etwas schwierig, ich bin aber doch relativ
schnell zu einer Lösung gekommen:
Ich habe ja zu jeder Zeit die aktuelle Position im Sample. Also bilde ich jeweils
die Differenz zur Position davor. Im Grunde ist das sogar alles was ich wissen
muss, die Differenz, nicht einmal die Position - die Position im 4-Bit Stream
wird anderswo gemerkt.
Anhand der Differenz, nur Vorkomma, weiss ich nun, wie oft ich die Phase in diesem
Schritt aktualisieren, also den nächsten Wert aus den 4-Bit-Daten lesen muss und
aus der Tabelle. Bei einer Differenz von 0 muss ich selbstverständlich nichts
tun und jegliche Aktivität in der Schleife wird übersprungen.
Bei allen anderen Werten geht der Weg weiter in eine entrollte Schleife, diese
habe ich bis zu 7 Durchläufen realisiert, und es wird per Sprungtabelle jeweils
in den Teil der Schleife gesprungen, auf den noch so viele Durchläufe folgen
wie gebraucht werden.
Genau das wollte ich wissen. Anders könnte ich es mir bei dieser Form des Delta-Packens auch gar nicht erklären, wie es sonst funktionieren soll.
zatzen hat geschrieben:Trotzdem ist der Player mit 11 kHz deutlich schneller als mit 44, und das sagt mir dass man evtl. noch etwas an den Mischroutinen außerhalb der entrollten Schleifen drehen kann.
Naja, das ist ja normal. Würde 11 kHz 4x so schnell wie 44 kHz berechnet werden, bestünde das Ganze ja ausschließlich aus der "inneren Schleife". Damit innere Schleifen aber effizient arbeiten können, müssen außerhalb natürlich gewisse Vorbereitungen getroffen werden - und das macht die zusätzliche "fixe Zeit" aus, die immer da ist, egal mit welcher Samplerate man arbeitet. Das ist ja normal.
zatzen hat geschrieben:Vielleicht liegt es sogar am Clippen und Shiften des 16 Bit Puffers,
und das folgende Überführen in den 8 Bit Puffer, obwohl ich das bisher als das
kleinste Übel angesehen habe.
Naja, aber das passiert ja auch bei allen Sampleraten und bei 11 kHz hast Du ja auch nur 1/4 soviele Zieldaten wie bei 44 kHz.
zatzen hat geschrieben:Mir fällt gerade auf, dass es bei 11 kHz passieren könnte, wenn Samples sehr hoch (> 77 kHz) gespielt werden (was durchaus vorkommt), dass der Player dann abstürzen müsste... Evtl. erweitern...
Naja, einfach die Schleife weiter ausrollen, das sollte an der Geschwindigkeit ja nichts ändern.
zatzen hat geschrieben:Bisher hatte ich 8 Lautstärke-Stufen und habe diese durch einfaches Shiften umgesetzt. Damit lassen sich aber nur Lautstärkestufen von 6 dB
realisieren, und das ist doch etwas zu grob.
Für die doppelte Auflösung musste ich jetzt Zwischenstufen einfädeln,
und das habe ich vorerst so gemacht:

Code: Alles auswählen

  mov ah, dl
  mov cl, 0; @voldata_full:
  test cl, 1
  jnz @vol_odd
  mov cx, ax
  sar cx, 2
  sub ax, cx { AX * 0,75 }
  @vol_odd: { 15, 13, 11, ... }
  sar ax, 0; @voldata:
DL ist die Phasenlage, d.h. der entpackte Wert aus den 4-Bit.
Der Geschwindigkeit halber lösche ich AL nicht, man wird es praktisch nicht hören.
@voldata_full: hier wird selbstmodifizierend die Lautstärke 0-15 reingeschrieben
@voldata: selbstmodifizierend der Shift-Wert, wird oben außerhalb der Schleifen
aus der 0-15 Lautstärke berechnet.
Bei geraden Lautstärken (14, 12, 10, ...) muss ein Viertel abgezogen werden.
Ziemlich viel Code für so eine simple Sache... Vorher sah das so aus:

Code: Alles auswählen

  mov ah, dl
  sar ax, 0; @voldata:
Ja, das neue sieht irgendwie etwas umständlich aus, da kann man sicher noch was dran drehen. Außerdem vermeide ich Sprünge wo ich nur kann - hatte ja mal gesagt, wieso.
zatzen hat geschrieben:Und etwas später natürlich in den 16 Bit Puffer schreiben und die Position weiterzählen:

Code: Alles auswählen

  add es:[di], ax
  db 66h; db 081h, 0c7h, 002h, 000h, 0ffh, 0ffh { add edi, 0ffff0002h }
Ich habe es irgendwie nicht hinbekommen, "db 66h; add di, sonstwas und dw 0002h etc."
zu definieren, oder irgendwie mit word ptr, daher habe ich das als einzigen Byte Code hingeschrieben, den ich mir auf der Seite https://defuse.ca/online-x86-assembler.htm erstellt habe.
Dafür gibt's eine einfache Erklärung: Die x86-CPUs supporten für viele Dinge (und eben auch für Additionen/Subtraktionen) mit direkten Werten sowohl Byte- als auch Word-Werte (um Programmspeicher zu sparen). D.h. man kann zu einem Word-Register oder einer Word-Speicherstelle auch einen Byte-Wert addieren, der auch bloß als Byte-Wert dargestellt wird - das wird am Opcode erkannt - es gibt also sozusagen 2 Additions-Opcodes, einmal für Byte, einmal für Word. Der Pascal-Compiler nimmt natürlich immer den Byte-Opcode, wenn ein Wert <256 addiert werden soll, egal ob man ihn z.B. $0002 oder einfach 2 schreibt. Die Schreibweise

Code: Alles auswählen

db $66;ADD AX,$0002; dw $FFFF
oder so sieht natürlich erst einmal plausibel aus - hier soll z.B. $FFFF0002 zu EAX addiert werden - ABER: Für den Pascal-Assembler, der ja nicht weiß, daß diese db und dw-Sachen einfach den Befehl erweitern sollen, ist das nur ein ADD AX,2 Befehl, um den herum noch einige Bytes gestreut wurden.
Um einen Befehl auf 32-Bit zu erweitern, MUß aber unbedingt der 16-Bit (nicht der 8-Bit!) Befehl benutzt werden, Befehle mit 8-Bit-Parametern stören sich gar nicht am vorgestellten db $66 (und das nachfolgende $FFFF wird natürlich als neuer Befehl gelesen, ich glaube das würde als ein TEST BH,BH gelesen, müßt ich nochmal nachgucken, ist ja auch egal...)
Anders ausgedrückt:

Code: Alles auswählen

db $66;ADD AX,$0102; dw $FFFF
würde z.B. funktionieren, weil $0102 ja >=256 ist und somit die 16-Bit-Addition benutzt werden würde, die dann auch durch db $66 auf die 32-Bit-Variante erweitert werden würde. Wenn das untere Word also <256 ist, bleibt einem im Pascal-Assembler nichts weiter übrig, als den Befehl, so wie Du es gemacht hast, komplett als Bytes (oder auch z.B. db $66,$81,$C7; dd $FFFF0002 für ADD EDI,$FFFF0002) zu schreiben.
zatzen hat geschrieben:BLASTER: ZSMPLAY liest die Umgebungsvariable aus, aber nachdem das bei Wobo nicht funktionierte habe ich noch eine Option zur manuellen Konfiguration eingebaut.
Naja, einfach auf den Buchstaben parsen, nicht einfach von der Reihenfolge A I D ausgehen. In meiner Blaster-Unit habe ich so etwas gleich eingebaut, in Assembler.
zatzen hat geschrieben:Ich hätte jetzt nicht damit gerechnet, dass Du sagst, dass sich ZSM evtl. für Spiele eignen würde, zumindest nicht, nachdem diese Version nun langsamer ist.
Naja, so wie ich programmiere - immer Vollbildscrollen und so - wäre ein 386er mit meinem Kram wohl auch etwas überfordert und ein 486er schon eher angemessen. Ich habe mir schon sagen lassen, daß Xpyderz auf einem 386er nur sehr leidlich performt, selbst mit Low-Res Einstellung.
zatzen hat geschrieben:Ich hatte/habe selber Zweifel, am liebsten wäre mir etwas, das sogar auf einem 286er in einem Spiel funktioniert. Aber ich glaube soetwas hat es
nie gegeben, also MOD+Spiel auf einem 286er, ich kann mich nur an VGA-Copy erinnern, wo im Intro ein MOD über den PC Speaker gespielt wurde.
Naja, 286er fällt ja sowohl für ZSM als auch für ISM aus - sobald ein einziger 32-bit-Befehl (oder Nutzung von FS/GS) drin ist, ist bei allem unter 386er der Absturz im wahrsten Sinne des Wortes vorprogrammiert.
zatzen hat geschrieben:Ich selber kenne Dezibel vor allem aus der Tonwelt, und da merkt man sich über die Zeit so ein paar Dinge, wie dass 6 dB einer Verdopplung der Amplitude entsprechen, in der Verstärkertechnik aber 3 dB mehr schon eine Verdopplung der Leistung sind.
Ja, mir ist das schon klar. Aber für mich gibt's eben Null für "aus" und Maximal-möglicher-Wert für "laut" und "Mehr-als-maximal-möglicher-Wert" für "häßliches kratzendes Übersteuern". Weiter reicht mein Verständnis da nicht. Und ich weiß, daß sowohl bei Licht als auch bei Klang die menschliche Wahrnehmung da logarithmisch (exponentiell) statt linear ist.

Anmerkung: Ich verstehe irgendwie nicht, wie das mit dem Shiften funktionieren kann - nicht, weil ich nicht ebenso auch geometrische Reihen nutzen könnte, sondern, wie das Aufaddieren dann bei mehreren Stimmen funktioniert.
Zu Anfang hatte ich das so, daß ich den Wert der Welle mit der Lautstärke multipliziert (natürlich über eine Tabelle) habe und dann addiert habe. Das habe ich für jede Stimme gemacht. Aber selbst wenn man dann nachträglich noch skaliert (so daß das Maximum aller Stimmen * Maximale Lautstärke zusammen auf maximal 255 hochskaliert wird), ist der Kram nicht "mittelzentriert", d.h. leise Töne gehen immer in Richtung 0, nicht in Richtung 128. Wenn ich daraus ein WAV gemacht habe, klang das in vielen Musikabspielprogrammen total bescheiden, weil es so "auszentriert" war. Deshalb mußte ich das alles umbauen. Die Tabelle ist nun quasi "signed", die Lautstärke wird nun zu -8 bis +7 und da addiert (also 248 bis 7). Und das Skalieren am Ende inkl. Mittelzentrieren wird ebenfalls über eine Tabelle gelöst. Bevor ich den Sound mittelzentriert hatte, klangen leisere Parts oder leisere Stimmen immer irgendwie schräg. Da beim Shiften ja nun keine solche Zentrierung passiert, frage ich mich nun, wie Du das Problem gelöst hast.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: So 2. Apr 2017, 22:00
von zatzen
gegenüber professioneller Klangerzeugung ist ISM wohl quasi einfach Müll.
ZSM dann aber auch. 4-Bit Samples haben nicht mehr viel mit Profiklang zu tun.
Dass die Klangfülle trotzdem relativ groß ist liegt einfach an der Natur von Samples.
Das war ja auch der Grund warum mich Tracker so faszinierten. Einmal, um auch
aus jedem "Furz" ein Liedchen zu stricken, aber auch weil durch dieses Format zum
ersten mal ziemlich realistische und abwechslungsreiche Klänge auf dem PC einzogen,
wenn man es mal mit AdLib vergleicht.

Aber als Charme bei ISM meine ich tatsächlich, dass es etwas vom SID Klang hat.

Bereits vorhandende Musik:
Es geht mir ja auch weniger um die Möglichkeit, x-beliebige MOD-Musik in Dein
Format zu konvertieren, sondern vielmehr darum, dass ich eben z.B. in meinem
gewohnten Tracker mit stellvertretenden Samples etwas neues für Dich machen kann.
Mir fehlt tatsächlich heute ein wenig die Zeit und Motivation, mich auf ein neues
Format inkl. dessen Editor einzulassen. Deshalb verwende ich immer noch meinen
Tracker von 1994 um Musik zu machen, obwohl es heute ganz tolle Tracker mit
allem Schnickschnack gibt - aber in der Zeit mich da einzuarbeiten dass ich so
schnell und intuitiv arbeiten kann wie mit dem DOS Tracker hätte ich schon
wieder eine ganze CD fertig...
Aber ich habe so bei mir gedacht als ich prISM gesehen habe, wenn ich das so
um 1992 gesehen hätte als ich nur einstimmiges PC-gepiepse machen konnte,
dann wäre das sehr spannend gewesen.
Bloß wenn ich heutzutage einen Tracker habe mit dem das eben alles so fluppt,
und den ich seit über 20 Jahren wie im Schlaf beherrsche, dann ist dieser Editor
und sein Format für mich eine stabile Grundlage, und ich konvertiere lieber
von diesem Format ausgehend als ein anderes Programm zu erlernen.
ZSM Dateien werden auch bislang ausschliesslich ausgehend von diesem Format
konvertiert. Der Tracker kann MOD und S3M importieren.

Verrückt finde ich das nicht unbedingt mit der Sample-Analyse, aber ich würde
ja umgekehrt vorgehen, dass ich im Tracker Samples verwende, die
1. auf jeden Fall die Tonhöhe haben wie hinterher in ISM
und
2. einen ähnlichen bis gleichen Klang haben.
Aber wie gesagt: Sowohl ein Konverter als auch ein Compiler würde voraussetzen, daß die Musik erst "woanders" entwickelt wird und "woanders" hat meines Wissens keinerlei Optionen für Software-Klangsynthese sondern immer nur für Samples. Korrigiert mich, wenn es anders ist.
Ja, klassische Tracker können nur Samples, aber wie gesagt kann man ja entsprechend klingende Samples
nehmen und somit eine gute Vorschau haben, wie es letztlich als ISM klingt.
Natürlich ist das alles irgendwie nur eine Krücke.
Ansonsten könnte ich Dir höchstens anbieten, falls Du Musik von mir gemacht haben wolltest,
dass ich Dir das irgendwie in Notenform zukommen lasse, und Du es in prISM programmierst.
Aber man weiss es nicht. Ich will jetzt auch nicht sagen dass ich prISM nie wieder anrühren
werde. Alles eine Frage von Lust und Laune.

Die klassischen Amiga MODs funktionieren auch über eine Rasterung in 50 Hz, somit hat man bei den
älteren nur Tempi wie 94, 107, 125, 150 BPM. Arpeggio und alle anderen Effekte sind auch in 50 Hz
gestuft. Ich hätte bei ZSM auch einfach alles in 50 Hz also 20 ms stufen können, aber das war mir
einerseits zu aufwändig zu programmieren mit den ganzen Effekten, und andererseits zu
eingeschränkt was das Tempo angeht. Zudem wollte ich beliebige Sample-Grundfrequenzen,
und das kann das MOD Format nicht, und ich hätte dafür eine riesige Tabelle gebraucht -
so wie ich es habe sind die Pitch-Tables selten mal größer als 200 Byte.

Die Redundanz in Trackerfiles kommt wie gesagt auch daher, dass Tracker-Editoren
umfangreiche Kopierfunktionen beinhalten. Hat man also einmal z.B. die Schlagzeugspur
fertig, kann man sie beliebig oft kopieren, oder man kopiert einfach das ganze Pattern
zum nächsten, um nur kleine Änderungen zu machen. Beispielsweise die komplette
Begleitung so lassen und nur die Melodiestimme ändern.

Ich würde darauf abzielen, ISM eher ohne Samples zu verwenden, oder wirklich nur
bestimmte Klänge wie z.B. eine Snare als Sample.
Ach naja, darum geht's mir nicht. Wie bereits erwähnt, brauche ich ja nicht "bereits vorhandene Musik", nur um zu hören, wie sie in der extrem reduzierten Qualität von ISM klingt
Das war nur meine Sorge. Ich stelle es mir eher frustrierend vor wenn man monatelang
an einem Musiksystem inkl. Editor programmiert hat, aber es dafür kaum "Software" gibt.
Daher mein Angebot zu dem Compiler, um einfach etwas mehr Musik über ISM
zu hören. Auch wenn die Qualität extrem reduziert wäre, könnte man sich so
doch einen guten Eindruck von der Leistungsfähigkeit von ISM machen.
Ich bin ja selber irgendwie auch neugierig drauf, aber ich brauche eben die
Tracker-Oberfläche. Wenn ich die hätte, hätte ich Dir schon mehrere Songs
getrackert.
Ein Synthesizer hat gegenüber Samples nämlich auch Vorteile: Man hat
alle Klänge immer parat. Bei Samples ist man darauf angewiesen dass
man entsprechende Samples besitzt... Und die Musikstücke klingen
dann schnell irgendwie eintönig wenn man immer nur Samples aus
einer Sammlung von ein paar dutzend benutzt.
Naja, ZSM ist ja quasi kein neues Konzept der Klangdatenerzeugung, sondern nutzt die gleiche Klangdatenform (track-/patternbasiert) wie MOD und seine Derivate - es reduziert lediglich die Größe der Daten und reduziert etwas an der Qualität, um weiteres Packen zu ermöglichen.
Das ist richtig, ZSM ist eigentlich "lame", weil es außer Lautstärke keine Effekte
unterstützt, und das alles damit die Abspielroutinen einfacher zu programmieren
waren - sonst hätte ich das wohl nicht durchgezogen.
Die einzige Daseinsberechtigung sehe ich nun in der Kompaktheit der Daten, ein
ZSM ist immer mindestens weniger als halb so groß wie das entsprechende MOD
von dem konvertiert wurde. Und man geht sicher, dass auch nur so viel von den
Samples gespeichert wird, wie auch abgespielt wird.
Jetzt müsste ich nur nochmal sehen, ob ich den Player noch etwas schneller
bekomme. Viel Luft ist da aber nicht mehr.

dB:
Wirklich kratzendes digitales Übersteuern passiert nur, wenn Überläufe passieren.
Relativ sauberes Clipping erreicht man, indem man diese abfängt.
Mit einem einfachen 8 Bit Puffer ist das aber schlecht möglich.
Für die dB Anzeige, die auch bis ins Positive geht, habe ich den 16 Bit Puffer
ausgelesen, in dem die Sounddaten noch relativ leise vorliegen.
Erst danach wird geshiftet und geclippt, um auf einen guten
Kompromiss für den 8 Bit Puffer zwischen "manchmal zu laut" und
"zu viel Rauschen" zu kommen.

Für zentrisches zusammenmischen ist wohl wichtig, dass der Puffer
vorzeichenbehaftet ist. Das ist ja bei 16 Bit Integern meistens so,
bzw. Ist das WAV Format bei 16 Bit vorzeichenbehaftet, bei 8 Bit
aber nicht.

Bei ZSM habe ich das nun so gemacht:
Die Samples (bzw. die von 4-Bit entpackten) liegen bei ZSM als 8 Bit mit Vorzeichen
vor. Bevor diese in den 16 Bit Puffer geschrieben werden, wird erstmal AH mit dem
jeweiligen Wert beladen, damit in AX nun ein 16 Bit Wert mit Vorzeichen steht.
Danach shifte ich AX mittels SAR (Shiften unter Beibehaltung des Vorzeichens) nach
rechts auf die richtige Lautstärke. Dann wird das in den 16 Bit Puffer (der ist signed)
aufaddiert. Erst am Schluss wird der 16 Bit Puffer nochmals in der Lautstärke angepasst
(geshiftet), geclippt und in den 8 Bit Puffer für die Soundausgabe überführt, wobei 128
addiert wird (natürlich mit Überlauf) um vorzeichenlose Werte zu erhalten, wie es der
Soundblaster braucht.
Der Befehl SAL hingegen ist ja genau der gleiche wie SHL, und beim Linksshiften von
vorzeichenbehafteten Werten muss man nur aufpassen dass man sie nicht zu weit
shiftet, weil sonst das Vorzeichen verloren geht und man sozusagen Datenmüll hat.
Bei SAR bemerke ich gerade eine Sache:
Das höchstwertige Bit wird immer übernommen bzw. dupliziert.
Wenn ich nun eine -1 habe also $FF, dann ergibt ein Shiften mit SAR wieder eine -1.
Richtigerweise, könnte man meinen, müsste aber doch eine 0 rauskommen.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Di 4. Apr 2017, 19:26
von DOSferatu
zatzen hat geschrieben:
gegenüber professioneller Klangerzeugung ist ISM wohl quasi einfach Müll.
ZSM dann aber auch. 4-Bit Samples haben nicht mehr viel mit Profiklang zu tun.
Naja, immerhin sind es skalierte 4-Bit Samples, nicht wie bei ISM wirkliche plain 4-Bit.
zatzen hat geschrieben:Dass die Klangfülle trotzdem relativ groß ist liegt einfach an der Natur von Samples.
Das war ja auch der Grund warum mich Tracker so faszinierten. Einmal, um auch
aus jedem "Furz" ein Liedchen zu stricken, aber auch weil durch dieses Format zum
ersten mal ziemlich realistische und abwechslungsreiche Klänge auf dem PC einzogen,
wenn man es mal mit AdLib vergleicht.
Wobei ich es aber auch als noch größere Kunst ansehe, mit kleinen "unscheinbaren" Samples
oder ganz ohne Samples trotzdem noch etwas auf die Beine zu stellen.
Ich bin, bei Grafik, Sound und auch anderen Dingen, immer so ein "Minimalistiker" gewesen -
wahrscheinlich nicht die schlechteste Voraussetzung, um für/auf DOS-Maschinen zu programmieren.
zatzen hat geschrieben:Aber als Charme bei ISM meine ich tatsächlich, dass es etwas vom SID Klang hat.
Wobei der SID deutlich besser klingt.
zatzen hat geschrieben:Bereits vorhandende Musik:
Es geht mir ja auch weniger um die Möglichkeit, x-beliebige MOD-Musik in Dein Format zu konvertieren, sondern vielmehr darum, dass ich eben z.B. in meinem gewohnten Tracker mit stellvertretenden Samples etwas neues für Dich machen kann.
Mir fehlt tatsächlich heute ein wenig die Zeit und Motivation, mich auf ein neues Format inkl. dessen Editor einzulassen.
Ja, ist mir schon klar. Mir geht es ja ähnlich in vielen Dingen. Schon alleine, wenn ich daran denke, mit welcher Technik ich arbeite und mit Borlands Turbo -Pascal, das seit 1993 nicht mehr weiterentwickelt wurde - 386er-Code baue ich aus Bytecode zusammen... all sowas. Mir ist natürlich bewußt, daß es heutzutage ganz andere Möglichkeiten gibt - aber ich habe weder Interesse noch Antrieb, mich darauf einzulassen.
zatzen hat geschrieben: Deshalb verwende ich immer noch meinen Tracker von 1994 um Musik zu machen, obwohl es heute ganz tolle Tracker mit allem Schnickschnack gibt - aber in der Zeit mich da einzuarbeiten dass ich so schnell und intuitiv arbeiten kann wie mit dem DOS Tracker hätte ich schon wieder eine ganze CD fertig...
So ähnlich geht's mir mit meinem Zeug. Von einigen Kleinigkeiten abgesehen sind die meisten Tools, mit denen ich arbeite, von mir selbst programmiert. Und dank der inzwischen an die hundert Units, auf die ich inzwischen zurückgreifen kann, ist ein kleines Programm schnell mal hingezaubert. Mit allen neuen Sachen müßte ich dagegen wieder bei Null anfangen. Dazu bin ich einfach zu alt...

Viele Programme erschlagen einen auch einfach mit Funktionen - man kann die nützlichen von den überflüssigen kaum noch trennen - und außerdem will man ja nicht nur EIN EINZIGES Programm zu seinem ganzen Lebensinhalt machen (weil sonst gar kein Platz mehr im Gehirn frei bleibt, wenn man so ein komplexes Tool erstmal einigermaßen verstanden hat).
Gerade heute, wo "Klickibunti" alles ist, strotzt es geradezu vor großen langsamen speicherfressenden und völlig funktionsüberladenen Tools - selbst ein Mailprogramm ist heute schon "ne Wissenschaft für sich". (Auf Arbeit benutzen wir dieses Lotus Notes 9...)
zatzen hat geschrieben:Aber ich habe so bei mir gedacht als ich prISM gesehen habe, wenn ich das so um 1992 gesehen hätte als ich nur einstimmiges PC-gepiepse machen konnte, dann wäre das sehr spannend gewesen.
So 1992 habe ich noch gar nicht auf PC programmiert - und abgesehen davon würde prISM/ISM wohl auf keinem Durchschnitts-Rechner von 1992 sonderlich performen...
zatzen hat geschrieben:Bloß wenn ich heutzutage einen Tracker habe mit dem das eben alles so fluppt, und den ich seit über 20 Jahren wie im Schlaf beherrsche, dann ist dieser Editor und sein Format für mich eine stabile Grundlage, und ich konvertiere lieber von diesem Format ausgehend als ein anderes Programm zu erlernen.
Das entspricht ja genau dem, was ich schon angemerkt habe. Wie bereits erwähnt habe ich dafür vollstes Verständnis - mir selbst ginge es kaum anders.
zatzen hat geschrieben:Verrückt finde ich das nicht unbedingt mit der Sample-Analyse, aber ich würde ja umgekehrt vorgehen, dass ich im Tracker Samples verwende, die
1. auf jeden Fall die Tonhöhe haben wie hinterher in ISM
und
2. einen ähnlichen bis gleichen Klang haben.
Ja, ich verstehe schon Deinen Ansatz/Deine Idee dahinter.
zatzen hat geschrieben:Ja, klassische Tracker können nur Samples, aber wie gesagt kann man ja entsprechend klingende Samples nehmen und somit eine gute Vorschau haben, wie es letztlich als ISM klingt.
Natürlich ist das alles irgendwie nur eine Krücke.
Ja klar. Und wenn man einen "samplebasierten" Tracker benutzt, wird man auch kaum jemals Hüllkurven selbst definieren oder ähnliches.

Ja, mit ISM wollte ich nur diese "Lücke schließen", die mir bei meinen Spielen noch fehlte - immer alles ohne Sound oder maximal mit ("analog") Speakersound Marke Xenon 2 daherzukommen, irgendwann fand selbst ich das nicht mehr "zeitgemäß". Meine musikalischen Fähigkeiten allerdings beschränken sich wirklich eher auf recht bescheidene Werke, da ist kaum je etwas mit Ohrwurmcharakter dabei.
Vielleicht müßte ich auch mal einen 4-Chord-Song (https://www.youtube.com/watch?v=5pidokakU4I) machen...
zatzen hat geschrieben:Ansonsten könnte ich Dir höchstens anbieten, falls Du Musik von mir gemacht haben wolltest, dass ich Dir das irgendwie in Notenform zukommen lasse, und Du es in prISM programmierst.
Aber man weiss es nicht. Ich will jetzt auch nicht sagen dass ich prISM nie wieder anrühren werde. Alles eine Frage von Lust und Laune.
Ach naja. Ich habe nur - genau wie die anderen Coder hier - mein Zeug im Forum vorgestellt. Und wie auch bei allen anderen besteht keine Pflicht, es zu benutzen oder zu mögen. Wie schon erwähnt, mußte zu ISM einfach noch ein Interface her, um den Kram auch einzugeben. Und diese "Jede Stimme für sich"-Idee von ISM steht ja quasi in krassem Kontrast zu Idee der MOD- und MOD-artigen Formate. Daher fehlt mir auch noch die maßgebliche Idee, das Ganze in "Tracker-Darstellung" editierbar zu machen ohne damit völlig umständliche Daten zu erzeugen. Meiner groben Einschätzung nach wäre selbst die Mühe, eine (editierbare) Trackeransicht zu programmieren, letztendlich vergebens, da sie natürlich trotzdem keine exakte Replik des jeweiligen Lieblingstrackers des entsprechenden Musikers werden würde - und somit wahrscheinlich ebenso nicht genutzt würde, solange besagter Lieblingstracker zur Verfügung steht.
zatzen hat geschrieben:Die klassischen Amiga MODs funktionieren auch über eine Rasterung in 50 Hz, somit hat man bei den älteren nur Tempi wie 94, 107, 125, 150 BPM. [...]
Ja, wie erwähnt: Diese Rasterung hat direkt mit der Bildwiederholfrequenz des PAL-TV zu tun. Daher gibts da auch die 50 /60 Hz Einstellung bei MOD-Playern. Weil die US-Versionen der Grafikchips von C64, Amiga und ähnlichem natürlich für's US TV-Format (ca. 60 Hz) ausgelegt sind.
zatzen hat geschrieben:Die Redundanz in Trackerfiles kommt wie gesagt auch daher, dass Tracker-Editoren
umfangreiche Kopierfunktionen beinhalten. Hat man also einmal z.B. die Schlagzeugspur fertig, kann man sie beliebig oft kopieren, oder man kopiert einfach das ganze Pattern zum nächsten, um nur kleine Änderungen zu machen. Beispielsweise die komplette Begleitung so lassen und nur die Melodiestimme ändern.
Naja, eigentlich kommt die Redundanz nicht von der Kopierfunktion, sondern sie ergibt sich schlicht aus dem MOD-Format selbst, in dem ein Pattern immer alle Stimmen gleichzeitig enthält und man somit keine Möglichkeit hat, nur bei einzelne Stimmen "etwas anderes" zu machen, ohne dafür ein NEUES Pattern zu nehmen und dann die gleichbleibenden Sachen nochmals zu schreiben (oder eben zu kopieren). Die Kopierfunktion verhindert eben nur, daß man z.B. eine gleichbleibende Percussionsequenz hunderte Male von Hand eingeben muß. Vorhanden sein muß sie aber eben diese hunderte Male, sonst funktioniert MOD nicht. (Das ist ja der Haupt-Unterschied zu ISM.)
zatzen hat geschrieben:Ich würde darauf abzielen, ISM eher ohne Samples zu verwenden, oder wirklich nur bestimmte Klänge wie z.B. eine Snare als Sample.
Das war auch die Idee dahinter.
zatzen hat geschrieben:
Ach naja, darum geht's mir nicht. Wie bereits erwähnt, brauche ich ja nicht "bereits vorhandene Musik", nur um zu hören, wie sie in der extrem reduzierten Qualität von ISM klingt
Das war nur meine Sorge. Ich stelle es mir eher frustrierend vor wenn man monatelang
an einem Musiksystem inkl. Editor programmiert hat, aber es dafür kaum "Software" gibt.
Ach naja, daher hab ich ja mit meinem Testfile (Ente) herumgespielt - und noch meine paar *.MSX Musiken dafür konvertiert. Musikalische Höhenflüge wird man damit nicht erreichen ... aber dann paßt es wenigstens zur Grafik und den anderen Dingen in meinen geplanten Spielen. Wirkt immer doof: Musik in Orchesterqualität, Grafik wie 1982. Oder umgekehrt: Grafik wie Gemälde, Musik wie Triola.
zatzen hat geschrieben:Daher mein Angebot zu dem Compiler, um einfach etwas mehr Musik über ISM zu hören. Auch wenn die Qualität extrem reduziert wäre, könnte man sich so doch einen guten Eindruck von der Leistungsfähigkeit von ISM machen.
Naja, wie gesagt: So einen Converter/Compiler hatte ich auch schon mal irgendwann "im Kopf". Das MOD-Format ist nicht gerade 'ne Wissenschaft und solange es keine allzu tracker-spezifisch modifizierten MODs sind, wäre es technisch möglich. Aber das Ganze hat für mich derzeit keine große Priorität - ich bin momentan (wenn ich überhaupt mal zum Programmieren komme), an der Entwicklung meines "Spiel-Rahmens".
zatzen hat geschrieben:Das ist richtig, ZSM ist eigentlich "lame", weil es außer Lautstärke keine Effekte unterstützt, und das alles damit die Abspielroutinen einfacher zu programmieren waren - sonst hätte ich das wohl nicht durchgezogen.
Ach, dafür daß es angeblich so "lame" ist, bringt es ziemlich was auf die Lautsprecher
zatzen hat geschrieben:Die einzige Daseinsberechtigung sehe ich nun in der Kompaktheit der Daten, ein ZSM ist immer mindestens weniger als halb so groß wie das entsprechende MOD von dem konvertiert wurde.
Ja, die Kompressionsrate ist wirklich beeindruckend - und es wird ja nicht im Speicher entpackt und dann abgespielt - sondern die Daten werden in dieser komprimierten Form direkt gespielt, das ist schon super.
zatzen hat geschrieben:dB:
Wirklich kratzendes digitales Übersteuern passiert nur, wenn Überläufe passieren.
Ja, das meine ich ja.
zatzen hat geschrieben:Relativ sauberes Clipping erreicht man, indem man diese abfängt.
Ich will die gar nicht abfangen. Der maximale Wert wenn alle aktiven Stimmen mit maximaler Lautstärke spielen ist bei mir 255, da gibt's nie Clipping. Würde ich nachträglich gegensteuern, würden vielleicht absichtlich leise Parts zu laut werden bzw der Unterschied zwischen leisen und lauten Parts zu gering, wenn immer alles auf so ein Level gefixt wird. Anders ausgedrückt: Wenn z.B. 4 Stimmen aktiv sind und 3 davon sind gerade zufällig still, darf die 4. deswegen nicht lauter werden.
zatzen hat geschrieben:Der Befehl SAL hingegen ist ja genau der gleiche wie SHL, und beim Linksshiften von
vorzeichenbehafteten Werten muss man nur aufpassen dass man sie nicht zu weit shiftet, weil sonst das Vorzeichen verloren geht und man sozusagen Datenmüll hat.
Naja, eigentlich geht es nicht verloren, weil kleine negative Zahlen ja die obersten Bits alle =0 haben.
-32 ist bespielsweise %11100000, schiebt man zwei Bits nach oben, ist es -128, was immer noch korrekt ist.
Würde man natürlich um 6 Bits schieben, erhält man natürlich keinen vernünftigen Wert mehr - aber das gilt auch für positive Zahlen.
zatzen hat geschrieben:Bei SAR bemerke ich gerade eine Sache:
Das höchstwertige Bit wird immer übernommen bzw. dupliziert.
Wenn ich nun eine -1 habe also $FF, dann ergibt ein Shiften mit SAR wieder eine -1.
Richtigerweise, könnte man meinen, müsste aber doch eine 0 rauskommen.
SAR ist ja nicht wirklich eine Vorzeichen-Division durch 2, sondern kann nur in manchen Fällen entsprechend genutzt werden. Es ist eine binäre Rechtsschiebung eines Wertes unter Beibehaltung des höchsten Bits, das und nichts anderes soll es auch sein. Das Ganze ist auch logisch: Nehmen wir an, wir haben eine negative Zahl in DX und AX (AX=Low-Word) gespeichert und wollen diese nun verschieben. Dann muß auch DX weiterhin $FFFF bleiben, auch wenn es das schon ist, sonst würde die ganze Zahl "umkippen".
Wenn man in diesem Fall eine korrekte Division haben will, muß man eben die Division benutzen - oder den Fall vorher abfangen.
Anders ausgedrückt, werden beim Rechtsschieben von positiven Zahlen, diese gegen 0 abgerundet, beim Rechtsschieben negativer Zahlen diese gegen -1 aufgerundet.
Wer es anders will (d.h. in jedem Fall abrunden), muß negative Zahlen in positive wandeln (NEG), dann shiften, dann wieder wandeln.

Beispiel dafür, daß es nicht nur bei -1 so ist:
9 SAR1 = 4 (also abgerundet), weil %00001001 -> %00000100
-9 SAR1 = -5 (also aufgefundet), weil %11110111 -> %11111011

(Das ganze liegt einfach daran, daß negative Zahlen auf Computern als 2er-Komplement, nicht als 1er-Komplement dargestellt werden - weil es für die Maschine so einfacher zu rechnen ist: Um eine Subtraktion zu "simulieren" (wenn man den Übertrag ignoriert), kann man so einfach eine "negative" Zahl zu einer anderen addieren.)

Klar?

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Do 6. Apr 2017, 17:16
von zatzen
Wobei ich es aber auch als noch größere Kunst ansehe, mit kleinen "unscheinbaren" Samples
oder ganz ohne Samples trotzdem noch etwas auf die Beine zu stellen.
Ja, das kann auch seinen Reiz haben, früher hätte mir echte Polyphonie mit Rechtecken
gereicht, oder ein ähnlicher Synth wie das NES System ihn hatte. Ist ISM vielleicht von den
klanglichen Möglichkeiten damit vergleichbar oder übertrifft ihn sogar?
Kam mir jedenfalls so vor.
Für meine Musikprojekte außerhalb von Spielen, die letztlich auf einer CD oder
für die jüngeren Leute leider nur noch in einer MP3 landen, nutze ich gerne
größere Samples weil es bei diesem Extrem wieder faszinierend sein kann
was man mit Samples zaubern kann, die nicht nur einen einzigen Ton darstellen
sondern direkt einen Mehrklang oder auch Melodien, z.B. Gesang oder kleine
Ausschnitte aus einem Musikstück. Mich inspirieren oft Klänge die ich zufällig
höre, die verarbeite ich zu Samples, und dann kann ich sie zu etwas neuem
verbinden. Die Klangfarben sind mir sehr wichtig, und da kommt es mir
gerade recht dass ich davon beliebig viele verwenden kann.
Für Spiele-Musik kann ich mir aber natürlich keine sonderlich großen oder
übermäßig viele Samples leisten, aber auch da kommt es mir sehr gelegen,
dass ich mit ZSM eine wirklich freie Klangwahl hätte und sich die Musik am
Ende eher nach echten Instrumenten als nach Synthesizer anhören kann.
Vielleicht sollte ich, um einfach nur mal ein Spiel zu machen das meine
Units verwendet, ein Tetris machen.
Viele Programme erschlagen einen auch einfach mit Funktionen - man kann die nützlichen von den überflüssigen kaum noch trennen - und außerdem will man ja nicht nur EIN EINZIGES Programm zu seinem ganzen Lebensinhalt machen
Es gibt wie erwähnt moderne Tracker, die haben so viele Features, man kann direkt beliebig
lange 16- oder noch höher Bit Samples verwenden, sicherlich auch Stereo-Samples, Hüllkurven
gehen sowieso, dazu kann man Plugins reinladen die den Sound direkt manipulieren können,
kurzum kann man direkt aus dem Tracker raus seine fertig gemischte und gemasterte Produktion
ziehen.
So zu arbeiten ist mir aber zuwider, ich möchte mich im Tracker erstmal nur auf die Komposition
konzentrieren, dann rendere ich die Spuren raus, dann wird in einem anderen Programm in aller
Ruhe abgemischt, und wenn der Mix fertig ist wird gemastert.
Dauert alles etwas länger, aber ist mir so lieber, denn auf eine Weise ist es sogar flexibler,
und ich bekomme so bessere Ergebnisse hin.
wenn man einen "samplebasierten" Tracker benutzt, wird man auch kaum jemals Hüllkurven selbst definieren oder ähnliches.
Seit Fasttracker II können die meisten Tracker Hüllkurven. Aber ich selbst habe soetwas
nie benutzt, und es entspricht auch nicht meinem persönlichem Empfinden wie man
"trackert". Hüllkurven empfinde ich als etwas das mit MIDI zu tun hat und damit, dass
man Musik über ein Keyboard einspielt. Wenn ich aber in meinem Tracker Musik mache
definiere ich lieber ganz genau den Lautstärkeverlauf mittels Befehlen im Pattern.
Viele Samples, die ich verwende, habe ihre eigene "Hüllkurve" von Haus aus, weil es
oft eben nicht nur einzelne Töne sind, sondern eher komplexe Klanglandschaften.
Ach naja. Ich habe nur - genau wie die anderen Coder hier - mein Zeug im Forum vorgestellt. Und wie auch bei allen anderen besteht keine Pflicht, es zu benutzen oder zu mögen.
Ich mag es. Aber es fällt mir schwer es zu benutzen.
Ich wäre gespannt darauf, mehr Musik über ISM zu hören.
Weil die US-Versionen der Grafikchips von C64, Amiga und ähnlichem natürlich für's US TV-Format (ca. 60 Hz) ausgelegt sind.
Da kommt gerade eine Frage in mir auf.
Orientieren sich Computer wie Amiga oder auch Konsolen wie die alte NES was die
Framerate angeht nicht an diesen 50 oder 60 Hz?
Mir ist beim alten NES nie aufgefallen, dass die Framerate mal in den Keller
gegangen wäre. Du weisst warum ich das Frage... Weil ich immer noch alles
über den Sound-Interrupt time. Und das auch nur, weil mir das unabhängige
timen von Grafik und Sound ein Rätsel ist.
zatzen hat geschrieben:
Das ist richtig, ZSM ist eigentlich "lame", weil es außer Lautstärke keine Effekte unterstützt, und das alles damit die Abspielroutinen einfacher zu programmieren waren - sonst hätte ich das wohl nicht durchgezogen.


Ach, dafür daß es angeblich so "lame" ist, bringt es ziemlich was auf die Lautsprecher
Es fallen eben viele MODs flach, die meisten lassen sich nicht zu ZSM konvertieren,
wegen der Effekte, es würde falsch klingen. Was ZSM dem alten MOD voraus hat
sind beliebige BPM und dem MOD Format generell, beliebige C-3 Frequenzen bei
kleinerer Pitch Tabelle. Die Frequenzwerte sind wirklich beliebig, ich könnte
wenn ich einen Tracker dafür schreiben würde auch z.B. orientalische Tonleitern
definieren.
Der maximale Wert wenn alle aktiven Stimmen mit maximaler Lautstärke spielen ist bei mir 255, da gibt's nie Clipping. Würde ich nachträglich gegensteuern, würden vielleicht absichtlich leise Parts zu laut werden bzw der Unterschied zwischen leisen und lauten Parts zu gering, wenn immer alles auf so ein Level gefixt wird.
Ich glaube, Du hast da eine dynamische Lautstärkeregelung im Sinn. Aber meine
die ganze Zeit nur eine einmalige, statische Einstellung.
Bei Dir macht es wirklich Sinn, da die Werte nur von -8 bis +7 gehen, und das
bei 16 Stimmen, alles so aufzuaddieren und so zu belassen.
In der Praxis wirst Du nur die -128 bzw. +127 selten bis gar nicht erreichen.
Deswegen mache ich ja bei meinem Player nur eine Halbierung der Lautstärke
und clippe dann, denn die meisten 4 Kanal Module passen da noch gut rein,
und mit einer Viertelung der Lautstärke reicht es so gut wie immer auch
noch für 16 Kanäle. Wenn ich dafür aber jetzt die Lautstärke auf 1/16tel
machen würde, dann wäre alles sehr leise und verrauscht.


Ja, es macht Sinn wenn man es bei SAR mal so sieht dass auf -1 "hochgerundet" wird.
Das mit dem 2er und 1er Komplement hab ich auch mal nachgelesen, danke!


Das Einrichten des Prefetchs im ZSM Player gestaltet sich unerwartet haarig...
Das soll so auf keinen Fall in die reinen Abspielroutinen für andere Anwendungen
rein, aber der Pattern-Darstellungsmode motiviert mich einfach zu stark...

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 8. Apr 2017, 11:25
von DOSferatu
zatzen hat geschrieben:
Wobei ich es aber auch als noch größere Kunst ansehe, mit kleinen "unscheinbaren" Samples
oder ganz ohne Samples trotzdem noch etwas auf die Beine zu stellen.
Ja, das kann auch seinen Reiz haben, früher hätte mir echte Polyphonie mit Rechtecken
gereicht, oder ein ähnlicher Synth wie das NES System ihn hatte. Ist ISM vielleicht von den
klanglichen Möglichkeiten damit vergleichbar oder übertrifft ihn sogar?
Kam mir jedenfalls so vor.
Ich weiß nicht genau, wieviele Welleformen der Soundchip des NES unterstützt.
ISM hat 7 Wellenformen: Dreieck, Sägezahn, Halber Sägezahn, und Rechteck in 4 LO/HI-Verhältnissen.
Bis zu 4 dieser Wellenformen können zu einer Gesamtwelle addiert werden. Außerdem kann dabei ein Faktorwert benutzt werden, um einzelne der kombinierten Wellen zu verdoppeln, verdreifachen (4-... 8-fachen)...
Daraus ergeben sich tausende verschiedene Wellenformen.
Dann hat ISM noch einen Rauschgenerator (erzeugt blaues Rauschen durch einen BIAS-basierten Pseudozufallsgenerator mit einem "Durchlauf" von 65536 - d.h. die Wertefolge wiederholt sich erst nach 65536 Durchläufen - zum Vergleich: Beim SID sind es 8388608 Durchläufe = 2^23)
Außerdem kann man auch komplett eigene Wellen benutzen, indem man ein Sample lädt und einen Teil davon "ausschneidet" und als Welle benutzt.
Die Welle ist in Wirklichkeit auch nur ein "Sample", das in ISM generiert wird und 32 "Frames" groß ist.
zatzen hat geschrieben:Für meine Musikprojekte außerhalb von Spielen, die letztlich auf einer CD oder für die jüngeren Leute leider nur noch in einer MP3 landen, nutze ich gerne größere Samples weil es bei diesem Extrem wieder faszinierend sein kann was man mit Samples zaubern kann, die nicht nur einen einzigen Ton darstellen sondern direkt einen Mehrklang oder auch Melodien, z.B. Gesang oder kleine Ausschnitte aus einem Musikstück. Mich inspirieren oft Klänge die ich zufällig höre, die verarbeite ich zu Samples, und dann kann ich sie zu etwas neuem
verbinden.
Ja, schon - aber wenn man das selbst durch Klangsynthese hinbekäme, wäre es auch nicht schlecht (und spart Sample-Speicher).
zatzen hat geschrieben:Die Klangfarben sind mir sehr wichtig, und da kommt es mir gerade recht dass ich davon beliebig viele verwenden kann.
Naja, wie erwähnt, kann man in ISM auch komplett eigene Wellen nutzen. Nur sind diese eben maximal 32 Frames lang (und wiederholen sich dann). Da ISM aber auf 4-Bit-Wellen ausgelegt ist, erscheinen mir 32 Frames als ausreichend.
zatzen hat geschrieben:Für Spiele-Musik kann ich mir aber natürlich keine sonderlich großen oder übermäßig viele Samples leisten, aber auch da kommt es mir sehr gelegen, dass ich mit ZSM eine wirklich freie Klangwahl hätte und sich die Musik am Ende eher nach echten Instrumenten als nach Synthesizer anhören kann.
Ich fände es nicht so schlimm, wenn ein Computerspiel auch "computermäßige" Musik hat.
zatzen hat geschrieben:Vielleicht sollte ich, um einfach nur mal ein Spiel zu machen das meine Units verwendet, ein Tetris machen.
Ein Tetris (in 40x25 Textmode) habe ich auch schonmal gemacht. Das lustige ist, daß im Hintergrund eigentlich sogar eine "Musikabspiel-Routine" läuft, die aber nichts abspielt. Wenn man das Tetris aber mit Parameter einer meiner MSX-Musiken (z.B. die aus meinem 4-Gewinnt) startet, läuft im Hintergrund dann die ganze Zeit die entsprechende Musik. Mann bin ich manchmal crazy...

zatzen hat geschrieben:
Viele Programme erschlagen einen auch einfach mit Funktionen - man kann die nützlichen von den überflüssigen kaum noch trennen - und außerdem will man ja nicht nur EIN EINZIGES Programm zu seinem ganzen Lebensinhalt machen
Es gibt wie erwähnt moderne Tracker, die haben so viele Features, man kann direkt beliebig lange 16- oder noch höher Bit Samples verwenden, sicherlich auch Stereo-Samples, Hüllkurven gehen sowieso, dazu kann man Plugins reinladen die den Sound direkt manipulieren können, kurzum kann man direkt aus dem Tracker raus seine fertig gemischte und gemasterte Produktion ziehen.
Ja, es ist mir bewußt, daß einige der umfangreicheren Tracker auch Hüllkurven anbieten. Bei Verwendung von Samples erscheint mir das etwas merkwürdig, weil das Sample selbst normalerweise ja seine eigene "Hüllkurve" hat.
Das ist auch der Grund, wieso in ISM die Hüllkurven-Funktion nur für die Wellen-Klangsynthese, aber nicht für den "Sample-Modus" benutzt wird.
zatzen hat geschrieben:So zu arbeiten ist mir aber zuwider, ich möchte mich im Tracker erstmal nur auf die Komposition konzentrieren, dann rendere ich die Spuren raus, dann wird in einem anderen Programm in aller Ruhe abgemischt, und wenn der Mix fertig ist wird gemastert.
So kann ich ja nicht arbeiten - denn dann kommt am Ende ein WAV, MP3 oder sonstwas speicherfressendes/rechenzeitfressendes raus, das ich nicht in einem Spiel verwenden kann. Der Player muß mit seinen Daten schon die Musik so abspielen können, wie sie am Ende klingen soll - anders geht's nicht.
zatzen hat geschrieben:Dauert alles etwas länger, aber ist mir so lieber, denn auf eine Weise ist es sogar flexibler, und ich bekomme so bessere Ergebnisse hin.
Ja, aus Musiker-Sicht ist das natürlich richtig. Aber - wie oben erwähnt - habe ich ja während des Spielablaufs und der Generation der Musikstimmen nicht den Luxus eines entsprechenden Post-Processings. Das Zeug, was der Generator (ISM) auswirft, muß die Soundhardware (SoundBlaster, Speaker) so nehmen.
zatzen hat geschrieben:
wenn man einen "samplebasierten" Tracker benutzt, wird man auch kaum jemals Hüllkurven selbst definieren oder ähnliches.
Seit Fasttracker II können die meisten Tracker Hüllkurven.
Wie gesagt: Ich weiß...
zatzen hat geschrieben:Aber ich selbst habe soetwas nie benutzt, und es entspricht auch nicht meinem persönlichem Empfinden wie man "trackert". Hüllkurven empfinde ich als etwas das mit MIDI zu tun hat und damit, dass man Musik über ein Keyboard einspielt.
Und genau das ist ja die Idee hinter ISM. ISM soll quasi in Software das machen, was ein Synthesizer/Keyboard in Hardware macht. Und der Sound, der dabei herauskommt, ist eben dieser 80er/Anfang 90er-Sound von Computer-/Konsolenspielen.
zatzen hat geschrieben:Wenn ich aber in meinem Tracker Musik mache definiere ich lieber ganz genau den Lautstärkeverlauf mittels Befehlen im Pattern.
Den "HLD" (="hold") Befehl habe ich genau zu diesem Zweck noch "nachträglich" in ISM eingebaut. Dazu habe ich bei einem anderen Befehl die Parameter-Reichweite halbiert, die sowieso zu groß angelegt war. (Transponieren um +/-127 Halbtöne reicht aus, das müssen keine 255 sein - anderenfalls kommt man schon weit in die nicht von Menschen hörbaren Frequenzen ober- und unterhalb.)
Der HLD-Befehl spielt den gerade beendeten Ton weiter. Das dient dazu, davor noch andere Befehle wie Änderungen von Lautstärke/Wellenform/Frequenz usw. einfügen zu können - um damit Effekte abbilden zu können, die ISM nativ nicht enthält.
zatzen hat geschrieben:Viele Samples, die ich verwende, habe ihre eigene "Hüllkurve" von Haus aus, weil es oft eben nicht nur einzelne Töne sind, sondern eher komplexe Klanglandschaften.
Ja, wie gesagt - das macht ja ein Sample aus und daher wird auf das Sample bei ISM nicht noch eine zusätzliche Hüllkurve gelegt (außer man nutzt einen Teil des Samples als "Welle").
zatzen hat geschrieben:
Ach naja. Ich habe nur - genau wie die anderen Coder hier - mein Zeug im Forum vorgestellt. Und wie auch bei allen anderen besteht keine Pflicht, es zu benutzen oder zu mögen.
Ich mag es. Aber es fällt mir schwer es zu benutzen.
Naja - zum Mögen, weil's vielleicht "so schick aussieht" oder "so crazy zu bedienen" ist, ist es ja nicht gedacht. Es ist nur ein Tool - ein Arbeitsgerät zur Benutzung. Wie in dem anderen Beitrag erwähnt: Wenn man schon ein Format und einen zugehörigen Player entwickelt, der zu nichts kompatibel ist, sollte natürlich auch mindestens ein Editor existieren, um diese Daten einzugeben/anzuschauen/ändern usw.
Alles "trackerartige"/"MOD-artige" würde die Daten nur unzureichend und verfälscht darstellen.

Der Hauptgrund ist, daß es zwischen zwei Notenbefehlen quasi unzählige "Steuerbefehle" geben kann, die keine Abspiellänge haben, sondern dem internen setzen/ändern von Daten dienen. Wo sollten diese in einem Editor stehen, dessen Darstellung darauf basiert, Tonlängen durch Abstände darzustellen?
Schon ein File wie das zu meinem Test-"Entenlied" wäre in so einem Editor quasi nicht mehr darstellbar, bedingt durch Sprünge, Wiederholungen und Steuerbefehle.

Ich habe zwar schon Ideen für eingeschränkte Darstellungen - unter Verzicht auf ca. 70%-80% der Funktionen von ISM - aber das scheint mir keine adäquate Lösung.
zatzen hat geschrieben:Ich wäre gespannt darauf, mehr Musik über ISM zu hören.
Und ich erst...
Naja - aber momentan grüble ich noch gerade über ein gescheites Konzept der "Verbindung der Einzelteile" (Grafik, Sound, Steuerung, Menüsystem, Filesystem) zu einem brauchbaren Ganzen - also quasi zu einem "Rahmen" für ein Spiel(programm). Das heißt, im Moment habe ich gerade keine Zeit/keinen Nerv, um Musiken zu komponieren - auch wenn ich schon viele Ideen habe. Ich habe mir zu diesem Zweck auch neulich ein Diktiergerät angeschafft, um immer, falls mir mal zwischendurch eine Idee kommt, diese gleich "hineinsingen" zu können.
zatzen hat geschrieben:
Weil die US-Versionen der Grafikchips von C64, Amiga und ähnlichem natürlich für's US TV-Format (ca. 60 Hz) ausgelegt sind.
Da kommt gerade eine Frage in mir auf.
Orientieren sich Computer wie Amiga oder auch Konsolen wie die alte NES was die
Framerate angeht nicht an diesen 50 oder 60 Hz?
Wie es auf Konsolen gehandhabt wird, weiß ich nicht. Es könnte ja sein, daß der Soundchip mancher Konsolen eine "eigene CPU" oder ähnliches erhalten hat, die dann unabhängig von der "Haupt-CPU" die Sounddaten ausliest, dann berechnet und an die Soundausgabe weitergibt.
Beim C64 ist es definitiv so, daß, sobald man ein Spiel mit Scrolling und/oder Sprite-Multiplexing machen will, auf recht exaktes Timing angewiesen ist: Der Rasterzeilen-Interrupt kann so eingestellt werden, daß er immer ausgelöst wird, wenn die Bildausgabe (des VIC = Grafikchips) gerade an einer bestimmten Bildzeile ist. Dann kann man bestimmte Werte ändern - alles folgende wird dann vom Grafikchip mit diesen geänderten Werten ausgegeben...
Da kann natürlich die Musik nicht über einen der Timer (CIA1/CIA2) erzeugt werden, weil es dann vielleicht gerade an einem zeitkritischen Punkt erfolgt und somit die Grafik vermurkst werden würde. Deshalb generiert man dann Musik ebenfalls abhängig vom Rasterzeilen-Interrupt und zwar an den Stellen "im Bild", wo gerade keine Berechnung für die Grafik nötig ist. Das ist auch der Grund, wieso es so "Performance-Anzeigen" für die Musik-Player beim C64 gibt, die anzeigen, wieviele "Rasterzeilen" er für die Musik braucht.
Man muß hier wie eine Maschine denken: Ein C64-CPU Zyklus entspricht genau 8 Pixeln auf dem Bildschirm - das Timing der CPU läuft über den VIC (dieser ist 8x schneller getimed). D.h. man denkt WIRKLICH darüber nach, wo gerade der "Rasterstrahl" ist, während des Bild aufgebaut wird.
Und das - und NUR DAS - ist der Grund, wieso C64- (und Amiga-) Musik 50Hz/60Hz getimed sind. (Bekanntlich können beide an Fernseher angeschlossen werden - die PAL- und NTSC-Norm unterscheiden sich in der Bildwiederholfrequenz.)
zatzen hat geschrieben:Mir ist beim alten NES nie aufgefallen, dass die Framerate mal in den Keller gegangen wäre. Du weisst warum ich das Frage... Weil ich immer noch alles über den Sound-Interrupt time. Und das auch nur, weil mir das unabhängige
timen von Grafik und Sound ein Rätsel ist.
Der Einwand ist zwar verständlich - aber die Erklärung dafür ist sehr simpel:
NES, SNES, C64 - sind alles "monolithische Geräte": Es steht von vornherein fest, was die Hardware kann, d.h. wie schnell jedes einzelne Bauteil arbeitet, wieviel Speicher es adressieren kann, usw. (Die "Updates" des C64 waren alle 100% hardware-abwärtskompatibel.)

Programmiert man also auf so einer "unveränderlichen" Hardware, weiß man vorher ganz genau, was sie leisten kann und wird natürlich nicht über diese Leistung hinausgehen, um zu vermeiden, daß das Scrolling ruckelt, die Musik stottert, der Speicher nicht reicht...

Nun kommen wir aber zum PC, der von Anfang an ein "Baukasten-System" war: Jeder baut da nach Lust und Laune soviel Speicher ein wie er will - irgendeine CPU einer x86-Generation, die verschieden schnell getaktet sein kann und auch je nach Generation verschieden viele Zyklen zur Ausführung eines Opcodes braucht. Irgendeine Grafikkarte mit nicht vorhersehbarem Datendurchsatz, der schon davon
abhänigt, ob sie für ISA, VLB, PCI oder etwas noch moderneres ist - und natürlich auch vom Bus des Motherboards selbst (das quasi auch "frei wähbar" ist). Mit der Soundhardware verhält es sich ähnlich.
Die (Spiele-)Programmierer waren irgendwann froh, daß sich irgendwann so ein inoffizieller "Quasi-Standard" herausgebildet hatte, bei dem man davon ausgehen konnte, daß irgendwann jeder "so eine Art VGA-Karte" und "irgend etwas Soundblaster 2.0 kompatibles" in die Kiste eingebaut hat - bei der CPU mußte man eben eine gewisse "Mindest-CPU" voraussetzen, wenn man nicht alles auf 8086-er Niveau machen wollte.

Zu Zeiten davor gab es HerculesMono (sowie verschiedene "Farb-Hacks" dafür), CGA und EGA. Und es gab, neben AdLib ja auch noch Tandy (Grafik UND Sound), außerdem verschiedenes proprietäres Sound-Zeug für den Parallelport...
Da war man sich noch nicht einig, wohin die Reise geht - und VGA und SB waren noch sauteuer... Also mußte man in alle Spiele quasi jeden Kram supporten, damit es auch möglichst viele Leute kaufen.

Später, als es dann mit Windows als "Betriebssystem" (Win95) usw. losging, hat sich die Hardwareindustrie nicht mehr an Hardware-Schnittstellen-Standards oder IRGENDWELCHE Standards halten wollen - verständlich: um immer etwas besseres als die Konkurrenz verkaufen zu können... Ab da wurde das massiv, was es früher nur für so "Low-Speed-Peripherie" wie Mäuse gab: Treiber für jedes und alles (sogar für Motherboards...) - quasi ein Software-Nadelöhr, das ziemlich an der Performance kratzt... Das wurde dann lediglich mit immer schnelleren CPUs kompensiert, deren wahre Leistung wahrscheinlich kaum einer kennt oder je in Aktion gesehen hat - jedenfalls nicht unter Windows...

--- egal. Kennen wir ja alles.

Was will ich damit sagen? Nun ja: Bei so einem Baukastensystem hat man drei Möglichkeiten:
1. Man entwickelt nur für die eigene Maschine. Da läuft es dann, wenn man es gut macht, 100%ig so wie es soll. Das performt natürlich am meisten: Man kann jedes Bit ausnutzen, jedes noch so spezielle Register. Diese Software kann man aber nur bedingt jemand anderem geben, denn je "unähnlicher" dessen Maschine zur eigenen ist, umso schlimmer wird die Software performen - bis hin zum Komplettversagen.

2. Man entwickelt so kompatibel wie möglich - d.h. quasi für alle möglichen Systeme, die es gibt. Die einfachste Variante wäre hier, das "kleinste gemeinsame Vielfache". Das Extrem: Man entwickelt für 8086, mit Hercules Mono und PC-Speaker - dann sollte es wirklich auf ALLEN x86-PCs laufen. Natürlich mit sehr eingeschränkten Features.

3. Man entwickelt ab einem bestimmten System - aber von da aus so kompatibel wie möglich: D.h. man setzt eine bestimmte Mindestsystemleistung und Mindesthardware voraus, supportet dabei aber auch Hardware-Klone und langsame CPUs, um mit "kleinen" System trotzdem noch lauffähig zu sein - wenn auch mit geringerer Grafik-Framerate und geringerer Soundabspielfrequenz (und auf "großen" Systemen dann mit voller Leistung).

Wie vielleicht schon anhand meiner vielen Beiträge deutlich wurde, bevorzuge ich persönlich die dritte dieser Varianten - aber es gibt hier keine bessere oder schlechtere Wahl: Es ist alles eine Frage der persönlichen Einstellung und Ziele.

Da für mich persönlich - trotz der vielen Tools und Engines, die ich baue - am Ende der Reise immer ein (DOS-) COMPUTERSPIEL steht, habe ich mich für eine Variante entschieden, bei der ich einem guten Durchschnitt der DOS-PC-Benutzer mein Spiel geben kann, so daß ich (der Spiel-Entwickler) nicht der einzige bleibe, der das Spiel auch spielen kann - ebenfalls aber auch nicht derart eingeschränkt (8086, HercMono), daß ich den Spielern quasi kaum etwas bieten kann. - Aber - wie gesagt: das ist eine rein persönliche Entscheidung meinerseits.

Ich setze bekanntlich als Mindestanforderung einen 386er voraus - aber eben, weil ich 32bit-Register, erweiterte SegmentRegister und diverse 386er-Befehle nutze - nicht weil ein 386er die volle Leistung erreicht, die meine Programme (leider) oft benötigen. Deshalb möchte ich dem User die Wahl lassen, ob er bei nicht voller Leistung lieber an der Bildframerate spart, um feineren Sound zu haben oder an der Soundfrequenz spart, um flüssigeres Scrolling zu haben - oder, ob er trotz Nichtbesitz einer SB oder kompatiblen Soundkarte trotzdem noch spielen (oder zumindest antesten) kann, dann eben mit Speaker oder ganz ohne Sound.

Hinzu kommt, daß Grafikdarstellung nichts "Monolithisches" ist, d.h. man braucht auf PC zur Darstellung eines Spielgeschehens (z.B. schon durch Nichtvorhandensein von Hardware-Sprites) nicht für jedes Bildframe genau die gleiche "Rasterzeit": Sind mehr Figuren zu sehen, wird auch mehr Zeit zur Berechnung der Grafik gebraucht - soll dann etwa die Musik aussetzen? Da ist es mir lieber, wenn kurz mal die Bildrate einbricht als wenn die Musik komplett ausfällt.
Würde man jetzt alles über einen Soundkarten-Interrupt timen, müßte sich diesem alles unterordnen: Sowohl die Grafik als auch die Steuerung. Hat der Rechner nicht genügend Leistung, liefe das Spiel insgesamt langsamer. (Und hat der Computer keine SB-kompatible Karte, liefe das Spiel gar nicht...)

Und schlußendlich muß ja auch der Sound an sich berechnet/generiert werden, bevor ihn die SB abspielen kann. Berechnung des Sounds, der Steuerung, der Grafik müssen sich die vorhandene Rechenleistung teilen - allerdings sollte (meiner unmaßgeblichen Meinung nach) die allgemeine Spielgeschwindigkeit nicht darunter leiden. Somit besteht (für mich) keine andere Möglichkeit, als das Spielgeschehen über den Ticker zu timen und den Soundkarten-IRQ nur genau dafür zu benutzen, wofür er da ist: Anzuzeigen, wann der Puffer abgespielt ist, um auf den nächsten Puffer zu wechseln.

Mal ganz anders ausgedrückt: Ja, ich programmiere inzwischen auf x86-PC und ja, es macht mir auch Spaß - ABER:
Realistisch gesehen ist der x86-PC nicht gerade das ideale Gerät, um darauf Spiele zu programmieren - eben durch seine auswechselbare Hardware und nicht vorhersehbare Systemleistung. Ein Programm (Spiel) kommt auf einen PC und muß dann mit dem klarkommen, was es dort vorfindet - da geht's C64- oder Konsolenspielen weit besser...
zatzen hat geschrieben:
zatzen hat geschrieben:
Das ist richtig, ZSM ist eigentlich "lame", weil es außer Lautstärke keine Effekte unterstützt, und das alles damit die Abspielroutinen einfacher zu programmieren waren - sonst hätte ich das wohl nicht durchgezogen.
Ach, dafür daß es angeblich so "lame" ist, bringt es ziemlich was auf die Lautsprecher
Es fallen eben viele MODs flach, die meisten lassen sich nicht zu ZSM konvertieren,
wegen der Effekte, es würde falsch klingen. Was ZSM dem alten MOD voraus hat
sind beliebige BPM und dem MOD Format generell, beliebige C-3 Frequenzen bei
kleinerer Pitch Tabelle. Die Frequenzwerte sind wirklich beliebig, ich könnte
wenn ich einen Tracker dafür schreiben würde auch z.B. orientalische Tonleitern
definieren.
Ja, andere Tonleitern kann ich "intern" in ISM nicht, dafür aber extern - weil es bei mir nur eine generalisierte Frequenztabelle gibt und die kann man setzen auf was man will.
Samples enthalten bei mir nie Pitchtabellen - ich supporte dafür quasi (fast) alle Abspielfrequenzen (ich "runde" sie auf 128er, hatte schonmal erklärt wieso).
Der Nachteil ist, daß ich dafür vor jedem Ton eine entsprechende Berechnung ausführe, um den Wave-/Sample-"Additionswert" zu ermitteln.
Somit hat ein Sample bei mir keine Pitchtabelle und auch keine Grundfrequenz. Wird etwas in ein ISM-Sample gewandelt, enthält es der Einfachheit halber nur einen einzigen "Pitch"-Wert: Dieser gibt an, welche Frequenz man allgemein "hört", wenn man dieses Sample als WAV mit Abspielrate 16384 Hertz abspielen würde. Davon ausgehend werden die restlichen Töne berechnet. Und ja, es gibt KEIN Fine-Tuning bei mir: Aber: Die hörbare Frequenz kann dabei von 16,000 Hz bis 4111,9375 Hz (in 0,0625 Hz Schritten) eingestellt werden - genau genug, finde ich.

(Der Konverter rechnet das natürlich entsprechend um: Man gibt ein WAV an und wie es sich "anhört" und bei der Konvertierung in ISM-Sample "normiert" es diesen Wert für diese virtuellen 16384 Hz.)

Wie der Sample-Header aussieht, wird sowohl in _ISM.TXT als auch in _ISMFILE.TXT angegeben.
zatzen hat geschrieben:
Der maximale Wert wenn alle aktiven Stimmen mit maximaler Lautstärke spielen ist bei mir 255, da gibt's nie Clipping. Würde ich nachträglich gegensteuern, würden vielleicht absichtlich leise Parts zu laut werden bzw der Unterschied zwischen leisen und lauten Parts zu gering, wenn immer alles auf so ein Level gefixt wird.
Ich glaube, Du hast da eine dynamische Lautstärkeregelung im Sinn. Aber meine
die ganze Zeit nur eine einmalige, statische Einstellung.
Naja, sie ist nur dynamisch abhängig von den aktiven Stimmen. Eine Stimme ist bei mir auch dann aktiv, wenn sie gerade nicht spielt, aber "an" ist. D.h. Während z.B. ein 8-stimmiges Stück spielt und es spielen nur gerade 3 Stimmen davon, wird trotzdem nicht "hochskaliert" für 3, sondern es bleibt so.

Im "Entenlied" habe ich es - aus Testgründen - absichtlich so gemacht, daß ich die Stimmen erst nacheinander "aktiviere" (d.h. einschalte), da hört man natürlich die dynamische Regelung. Im Normalfall würde man aber natürlich so vorgehen, daß gleich am Anfang alle Stimmen eines Liedes "reserviert" (=eingeschaltet) werden und solange sie nicht spielen, mit "Stille" Befehlen laufen.

Die "Dynamik" dient lediglich dazu, wenn man insgesamt nur z.B. maximal 8 Stimmen verwenden will, nicht wegen der theoretischen Möglichkeit von 16 nutzbaren Stimmen die ganze Zeit nur mit halber Maximallautstärke auskommen muß. Das reine Vorhandensein von 16 möglichen Stimmen in ISM verpflichtet nicht zur ständigen Nutzung ALLER dieser Stimmen - vielleicht reichen einem Spielemacher ja auch 8 oder 6 Stimmen (z.B. 3 Musik, 3 Effekte) und er verteilt die übrige Rechnerleistung lieber auf die Grafikberechnung oder Steuerung. Es ist nicht immer so, daß 16 Stimmen besser klingen als 4.

Diese dynamische Anpassung geschieht ebenfalls über eine Tabelle, die immer nur (automatisch) neu berechnet wird, wenn entweder die Masterlautstärke oder die Anzahl angeschalteter Stimmen sich ändert.
zatzen hat geschrieben:Bei Dir macht es wirklich Sinn, da die Werte nur von -8 bis +7 gehen, und das bei 16 Stimmen, alles so aufzuaddieren und so zu belassen.
In der Praxis wirst Du nur die -128 bzw. +127 selten bis gar nicht erreichen.
Das stimmt - aber es ist auch gar nicht nötig. Wenn ich beim Soundblaster nur halbe Lautstärke einstelle, ist das (schon über meine kleinen Boxen) dermaßen laut, daß es als Hintergrundmusik schon nerven würde.
zatzen hat geschrieben:Deswegen mache ich ja bei meinem Player nur eine Halbierung der Lautstärke und clippe dann, denn die meisten 4 Kanal Module passen da noch gut rein, und mit einer Viertelung der Lautstärke reicht es so gut wie immer auch
noch für 16 Kanäle. Wenn ich dafür aber jetzt die Lautstärke auf 1/16tel
machen würde, dann wäre alles sehr leise und verrauscht.
Das kann ich nicht beurteilen, da ich ISM noch nie mit 16 Stimmen betrieben habe - ABER: Ich skaliere den Sound am Ende immer nur HOCH, nie RUNTER!
D.h. so wie es mit 1 Stimme klingt, klingt es dann auch mit 16 Stimmen.
Bei 16 Stimmen mit voller Lautstärke und voller Amplitude des jeweiligen Soundframes erreiche ich Werte von +119/-120. (also quasi 240 = 16*15), die muß ich dann entsprechend auf +127/-128 hochskalieren. Bei 4 Stimmen sind es +29/-30 (also quasi 60 = 4*15), die ich um einen größeren Faktor "hochziehen" muß. Anders ausgedrückt erhalte ich ziemlich treppenförmige Wellen, deren Stufen nur etwas kleiner werden, wenn es mehr Stimmen werden.

Das bedeutet: Beim Zusammenaddieren der Werte, die die Stimmen generieren, clippe ich NIEMALS, da könnte ich sogar noch mit 17 Stimmen hinkommen (17*15=255) - ich ziehe dann nachträglich hoch.
Das liegt daran, daß die Lautstärke ja pro Stimme verschieden sein kann und die Ungenauigkeit quasi schon hier entsteht. Deshalb klingt ISM ja auch so schlecht.
Andererseits ist es ja auf diese einfachen "geometrischen" Wellenformen ausgelegt, denen ungenaue "Lautstärkenmultiplikation" (Tabellen natürlich) weniger ausmacht als z.B. einem guten Sample.
zatzen hat geschrieben:Ja, es macht Sinn wenn man es bei SAR mal so sieht dass auf -1 "hochgerundet" wird. Das mit dem 2er und 1er Komplement hab ich auch mal nachgelesen, danke!
Keine Ursache. Mit Binärarithmetik habe ich mich schon zu Hochsprachen-Zeiten oft beschäftigt, um immer mal wo schöne Tricks anzuwenden oder mehr Leistung rauszuholen. In Assembler ist gute Kenntnis von Binärarithmetik natürlich noch um ein Vielfaches nützlicher.
zatzen hat geschrieben:Das Einrichten des Prefetchs im ZSM Player gestaltet sich unerwartet haarig... Das soll so auf keinen Fall in die reinen Abspielroutinen für andere Anwendungen rein, aber der Pattern-Darstellungsmode motiviert mich einfach zu stark...
Auf welche Art wird dieser Prefetch denn durchgeführt?

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 8. Apr 2017, 14:05
von zatzen
Soweit ich weiß kann der NES Soundchip nicht wirklich etwas kombinieren und hat
wohl auch keinen Sinus. Also vielmehr Dreieck, Rechteck, und wahrscheinlich
Sägezahn. Dazu noch Rauschen und manchmal wird noch 1 Bit Delta PCM genutzt.

Was mein allgemeines "Musikschaffen" angeht, das hat ja nichts mit Spielen zu tun -
ich nutze da einfach gern Samples experimentell bzw. als Inspiration.
Weiter brauchen wir hier auch nicht darüber diskutieren, es ist ja eigentlich offtopic -
es ist nur der Hintergrund, warum ich überhaupt Tracker Musik mache, nämlich nicht
durch Spiele motiviert sondern durch Musik zum einfach-so-anhören.

Hüllkurven bei Trackern können dann sinnvoll sein, wenn die Samples selbst
lautstärkemäßig eher statisch sind, oder man es mit Schleifen zu tun hat.

Und ja, natürlich kann man keine Postproduction der Musik machen für ein DOS-Spiel,
aber gerade deswegen würde ich gerne mal wieder Trackermusik für ein Spiel machen,
die direkt so klingen muss wie sie klingen soll, ohne dass ich mir das für die Nachbearbeitung
aufspare.


Ich mag ISM(!), wäre gespannt mehr zu hören. prISM find ich aber auch recht beeindruckend,
um damit zu arbeiten brauche ich aber Zeit und Motivation.
Der Hauptgrund ist, daß es zwischen zwei Notenbefehlen quasi unzählige "Steuerbefehle" geben kann, die keine Abspiellänge haben, sondern dem internen setzen/ändern von Daten dienen. Wo sollten diese in einem Editor stehen, dessen Darstellung darauf basiert, Tonlängen durch Abstände darzustellen?
Es könnte auf der entsprechenden Zeile ein Fenster aufgehen (z.B. durch TAB aktiviert)
in das man dann beliebig viele Steuerbefehle eintragen könnte. Das würde natürlich Dein
gesamtes Konzept über den Haufen werfen, es war auch nur so eine fixe Idee.
Aber vielleicht hätte ich das so gemacht, es würde das ganze etwas strukturieren.
Aber lass es mal so. Du wolltest etwas anderes machen als einen typischen Tracker und
so wie Du Dir das gedacht hast wird es seine Vorteile haben.
Danke für Deine ausführliche Erklärung bzgl. des Timings auf verschiedenen Systemen.
Ein unabhängiges Timing von Steuerung, Grafik und Sound hätte sicherlich etwas für sich.
Nur wie gesagt ist es mir ein Rätsel wie man das realisiert, und ich muss gestehen dass
ich mir darüber bisher auch noch nicht so viele Gedanken gemacht habe, weil für mich
die Sache mit dem Sound-Timing immer funktioniert hat.
Die Frage für mich wäre, ob man das "darf". Wenn keine Soundkarte vorhanden ist könnte
ich ja immer noch den Ticker den Soundinterrupt "simulieren" lassen, bzw. einfach das
flaggen lassen worauf das Programm jeweils wartet.
Wahrscheinlich auch wieder kein guter Ansatz, weil so Framerate verschenkt wird.
Aber mir sind variable Framerates, die jederzeit die volle Rechenkapazität ausnutzen,
völlig fremd. Lieber setze ich auf feste Framerates die noch angenehm sind, aber die
auf der Zielplattform (bei mir eben 486er) noch gut erreicht werden können. Nur als
Beispiel, es gibt Spiele wie Captain Comic, da ist die Framerate wenn ich nicht irre fest
10 fps (eher unangenehm), obwohl keine Soundblaster-Ausgabe vorhanden ist. Was
spricht also dagegen, alternativ, wenn Soundblaster vorhanden ist, über den Interrupt
zu timen - letztlich ist der Ticker auch nur ein Interrupt.
Ich weiß, wir drehen uns im Kreis und ich möchte Dich nicht nerven.
Ändern an meinem Prinzip des per Soundpuffer-timens kann ich aber erst dann etwas,
wenn ich verstanden habe, wie man es anders macht. Dazu kann ich mich belesen,
oder wir diskutieren es hier.

Früher als Kind habe ich was ich bei anderen Spielen gesehen habe, dass es die Grafik
in CGA, EGA und VGA gab, gerne nachgemacht.
Und ähnlich hätte ich es auch mit dem Sound gehandhabt.
Aber mittlerweile empfinde ich das als vergebene Mühen, denn nach meinem Empfinden
hat jeder eine VGA und jeder hat, zumindest auf einem DOS-System, eine Soundblaster-
kompatible Karte.
Von daher empfinde ich das eben nicht so sehr als Baukasten-System sondern eher
monolithisch, dass ich von diesen Voraussetzungen ausgehen kann.
Was für mich dann nur noch bleibt ist, dass ich die Performance im Auge behalten muss,
und da würde ich mich im Zweifelsfall dafür entscheiden, dass Grafik & Sound wenig
genug Rechenzeit beanspruchen, anstatt dass die Framerate einbricht.
Ich würde also gern ein Spiel rausgeben was bei Beachtung der Mindestvoraussetzungen
niemals hakelt oder ruckelt. Und diese Mindestvoraussetzung wäre für mich ein 486er,
den halte ich heutzutage nicht für zu übertrieben, und für Leute mit 386er funktioniert
das Spiel eben nicht richtig, so wie es vom 286er zum 386er auch einen Schnitt gab.
Der 386er versteht zwar dieselben Befehle wie der 486er (bis auf eine handvoll neuer),
aber der 486er führt sie nochmals deutlich schneller aus wegen höherer Taktzahl und
weniger Taktzyklen für den gleichen Befehl.
Wissen wir alles, ich wollte nur mal meine Situation darstellen.
Auf einem 386er könnte ein Spiel von mir aber dennoch laufen, nämlich dann, wenn ich
den Ton abstelle, und die Grafik über den Ticker getimet wird.
Die Steuerung wäre bei mir auch mit der Framerate gekoppelt, vielleicht noch so ein
Ding der Unmöglichkeit, aber vielen Fällen funktioniert das sehr gut.


Pitchtabellen pro Samples sind auch etwas ungewöhnliches.
Aber ich habe einfach gemerkt dass die meisten Samples im Schnitt nicht mehr als sagen
wir auf 10 verschiedenen Tonhöhen gespielt werden, und da kann man schon was
einsparen gegenüber einer fetten Tabelle wie sie in MOD-Playern zu finden ist.
Das hat auch mit dem ganzen ZSM System zu tun, wenn es für ein Sample nur einen
Tabellenwert gibt, z.B. eine Bassdrum die nur auf einem Ton gespielt wird, dann
brauche ich in den Patterns gar kein einziges Bit mehr um den Ton zu definieren,
denn der ist ja immer gleich.
Den Ton jeweils vorher berechnen wäre wohl auch nicht so schlimm gewesen was die
Performance angeht, aber wie gesagt ist das alles auch eine Sache des Systems.

Das bedeutet: Beim Zusammenaddieren der Werte, die die Stimmen generieren, clippe ich NIEMALS, da könnte ich sogar noch mit 17 Stimmen hinkommen (17*15=255) - ich ziehe dann nachträglich hoch.
Das hatte ich schon vergessen, ich verwende zur Lautstärkeanpassung bloßes Shifting -
es geht schlecht anders weil ich ja einen 16 Bit Zwischenpuffer habe, das gäbe eine
viel zu große Tabelle. Mir wären Multiplikationen mit 8 Bit zu "rauschig", aber ich muss
sagen was ich bisher in prISM gehört habe klang ganz ordentlich.


Prefetch bei ZSM:
Das Patterformat ist ja dafür ausgelegt, dass es Zeile für Zeile gelesen wird.
Wenn ich nun die Patterns einfach plain und komplett im Speicher hätte wäre das mit dem
Prefetch einfacher gewesen. Ich habe mir gedacht, da der Bildschirm im Textmodus 25
Zeilen hat, mache ich mir ein Array von 24 Zeilen. Diese enthalten für alle je 16 Kanäle
die Information zur jeweiligen Zeit, d.h. Sample, Frequenz, Lautstärke. Wenn ich nun eine
Zeile lese wird das Element 0 des Arrays mit einer Zeile beladen. Vorher werden alle
Elemente des Arrays eins nach oben gerückt. Über einen Abgriffpunkt definiere ich, an
welchem Punkt des Arrays[0..23] die Zeileninformationen gelesen und abgespielt werden
sollen.
Das hat erstmal ganz gut funktioniert, ich hatte einfach mal als Abgriffpunkt 22 definiert
und die Musik spielte so wie angedacht 22 Zeilen später los.
Prefetch an sich muss gemacht werden am Anfang, oder wenn man zum nächsten oder
vorherigen Sequencerpunkt springt.
Das "haarige" an der Sache waren nun die Anzeigen.
Es bringt ja nicht viel wenn der Player auf einmal der abgespielten Musik in seiner Anzeige
immer voraus ist. Deshalb mussten einige Werte wiederum in einem 24 Datensätzen
großen Array gehalten werden, und da bin ich noch nicht ganz fertig. Zwischendurch
hatte ich ein wenig an einer Division durch Null zu beißen, denn mit den Anzeigewerten
wird ja auch gerechnet. Es stellte sich heraus dass ich VOR der ganzen Anzeigerei den Puffer
füllen muss, weil aus der Pufferfüllroutine heraus die procedure read_row aufgerufen wird,
welche die obigen Arrays aktualisiert. Wenn sie erst danach kam hinkte das Werte-Array
nach.
Mit den ganzen Werten (wie auch die jeweils richtige Geschwindigkeit) im Boot konnte ich
dann die Visualisierung der Patterns machen, hier habe ich mir ein String-Array angelegt,
um nicht für jede Zeile aufs neue mit write oder str hantieren zu müssen - ich habe mir
eine schnelle Routine geschrieben, die Strings direkt in den Bildschirmspeicher schreibt.
Noch nicht ganz fertig das ganze, aber das schlimmste hab ich geschafft.
Ganz nett: Es kann jetzt pro Zeile angezeigt werden, wieviel Bit dafür gebraucht werden.
Bleibt nur noch zu erwähnen, dass ich die größeren Arrays auf dem Heap angelegt
habe, damit mir nicht verfrüht der Variablenplatz ausgeht.
Auch hatte ich bisher im Player für die Anzeigen nur eine Prüfung, ob die neue
Patternzeile nicht die gleiche ist wie die letzte - um wirklich nur dann zu aktualisieren
wenn sich etwas getan hat. Für die Patterndarstellung brauchte ich aber einen
Zähler, wie oft während des Puffers eine neue Zeile gelesen wurde, denn für
schnellere Module hat das mit der neue/letzte Zeile Überprüfung nicht funktioniert.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Mo 11. Jun 2018, 20:08
von zatzen
In einigen Wochen wird's wohl ein Update geben zusammen mit neuer Musik, ich bin im modarchive gerade bei
Kategorie F dran und wenn ich die durch habe verlinke ich einen Upload.

Die ZSM Engine unterstützt neben dem Abspielen von Musik auch Soundeffekte.
Das geschieht ganz einfach, indem man 4 Bit Delta Samples einzeln lädt und
dann eine Routine aufruft die das Abspielen veranlasst, dabei kann man die Samplefrequenz
und Lautstärke frei wählen und z.B. auch durch Zufallsgenerator dem ganzen etwas
Abwechslung einhauchen.

Jetzt hatte ich überlegt, ob es nicht auch reizvoll wäre, die Engine um die Option der
Sprachausgabe zu erweitern. Als Samplefrequenz müsste hier 16 kHz genügen, womit
die Datenrate bei 8000 Byte pro Sekunde liegen würde.
Die Frage ist nur, wie flechtet man die Daten am besten ein.
Ich denke, das ganze so zu lösen, dass man einen ganzen Satz, der mit 64K immerhin
8 Sekunden dauern könnte, auf einen Schlag einliest, hätte zwei Nachteile:
Man braucht 64K Puffer, und die Ladezeit, wenn man es nicht aus dem XMS
holt, wäre wahrscheinlich zu lang oder etwas Performance-kritisch, um das ganze
innerhalb einer Mischpufferdauer zu erledigen.
Was den XMS angeht: Ich kann mich erinnern dass bei Adventurespielen wie DOTT
bei Sprachausgabe immer von der CD-ROM gelesen wurde, also nichts vorher
in den Erweiterungsspeicher geladen wurde. Das führte aber zu merklichen Hängern.

Meine Idee war nun, dass man die Sprachausgabe vielmehr als Stream einliest,
also pro Soundpuffer immer nur so viel wie gebraucht wird. Ich würde mutmaßen,
dass sich dann die Ladezeiten in Grenzen halten, zumindest wenn das Spiel von
Festplatte läuft. Die Puffergröße des momentanen Players ist 1536 Samples (Samplepunkte).
Es bietet sich an, die Samplefrequenz der Sprachausgabe auf ein vielfaches bzw.
teilbares der Mischfrequenz zu legen, also sagen wir mal 22050 Hz.
Es ergibt sich ein Datendurchsatz von lediglich 384 Byte pro Mischpuffer,
nur so wenig müsste geladen und in einem Puffer gehalten werden.
Man kann das ganze auch weiterspinnen in Hinblick auf die Tatsache,
dass alle Samples hinzugemischt werden. ZSM kann tatsächlich theoretisch
beliebig viele Kanäle mischen, es hängt nur von der Leistung ab. So wäre
mehrkanälige Sprachausgabe möglich, also dass zwei oder drei Leute gleichzeitig
reden oder sich ins Wort fallen etc. Es müssen dann nur entsprechend mehr Daten
geladen werden, d.h. z.B. 768 oder 1152 Byte - wobei hier jeweils wahrscheinlich die
meiste Zeit für das "seeken" und nicht für das Laden selbst draufgeht.
Naja die Idee von mehrkanäliger Sprachausgabe kann z.B. einfach darauf abzielen,
dass nicht nur wie in einem Adventure ein sauberer getrennter Dialog stattfindet,
sondern auch in einem 2D Platformer die Charaktere etwas sagen, und zwar
wann sie wollen - so ähnlich wie mit Soundeffekten, nur mit Sprache, die man
aber eben nicht auf dem Heap unterbringen kann.

Allerdings bin ich ein gebranntes Kind was experimentieren mit DMA-Aktionen angeht.
Ich habe früher einmal versucht, per Soundblaster Musik abzuspielen und gleichzeitig
aufzunehmen. Als Ergebnis waren alle Dateien auf meiner Festplatte nicht mehr lesbar
die größer als eine Zuordnungseinheit waren.

Deshalb möchte ich meine Idee hier zur Diskussion stellen, möchte von Euch wissen
ob Ihr das für vernünftig haltet, oder ob es ein No-Go ist, immer wieder über längere
Zeit von der Festplatte zu lesen (also ein DMA Transfer) während gleichzeitig ständig
ein anderer DMA Transfer (Soundblaster) läuft.
In meinem ZSM Player habe ich bis jetzt alle Festplattenzugriffe vermieden, solange
die Soundausgabe läuft.
Aber ich habe Ende der 90er schonmal einen FLI-Player geschrieben, genauer gesagt
"FLS", nämlich FLI mit Sound, der bedeutend mehr Daten pro Frame von der Festplatte
gelesen hat und Bild + Ton ausgegeben hat, als bei dem was ich mir oben überlegt habe.

Also zusammenfassend:
Ich möchte XMS Nutzung lieber vermeiden, und dort ist die Sprachausgabe bei 11025 Byte/s
Datendurchsatz und sagen wir mal 4 MB XMS auf 6 Minuten beschränkt. Man könnte
natürlich das Spiel in Abschnitte unterteilen wo man eine Ladepause einlegt, aber
wenn das mit dem mehr oder weniger permanenten Festplattenzugriff okay wäre
hätte man mehr Freiheiten.

Ich meine übrigens bei Duke Nukem 3D beobachtet zu haben, dass es dort auch die
ganze Zeit über Festplattenaktivität gibt. Vermutlich sogar für den Sound, denn die
Engine gibt einem da scheinbar keine Grenzen vor (wir haben das nach Lust und Laune
modifiziert und hatten unseren Spaß).

Klar könnte man angesichts der Idee mit der Sprachausgabe auch den ZSM Musikplayer
anzweifeln und sich denken, streamen wir einfach die Musik als 22 oder 44 kHz 4 Bit Delta.
Das würde sich u.U. positiv auf die Performance auswirken und lediglich mehr Platz auf
der Festplatte fordern, und sogar mehr Platz im Speicher für die Grafik lassen.
Soetwas hatte ich sogar früher schonmal entworfen, ein System bei dem ich
Musikstücke in Teile geschnitten habe, um sie beliebig arrangieren zu können, allerdings für XMS gedacht.
Man hätte so auch die Möglichkeit, die Musik richtig zu produzieren und abzumischen,
und man würde Aliasing vermeiden können, das durch das rohe Pitchen der Samples entsteht.

Aber irgendwie hat die Geschichte gezeigt, dass es für Sprachausgabe legitim war, mal
eben 300 MB zu beanspruchen, während die Musik aber AdLib war, und sich der Rest
der Spieles inklusive aller Grafik mit 20 MB begnügte.
Die Musik war wohl auch AdLib, damit so ein Spiel überhaupt auf eine CD-ROM passte,
andererseits bei LucasArts aber auch begründet durch iMuse, ein System was von
einem Musikstück zum anderen moduliert, was man nicht so einfach durch Überblenden
oder einen Schnitt mit vorproduzierter Musik hinbekommt.
Wenn ich Musik mit 44.1 kHz streamen würde, also 22050 Byte/s Datendurchsatz,
wären das für 5 Minuten rund 6 MB, für 10 Musikstücke dieser Länge entsprechend
60 MB. Das könnte man noch gutheißen, wenn die Sprachausgabe ähnlich oder
mehr verbraucht.

Naja, ich denke da muss man sich überlegen in welcher Liga man spielen möchte.
Wenn ich den ZSM-Musikplayer weglasse und stattdessen die Musik streame, werde
ich wohl eher dazu tendieren, für die Grafik auch XMS zu benutzen und das ganze
etwas ausladender aufzuziehen. Es wäre dann auch interessant, in der Qualität
weiter nach oben zu gehen, Stereo und 16 Bit, allerdings immer noch basierend
auf 4 Bit Delta.
Benutze ich aber den ZSM-Musikplayer so wie er bisher steht, dann werde ich wohl
nur der Sprachausgabe eine Sonderrolle zukommen lassen - und darum geht's in diesem
Thema ja eigentlich nur, ob ein Streamen von kleinen Dateneinheiten von der Festplatte
technisch unbedenklich wäre, auch wenn das am Ende vielleicht 20x in der Sekunde passiert.

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Sa 28. Jul 2018, 11:46
von DOSferatu
zatzen hat geschrieben:In einigen Wochen wird's wohl ein Update geben zusammen mit neuer Musik, ich bin im modarchive gerade bei Kategorie F dran und wenn ich die durch habe verlinke ich einen Upload.
Ich warte gespannt und voller Ungeduld...
zatzen hat geschrieben:Die ZSM Engine unterstützt neben dem Abspielen von Musik auch Soundeffekte.
Das geschieht ganz einfach, indem man 4 Bit Delta Samples einzeln lädt und dann eine Routine aufruft die das Abspielen veranlasst, dabei kann man die Samplefrequenz und Lautstärke frei wählen und z.B. auch durch Zufallsgenerator dem ganzen etwas Abwechslung einhauchen.
Kann man die Soundeffekte auch quasi "von außen" aktivieren, während gerade Musik gespielt wird?
zatzen hat geschrieben:Jetzt hatte ich überlegt, ob es nicht auch reizvoll wäre, die Engine um die Option der Sprachausgabe zu erweitern. Als Samplefrequenz müsste hier 16 kHz genügen, womit die Datenrate bei 8000 Byte pro Sekunde liegen würde.
Die Frage ist nur, wie flechtet man die Daten am besten ein.
Ja, so wie z.B. bei "Day of the Tentacle". Da fand ich die Sprachausgabe wirklich gelungen und die Stimmen gut gewählt. (Am meisten mag ich ja die Stimme von Dr. Fred.)
zatzen hat geschrieben:Ich denke, das ganze so zu lösen, dass man einen ganzen Satz, der mit 64K immerhin 8 Sekunden dauern könnte, auf einen Schlag einliest, hätte zwei Nachteile:
Man braucht 64K Puffer, und die Ladezeit, wenn man es nicht aus dem XMS holt, wäre wahrscheinlich zu lang oder etwas Performance-kritisch, um das ganze innerhalb einer Mischpufferdauer zu erledigen.
Es kommt natürlich auf die Laufwerksgeschwindigkeit an - aber ja, Festplattenzugriffe "stören" quasi immer das ganze restliche Zeug. Ich weiß auch nicht, ob man hier mit anderer Priorisierung der IRQs irgendwie besser fahren würde - am Ende werden vielleicht Daten nicht mehr richtig vom Laufwerk gelesen, das wäre ja auch Mist... Vielleicht kennt sich jemand damit aus/hat Erfahrungen damit gemacht und kann hier mal berichten?
zatzen hat geschrieben:Was den XMS angeht: Ich kann mich erinnern dass bei Adventurespielen wie DOTT bei Sprachausgabe immer von der CD-ROM gelesen wurde, also nichts vorher in den Erweiterungsspeicher geladen wurde. Das führte aber zu merklichen Hängern.
Ich hatte nie Hänger - aber mein DOS-System ist ja auch echt erstklassig.
zatzen hat geschrieben:Meine Idee war nun, dass man die Sprachausgabe vielmehr als Stream einliest, also pro Soundpuffer immer nur so viel wie gebraucht wird. Ich würde mutmaßen, dass sich dann die Ladezeiten in Grenzen halten, zumindest wenn das Spiel von Festplatte läuft. Die Puffergröße des momentanen Players ist 1536 Samples (Samplepunkte).
Es bietet sich an, die Samplefrequenz der Sprachausgabe auf ein vielfaches bzw. teilbares der Mischfrequenz zu legen, also sagen wir mal 22050 Hz.
So "Fixpoints" können einerseits nützlich sein und andererseits ein Hemmschuh. Es kommt immer auf die restliche Programmierung an. Nehmen wir an, quasi "ALLES" (außer Ausgabe Musik/Sound) passiert dann an diesem Fixpoint. Dann hat man wieder so einen Totpunkt, der Aussetzer machen würde.
Bei Xpyderz habe ich das z.B. so gelöst: Das Spiel selbst läuft mit 50 Hz. Allerdings läuft der Ticker mit 400 Hz und bei jedem Tick (bzw. "de-synchronisiert", hatte das mal erklärt) erfolgt Aktion jeder 8. Figur. Auf diese Art habe ich das Ganze "regelmäßiger" verteilt. Grund war, daß das Steuer-Unterprogramm nicht von anderen Sachen unterbrochen wird - ich aber nicht zu lange darin verweilen wolte, damit andere Teile eine Chance haben, "dazwischenzufunken" (halt "Pseudo-Multitasking"). Der Plan sah ja ursprünglich vor, daß Xpyderz Multiplayer-fähig werden sollte, und damit die Zugriffe auf COM-Port bzw. Netzwerkkarte dazwischen auch noch zeitnah ausgewertet werden können, um im Spiel nicht unsynchron zu werden... naja.

Will damit nur sagen:
Wenn man, wie bei Spielen üblich, alles "quasi-gleichzeitig" macht, (also "Multitasking für Arme"), dann ist es gut, die Sub-Prozesse klein zu halten, bzw "stückelbar" zu machen, damit ein Prozeß nicht einen anderen "ausbremst". (Das Schlimmste ist das Generieren der Grafik. Das braucht viel Rechenzeit und man will es nicht zwischendurch unterbrechen, weil man dazu ja jedesmal neu "teil-initialisieren" müßte. Ich habe schon überlegt, ob ich mal ein echtes Multitasking für meine Games baue, so simples "Round Robin" Multitasking.
(Erklärung: Wo immer im Kreis verschiedene Teile ausgeführt werden, mit geplanten Unterbrechungen per Ticker - und dann hat jedes seinen eigenen Stack. Bei Task-Wechsel werden alle Register auf den Stack geschoben, dann werden SS und SP auf den NEUEN Stack getan und der Int wieder verlassen...)
zatzen hat geschrieben:Es ergibt sich ein Datendurchsatz von lediglich 384 Byte pro Mischpuffer, nur so wenig müsste geladen und in einem Puffer gehalten werden.
Naja, wie ich vor einiger Zeit schon mal erwähnte: ZU kleine Puffer erzeugen dann wieder andere Probleme: Eine Pufferbearbeitung besteht ja aus 3 Phasen:
* INIT
* PUFFERGENERIEREN (SAMPLES*SIZE)
* EXIT
Wobei INIT und EXIT immer gleichlang sind und PUFFERGENERIEREN von SIZE abhängt. Je kleiner SIZE ist, umso mehr Anteil an der Gesamtbearbeitung haben INIT+EXIT. Das kostet quasi Gesamtperformance für das Gesamtsystem (also quasi die Hauptsystemschleife).

Hier den guten Mittelweg zu finden ist - gerade für PCs - ziemlich schwer, weil PCs ja "Baukastensysteme" sind: Jeder hat einen unterschiedlich schnellen BUS, unterschiedlich schnelle Grafikkarten- und Soundkartenzugriffe, unterschiedlich schnelle Speicherzugriffe und, nicht zuletzt, auch unterschiedlich schnelle CPUs. Hier ist die beste Wahl - meiner bescheidenen Meinung nach - eine möglichst flexible Anpassung an das System. Dabei kann man es entweder dem User überlassen (z.B. die Soundfrequenz, die Grafikauflösung/Bildfrequenz oder ähnliches selbst zu wählen) oder eine automatische Anpassung (mittels interner Performance-Zähler). Xpyderz z.B. macht das Ganze für den Vertical Retrace bei Grafik auf 3 Arten:
Vertikal Retrace AUS, Vertikal Retrace AN oder AUTO (letzteres paßt es an die gemessene Systemleistung live immer wieder an). (So Messungen macht man mit einem Ringpuffer - kann das bei Interesse genauer erklären.)
zatzen hat geschrieben:Man kann das ganze auch weiterspinnen in Hinblick auf die Tatsache, dass alle Samples hinzugemischt werden. ZSM kann tatsächlich theoretisch beliebig viele Kanäle mischen, es hängt nur von der Leistung ab.
Cool. Ich dachte, das wäre auf 16 Stimmen beschränkt. ISM hat eine Beschränkung auf 16 Stimmen und ohne größere Änderungen am Code ist auch hier keine Erweiterung möglich.
Andererseits bitte ich dabei natürlich immer zu bedenken, daß ich (und vielleicht auch Du) für DOS-Maschinen programmieren wollen, d.h. wir reden hier von 386er bis vielleicht Pentium I. Mit 16 Stimmen ist so ein System schon mächtig ausgelastet - einem 386er würde ich z.B. 16 Stimmen, 44,1 Khz Stereo 16bit nicht zumuten wollen... Das geht in die Hose... Und selbst wenn er das gerade so schaffen würde: Ein Spiel mit Grafik und Sprites könnte da keinesfalls gleichzeitig mitlaufen...
Die 16 Stimmen bei ISM sind bei mir ehrlich gesagt nur angelegt worden, um etwas "Luft nach oben" zu haben - normalerweise halte ich 3- bis 4-stimmige Musik und MAXIMAL 4 Stimmen für Soundeffekte für mehr als ausreichend. Also eher so 4 bis 6 Stimmen, die "gleichzeitig etwas tun" statt 16. (Zum Glück verbrauchen ausgeschaltete Stimmen bei ISM quasi keine meßbare Performance.)
Aber das ist natürlich nur meine persönliche Meinung.
Ich fände es halt nur etwas "lame", ein "DOS-artiges" 2D-Spiel zu machen, das dann eine 500 MHz-Maschine braucht, um überhaupt vernünftig spielbar zu sein.
zatzen hat geschrieben:So wäre mehrkanälige Sprachausgabe möglich, also dass zwei oder drei Leute gleichzeitig reden oder sich ins Wort fallen etc.
Klingt natürlich interessant. Nur muß irgendwer natürlich das Spiel dazu schreiben. Und nicht zu vergessen bräuchte man dann auch 3 verschiedene Leute, die Zeit, Lust und Talent haben, die ganzen Texte einzusprechen. Und vielleicht ein gescheites Soundequipment, um das Ganze mit einigermaßen gescheiter Qualität aufzunehmen und zu entrauschen usw. (Aber wie ich Dich einschätze, zatzen, hast Du, als Soundprofi sicher entsprechendes Equipment da. Ich hab sowas z.B. nicht. Meine 2 Mikros hier sind der letzte Dreck - hatte schon lange mal überlegt, mir mal ein wenigstens ETWAS besseres zu holen...)
zatzen hat geschrieben:Es müssen dann nur entsprechend mehr Daten geladen werden, d.h. z.B. 768 oder 1152 Byte - wobei hier jeweils wahrscheinlich die meiste Zeit für das "seeken" und nicht für das Laden selbst draufgeht.
Da gäbe es eine Menge "Tricks", um so etwas quasi "im Vorfeld" zu erledigen... Und, sobald es Sprachausgabe werden soll, denke ich, sollte man dem User/Player - wenigstens optional - die Nutzung von XMS zugestehen.

Wenn er kein/zu wenig XMS hat, kann ja immer noch die Festplatte benutzt werden. Auch so "Cluster-artiges" ein-/ausblenden von Teilen aus dem XMS wäre möglich. Sowas erlaube ich z.B. für meine Grafiken. Die erkennen selbst, ob sie gerade auf einen "ausgeblendeten" Teil zugreifen wollen, blenden den dann ein und entfernen dafür den letzten am wenisten benutzten... - und vor einer Weile habe ich mal gelesen, daß so ähnlich auch das Speichermanagement unter Windows funktioniert - mit freundlicher Unterstützung des Protected Mode natürlich...
zatzen hat geschrieben:Naja die Idee von mehrkanäliger Sprachausgabe kann z.B. einfach darauf abzielen, dass nicht nur wie in einem Adventure ein sauberer getrennter Dialog stattfindet, sondern auch in einem 2D Platformer die Charaktere etwas sagen, und zwar wann sie wollen - so ähnlich wie mit Soundeffekten, nur mit Sprache, die man aber eben nicht auf dem Heap unterbringen kann.
Ja, ich weiß. Dir schwebt immer noch diese Idee des "Pseudo-Spiels" der "Figuren mit teilweise eigenem Willen" vor. Die Idee ist an sich nett. Nur ich weiß nicht, ob Systeme mit 30-150 MHz CPU und ca. 600 kB Heap mit so etwas eventuell überfordert wären. Vielleicht - nur so eine doofe Idee von mir - erst einmal einen kleinen "normalen" 2D Platformer bauen und wenn der funktioniert, kann man da immer noch gewaltig dran "ausrasten"/"ausufern" mit dem Speicher und CPU-Zeit, die dann noch übrig sind... - Die Grenze ist das Universum...
zatzen hat geschrieben:Allerdings bin ich ein gebranntes Kind was experimentieren mit DMA-Aktionen angeht. Ich habe früher einmal versucht, per Soundblaster Musik abzuspielen und gleichzeitig aufzunehmen. Als Ergebnis waren alle Dateien auf meiner Festplatte nicht mehr lesbar die größer als eine Zuordnungseinheit waren.
Ja, allerdings liegt das an besch[eiden]er Programmierung und weniger an der Sache an sich. Ich nehme an, daß hier jemand aus Performancegründen nicht mit Dateien gearbeitet hat, sondern mit direkten Festplatten-Sektorenzugriffen. Das ist zwar sehr viel performanter... ABER! - Es ist eben auch sehr gefährlich, "am Dateisystem vorbei" zu arbeiten - da muß man schon GANZ GENAU wissen, was man tut!
Und, übrigens: Auch so eine Festplatte wäre noch zu retten gewesen. Die Dateien hätte man sicher flicken können. Es gibt Programme für sowas (kann CHKDSK sowas nicht auch?) - und notfalls geht es auch "von Hand". Ich habe auch selbst schonmal überlegt, mich etwas mit FAT zu beschäftigen, um so ein "Retterprogramm" zu bauen. Aber ich komme ja so schon kaum noch zu etwas...
zatzen hat geschrieben:Deshalb möchte ich meine Idee hier zur Diskussion stellen, möchte von Euch wissen ob Ihr das für vernünftig haltet, oder ob es ein No-Go ist, immer wieder über längere Zeit von der Festplatte zu lesen (also ein DMA Transfer) während gleichzeitig ständig ein anderer DMA Transfer (Soundblaster) läuft.
Soweit ich weiß, ist gleichzeitiges Lesen und Schreiben von Sounddaten nicht verboten und die Soundkarte bietet so etwas glaube ich sogar an (weiß nicht genau). Man darf nur nicht (GANZ GANZ WICHTIG!) in denselben Bereich schreiben, aus dem man gerade liest!
Und: Aus Performancegründen sind auf PCs Speicherzugriffe etwas komisch gelöst - sicher schon von diesen L1- / L2- Memory Caches gehört... Manches, was man so liest/schreibt, steht gar nicht wirklich im RAM... jedenfalls nicht in "DEM" RAM, wo man denkt... Heutige ("moderne") Rechner haben Speichercaches, die sind größer als der ganze Heap - wenn auf denen ein DOS-Programm ohne XMS-Zugriffe läuft, wird glaube ich, nicht ein einziges Mal wirklich auf die RAM-Riegel zugegriffen, sondern erst, wenn es beendet ist...
Ich weiß nicht, ob das vielleicht ein Problem ist.

Achja: Und die Soundkarte schreibt ja NICHT auf die Festplatte und liest auch NICHT von dort. Es geht immer über den Speicher. D.h. das Aufnehmen/Abspielen an sich macht keine Festplattenzugriffe - das muß das Programm schon selbst machen. Und hier hat wohl eher das Programm Mist gebaut - die Soundkarte ist unschuldig.
zatzen hat geschrieben:In meinem ZSM Player habe ich bis jetzt alle Festplattenzugriffe vermieden, solange die Soundausgabe läuft.
Wäre nicht nötig. (Und bei Lesezugriffen schon gar nicht.) Allerdings könnten die Zugriffe natürlich im Sound "stören", wenn sie zu lange dauern.
zatzen hat geschrieben:Aber ich habe Ende der 90er schonmal einen FLI-Player geschrieben, genauer gesagt "FLS", nämlich FLI mit Sound, der bedeutend mehr Daten pro Frame von der Festplatte gelesen hat und Bild + Ton ausgegeben hat, als bei dem was ich mir oben überlegt habe.
Also scheint es doch zu funktionieren. Vielleicht hatte auch das Dateisystem der obengenannten "kaputten" Festplatte sowieso schon einen Treffer...
zatzen hat geschrieben:Also zusammenfassend:
Ich möchte XMS Nutzung lieber vermeiden, und dort ist die Sprachausgabe bei 11025 Byte/s Datendurchsatz und sagen wir mal 4 MB XMS auf 6 Minuten beschränkt. Man könnte natürlich das Spiel in Abschnitte unterteilen wo man eine Ladepause einlegt, aber wenn das mit dem mehr oder weniger permanenten Festplattenzugriff okay wäre hätte man mehr Freiheiten.
Naja, hier könnte man natürlich auch den Umstand berücksichtigen, daß ja quasi NIE die komplette Zeit gelabert wird und das Nachladen anderer Sprachsamples in den Sprechpausen erledigen, oder?
zatzen hat geschrieben:Ich meine übrigens bei Duke Nukem 3D beobachtet zu haben, dass es dort auch die ganze Zeit über Festplattenaktivität gibt. Vermutlich sogar für den Sound, denn die Engine gibt einem da scheinbar keine Grenzen vor (wir haben das nach Lust und Laune modifiziert und hatten unseren Spaß).
Naja, Duke Nukem 3D läuft ja auch im Protected Mode und das ist ja schon einmal von vornherein eine ganz andere Liga! Der Protected Mode kann einem viel von der Arbeit abnehmen, die man bei RealMode oder PseudoRealMode (also VM86) selbst berücksichtigen müßte. Andererseits muß bei der Programmierung in PM natürlich dann wieder vieles anderes beachtet werden. Diese 32bit-DOS-Extender wie DOS4GW, PMODE und wie sie alle heißen, können dabei aber eine große Hilfe sein. (Anm.: Ich selbst habe noch nie in PM programmiert, noch nicht einmal selbst in den PM geschaltet und auch noch keine der o.g. Extender benutzt. Dazu wäre von mir also keine Hilfe zu erwarten.)
zatzen hat geschrieben:Klar könnte man angesichts der Idee mit der Sprachausgabe auch den ZSM Musikplayer anzweifeln und sich denken, streamen wir einfach die Musik als 22 oder 44 kHz 4 Bit Delta. Das würde sich u.U. positiv auf die Performance auswirken und lediglich mehr Platz auf der Festplatte fordern, und sogar mehr Platz im Speicher für die Grafik lassen. Soetwas hatte ich sogar früher schonmal entworfen, ein System bei dem ich Musikstücke in Teile geschnitten habe, um sie beliebig arrangieren zu können, allerdings für XMS gedacht. Man hätte so auch die Möglichkeit, die Musik richtig zu produzieren und abzumischen, und man würde Aliasing vermeiden können, das durch das rohe Pitchen der Samples entsteht.
Der Möglichkeiten gibt es ja viele - und worauf man das Hauptaugenmerk legt, hängt auch von den persönlichen Präferenzen ab. Die Verwendung von "Teilstücken" - egal ob für Grafik, Levels, Sprites, Sound, Steuerung oder wasauchimmer - ist, meiner bescheidenen Meinung nach, sowieso der beste Ansatz, wenn man ein Spiel im RealMode/VM86 schreiben will. Anders kann man kaum "größere Projekte" erzeugen. Alles gleichzeitig im Speicher zu halten ohne Nachzuladen oder Auszulagern geht natürlich auch - aber dann muß man eben mit gewissen Einschränkungen leben.
zatzen hat geschrieben:Aber irgendwie hat die Geschichte gezeigt, dass es für Sprachausgabe legitim war, mal eben 300 MB zu beanspruchen, während die Musik aber AdLib war, und sich der Rest der Spieles inklusive aller Grafik mit 20 MB begnügte.
Ja, wobei ich (vielleicht im Gegensatz zu anderen) nicht unbedingt der Typ bin, quasi ein komplettes Spiel nur auf den Sound auszulegen. Und: Bei DOTT (und auch anderen Spielen mit Sprachausgabe) war es so, daß diese Sprachausgabe quasi "nachgebaut" war, d.h. das ursprüngliche Spiel existierte ohne Sprachausgabe und diese wurde quasi später hinzugefügt und funktionierte mehr oder weniger (fast) "unabhängig" vom restlichen Programm.
zatzen hat geschrieben:Die Musik war wohl auch AdLib, damit so ein Spiel überhaupt auf eine CD-ROM passte, andererseits bei LucasArts aber auch begründet durch iMuse, ein System was von einem Musikstück zum anderen moduliert, was man nicht so einfach durch Überblenden oder einen Schnitt mit vorproduzierter Musik hinbekommt.
Naja. wenn man eine komplette CD zur Verfügung hat und ein 200 MB Sprachausgabe-File drauflegt, wäre auch noch genügend Platz gewesen für ein paar MOD-artige Musiken (mit Samples statt AdLib-Sound). Es war eben nur nicht so programmiert worden.

Das Gute an den alten Lucasfilm Games/Lucas Arts Spielen war ja, daß viele davon auch auf relativ schwacher Hardware mit spärlicher Ausstattung immer noch liefen. DARAN SOLLTE MAN SICH EIN BEISPIEL NEHMEN!
Das heißt: Die eigentliche "Message", die ICH aus der Betrachtung von Lucas-Spielen mitnehme ist NICHT: "man kann ja auch ruhig mal 200 Megabyte verbrauchen", sondern: "läuft auch noch vernünftig auf 'nem 286er".

Und ja: Mein programmiertes Zeug braucht 386er und selbst da performt es nicht besonders. Das heißt für mich aber NICHT "Rechner zu langsam", sondern "Programmierer zu schlecht". 386er-Voraussetzung finde ich an sich OK - aber eben dann, wenn man durch die freiwerdenden Möglichkeiten - mehr Segmentregister, mehr Registerbreite, andere Speicherzugriffe - auch wirklich bessere Software macht. Und, auch wenn manche der heutigen "coolen Kids" es vielleicht anders sehen mögen: Performance IST ein Software-Qualitätskriterium - Punkt!
zatzen hat geschrieben:Wenn ich Musik mit 44.1 kHz streamen würde, also 22050 Byte/s Datendurchsatz, wären das für 5 Minuten rund 6 MB, für 10 Musikstücke dieser Länge entsprechend 60 MB. Das könnte man noch gutheißen, wenn die Sprachausgabe ähnlich oder mehr verbraucht.
Ja, und es klänge auch "besser", weil man quasi "richtigen Sound" statt "Midi"/"Mod" benutzen könnte - allerdings wäre es natürlich auch - programmiererisch - eindeutig weniger cool. Und, wie man an MPXplay ja sieht, wäre es sogar möglich, unter DOS die Musiken als MP3 einzubinden und abzuspielen - oder meinetwegen MP2, wenn man auch auf langsamen Kisten noch etwas Power für's restliche Spiel übriglassen will... (Naja, die Soundeffekte müßte man natürlich trotzdem extra dazumischen...)
Aber wenn man das will, kann man auch gleich bei der Grafik weitermachen: Truecolor-Fotos als Vorlagen für die Grafikteile nutzen und das Ganze im 16,7 Mio-Farben Modus, hochauflösend... - Aber damit bewegt man sich - sowohl sound- als auch grafiktechnisch - lange nicht mehr in den Regionen von eigentlichen "DOS-Rechnern".

Und es gibt unzählige Beispiele, wo Leute mit "modernen Game-Makern" Spiele bauen, die 16 Mio Farben und 48 kHz Stereosound voraussetzen, sowie Speicher im GB-Bereich und CPUs im GHz-Bereich und die Spiele selbst können nicht einmal mit Sachen mithalten, die damals auf dem C64 liefen, weil von den 16 Mio Farben vielleicht 30 benutzt werden, weil die hohe Auflösung zustande kommt, weil man handgemurkste Grafiken "antialiased" verschwommen "aufbläst" und weil der Sound irgendwelche geklauten Musiken von anderen Spielen sind. Und diese Game-Maker-Spiele sehen irgendwie alle gleich aus - selbst die Grafiken sind schon von irgendwo importiert. Vielleicht ist das Ergebnis zufriedenstellend - aber quasi NICHTS daran ist selbst programmiert - maximal vielleicht ein wenig "geskriptet"... Kann man machen - aber für mich wär' das nix. Ich bin Programmierer. Ein bescheidener, schäbiger zwar - aber ich habe auch trotzdem noch ein wenig Würde... Also, um es mit Rüdiger zu sagen: Kann man machen, muß man aber nich...
zatzen hat geschrieben:Naja, ich denke da muss man sich überlegen in welcher Liga man spielen möchte.
Genau das wollte ich damit sagen (siehe voriger Absatz).
Ginge es mir ausschließlich um irgendein wie auch immer hingeschlunztes "fertiges Produkt", hätte ich mir schon lange den nächstbesten Game-Maker geschnappt, was zusammengeschustert und es ins Netz gestellt.

Ich sags mal so: Ich habe vor einer Weile mal einen Platformer gesehen - an sich nett, macht auch irgendwie Spaß - aber der enthält: (Ja. ich kann Programme schreiben, die die Daten aus anderen Programmen herauskratzen und einzeln speichern können...) Die Grafiken als mehrere 32bit (24bit mit Alphakanal) 2048x2048-Bilder, Sound als riesige ungepackte 44kHz 16bit WAVs, sogar die Fonts sind in obengenannten großen 32bit-Grafiken gespeichert und dabei sehen sie aus wie monospaced-Schreibmaschinenschrift... Das Spiel hat irgendwas um die 20 Levels oder so. Es braucht 65,3 MB.
Das ganze Spiel läuft nur auf meiner schnellsten Windows-Maschine ruckelfrei, auf der der zweitschnellsten mit starkem Ruckeln (und ewig langer Ladezeit am Anfang) und auf den anderen Win-Kisten startet es nicht mal. Und es ist ein 2D-Jump'n'run ohne Scrolling (also mit fixed screens). Die Grafik nutzt meines Erachtens nicht einmal insgesamt 256 Farben.

Ich weiß, daß ich sehr vieles nicht perfekt mache und vieles von meinem Zeug bescheiden performt (allerdings ist z.B. die letzte Version von Xpyderz auch schon 10 Jahre alt, inzwischen habe ich einiges dazugelernt). ABER: In so eine Kategorie wie o.g. möchte ich als "Spieleentwickler" niemals fallen - da würde ich lieber komplett damit aufhören, Spiele zu entwickeln. - Kann jeder anders sehen, aber wenn ICH das o.g. programmieren würde (mit meinen derzeitigen bescheidenen Fähigkeiten), würde es maximal ein Zehntel des Speichers und weniger als ein hundertstel der Rechenleistung brauchen.
zatzen hat geschrieben:Wenn ich den ZSM-Musikplayer weglasse und stattdessen die Musik streame, werde
ich wohl eher dazu tendieren, für die Grafik auch XMS zu benutzen und das ganze etwas ausladender aufzuziehen. Es wäre dann auch interessant, in der Qualität weiter nach oben zu gehen, Stereo und 16 Bit, allerdings immer noch basierend auf 4 Bit Delta.
Natürlich muß man hierbei immer bedenken, daß man mit XMS zwar an sich mehr Speicher hat - jedoch nie "gleichzeitig". Gleichzeitig ist weiterhin nur das vorhanden, was in die unteren 600+x kByte hineinpaßt. Ein extremes "Flippen" von Grafik/Sound zwischen XMS und Heap wird wohl nicht wirklich etwas bringen - hier muß man sich ein intelligentes System zum dynamischen "Auslagern" einfallen lassen.
zatzen hat geschrieben:Benutze ich aber den ZSM-Musikplayer so wie er bisher steht, dann werde ich wohl
nur der Sprachausgabe eine Sonderrolle zukommen lassen - und darum geht's in diesem Thema ja eigentlich nur, ob ein Streamen von kleinen Dateneinheiten von der Festplatte technisch unbedenklich wäre, auch wenn das am Ende vielleicht 20x in der Sekunde passiert.
Naja, 20 Festplattenzugriffe pro Sekunde wäre glaube ich eine schlechte Idee. Dann würde außer Festplattenzugriffen quasi fast gar nichts anderes mehr passieren... Dann lieber etwas "vorladen" (in einen größeren Temp-Puffer) und dafür seltener zugreifen. Lustiger Fakt: Bei 20 Festplattenzugriffen in der Sekunde hätte man ja quasi schon einen hörbaren "Brummton"... (Weil 20 Hz so die Untergrenze des menschlichen Gehörs ist.)

Achja - ganz am Schluß noch ein kleiner Off-Topic Hinweis:
Vielleicht mal einen kurzen Blick in meinen "Nicht-Tracker prISM" Thread werfen. Da ist etwas Neues, möglicherweise interessantes drin.
(Ja - es ist Sommer. Es ist warm. In letzter Zeit gibt es wenig Beiträge. Mit sehr viel Interesse hatte ich also ohnehin nicht gerechnet - mit Null aber auch nicht, zumal es eventuell ein "Problem" lösen könnte.)

Re: Trackermodul-Engine (sehr einfach)

Verfasst: Mo 30. Jul 2018, 17:21
von zatzen
Danke für die Antwort!
Freut mich sehr!

Ja, es ist sehr warm, und zudem befinde ich mich momentan mal wieder mehr im Real Life,
Lautsprecher bauen, Musik bearbeiten / machen.
Deswegen wird mein Versprechen mit den nächsten ZSMs und der nächsten Programmversion
auch noch etwas hinausgeschoben.
Sind bis jetzt aber schon einige sehr schöne Stücke dabei, die technisch teils auch sehr interessant sind.

Dass Du eine Tracker GUI für ISM geschrieben hast ist doch großartig, zumindest für mich.
Ich habe mich die letzten Jahre bloß eher beim Komponieren auf Samples gestützt, die
schon wechselnde Harmonien oder Melodien vorgeben, und ich musste nur noch dazu
improvisieren. Muss ich mal sehen ob ich auch etwas "from scratch" hinbekomme, aber das
wird schon gehen.

Zu meiner Überlegung würde ich schlussfolgern, dass ich das mit den Festplattenzugriffen
lieber lasse und stattdessen die Sounddaten aus dem XMS hole. D.h. Sprachausgabe optional über XMS.
Und wie Du schon meintest, ist es für uns als Programmierer einfach schöner, wenn das
Programm etwas intelligenter strukturiert ist und man nicht einfach alle Daten grob
reinstreamt. Heißt, ich werde ZSM nutzen.
Die ZSM Engine kann mehr als 16 Kanäle, allerdings habe ich den 16 Bit Puffer so optimiert
dass er optimal ausgenutzt wird bei 16 Kanälen, d.h. bei mehr als 16 Kanälen könnte es
Überlaufe geben, auch aber nur wenn auf allen Kanälen gerade die volle Sample-
Präsenz und -Lautstärke herrscht. Trotzdem würde ich, auch der Performance wegen,
die Musik vielleicht auf 8 Kanäle beschränken und die Soundeffekte ebenfalls.
Letztere kann man von außen triggern, unabhängig von der Musik, ja.

Meine Programmierfähigkeiten entziehen sich derzeit noch des Könnens und des
Verständnisses, um die Ticker so zu gestalten wie Du es in XPYDERZ machst.
Ich bin erstmal überhaupt froh, eine performante Sache mit simplem "warten auf
Tonpuffer abgespielt" bzw. "ist die Dauer eines Frames rum?" hinbekommen zu haben.
Du hast mir schon oft genug gesagt dass das ein No-Go ist, allerdings sagtest Du
mir auch, wenn ich mich recht erinnere, dass der Ton so wie Du es machst bis zu
200 ms hinterherhinken kann, und das wäre für mich ein No-Go.
Ich weiss auch nicht ob ich so weit in die Programmier-Materie einsteigen will,
letztlich habe ich mir mit dem ZSM Player ersteinmal einen kleinen Jugendtraum
erfüllt, und das Ding funktioniert so wie es ist ja erstmal gut und die Anzeigen
sind mit dem Ton schön synchron.
Ich hatte ja schon einen Test gemacht mit relativ viel Grafik, und das lief auf
niedrigem 486er Niveau auch noch ganz rund bzw. ohne jegliche Hänger.
Wenn der User den Ton abschaltet bzw. keinen Soundblaster hat, würde ich das
Timing über den Timer realisieren.
Ich gehe eben plump davon aus, dass innerhalb einer Frame-Dauer alles berechnet
sein muss, und es wäre mir weitaus zu kompliziert, irgendwie fehlende Rechenkapazität
bzw. deren Auswirkung gleichmäßig auf die Erscheinung des Spiel zu verteilen.

Also alles zu seiner Zeit... Kotzman II war von der Rechenzeit so anspruchslos
dass ich mit diesem Format sehr gut gefahren bin, ich habe sogar einfach eine Warteschleife
genutzt um das Spiel zu bremsen, d.h. die eigentliche Rechenzeit für die Grafik und alles andere
war vernachlässigbar.
Deswegen wäre der nächste logische Schritt für mich ersteinmal, die übrige Rechenkapazität
nicht in einer Schleife zu verbraten sondern dem Spiel die Rechenleistung komplett
zu geben und eben per Timer oder warten auf Soundpufferwechsel die Framerate zu kontrollieren.
Natürlich nutzt man damit die Rechenkapazizät nicht optimal, das Spiel läuft mit einer festen
Framerate und nicht mit so viel wie der Rechner maximal schafft, und durch die fixe Framerate
scheiden dann leider auch manche langsamen Computer aus.
Das mag Dir ein Dorn im Auge sein, da Du ja immer versuchst so optimal zu programmieren wie möglich.
Aber ich würde in diesem Fall eine Ausnahme machen, mit meinem Können das mir vertraut ist etwas
anfangen, das immerhin besser ist als das was ich 1995 gemacht habe. Es ist dann nicht 100% optimal
programmiert aber würde dennoch ein sehenswertes Ergebnis hervorbringen.


Wäre mir das heute passiert mit der Festplatte hätte ich sie wohl retten können.
Aber 1994, ohne Internet, noch wenig Erfahrung mit Computern, hatte ich keinen Plan.
Ende der 90er mit dem FLI+Sound Player, das war ein anderer Computer (Pentium 200MMX),
und mit dem hatte ich nie Probleme bis er sich vor ein paar Jahren verarbschiedete.
Seitdem nutze ich Dosbox.

Spiel auf Sound auslegen:
Ich hatte sogar schonmal die Idee ein Text-Adventure zu machen mit Ton...

Du hast mehr geschrieben als ich im Moment verstehen kann.
Aber das Forum hier bewahrt die Einträge und so können sie für die Zukunft viel wert sein.
Ich bin mit der gesamten komplexen Materie bis ins Detail längst nicht so vertraut wie Du,
und daher werden auf absehbare Zeit auch meine Programme nicht perfekt zugeschnitten auf
ein entsprechendes Computersystem sein. Es macht mir aber Spaß wenigstens ein bisschen
intelligent zu programmieren, indem ich doch ein wenig von der Rechnerarchitektur verstanden
habe und so mit Assembler in Verbindung mit Pascal heute deutlich bessere Ergebnisse erziele
also damals mit bloßem QuickBasic.

Wie auch immer, ich bin aufgewachsen mit Nintendo NES, also dem ersten sozusagen, da war die
Grafik ja wie man's kennt eher bescheiden, wobei gleichzeitig die Geschwindigkeit der ganzen
Sache noch etwas ist, das ich derzeit noch nicht erreichen würde.
Schliesslich kam bald aber der PC, das war so um 1989, und da gab es beispielsweise Spiele
wie Captain Comic. Ich greife das nur mal heraus weil es im Grunde für ein "Arcade" Spiel
sehr unübliche Parameter hat: Framerate von 10 fps, Scrolling in 8 Pixel-Einheiten.
Trotzdem war es spielbar.
Für ein eigenes Spiel würde ich nicht zu viel Zeugs auffahren wollen, dafür aber auf etwas
gehobenerem Level. Scrolling möchte ich nicht - weiches Scrolling entzieht sich wieder meinen
Fähigkeiten. Also eher sowas wie ein Level-Platformer wie Donkey Kong, Mario Bros (ohne Super).
Aber mit 256 Farben Grafik, transparenten Sprites, schönen Hintergründen und schöner Musik.
Wäre eine Idee. Oder, vielleicht letztlich doch faszinierender, ein Dungeon-ähnliches Spiel,
wo man überall hin laufen kan, und es wird von Screen zu Screen "geblättert", ähnlich wie
bei Kotzman II.
Du merkst vielleicht schon, dass ich bei der Grafik schon direkt schon eine Hemmnis habe,
dass diese nicht zu viel Rechenzeit in Anspruch nimmt.

Vom "schnell zum fertigen Produkt, Hauptsache schnell und es sieht gut aus" bin ich aber auch
weit entfernt. Für mich zählt der Weg dorthin, dass ich weiss was hinter den Kulissen passiert.