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:
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
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:
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.
?