Nicht-Tracker prISM

Nicht-Tracker prISM

Beitragvon DOSferatu » Sa 29. Okt 2016, 13:05

So.
Ich habe nun mein ISM (Imperial Games Sound Machine) soweit "fertig", daß es benutzbar ist. Es gibt nur noch 2 Baustellen, eine kurzfristiger, eine längerfristiger geplant:

1) Die Filter-Befehle tun noch nichts. Einsetzen der Klang-Filter (Treble, Band, Bass) bewirkt derzeit gar nichts. Die Dokumentation dazu ist derzeit als vorläufig zu betrachten, weil es im Zuge der Programmierung hier noch zu Änderungen kommen kann.

2) Die Stereo-Option tut auch nichts. Stereo ist erst längerfristig geplant - wahrscheinlich werde ich es so gestalten, daß es eine Subroutine gibt, die nur Mono kann und eine, die Mono und Stereo kann. Beide werden vollständig kompatibel zueinander sein, aber die mit Stereo-Option wird evtl. mehr Rechenleistung und ggf. zusätzliche 8 kB Speicher brauchen.

Der dazugehörige Nicht-Tracker heißt prISM. Ich habe einfach etwas gesucht, das kurz ist, gut klingt, und (weil die Unit ISM heißt) zu den praktischerweise im Englischen haufenweise existierenden Wörtern gehört, die auf -ism enden. Man kann es auch verstehen als eine Abkürzung zu [pr]ogramming [ISM].

Dieser Nicht-Tracker ist soweit fertig. Ob ich jemals die Import/Export Funktionen noch einbaue, steht in den Sternen. Je mehr Code im Heap ist, umso weniger Platz bleibt für Samples frei. Momentan habe ich etwas über 300 kB frei für Samples. Da meine Samples 4-bit gespeichert werden, ergibt das 600 kB Samplespeicher. Bei der geringen Qualität, die ISM im Allgemeinen zu erzeugen imstande ist, sollte das ausreichen.

Wieso ist prISM ein Nicht-Tracker?
Das Format, in dem die Musikdaten eingegeben und abgespielt werden, entspricht in keiner Weise dem MOD-Format oder dessen unzähligen Derivaten.

Daten für die einzelnen Stimmen werden unabhängig voneinander eingegeben. Die Geschwindigkeit und andere Werte einzelner Stimmen ist beliebig einstellbar. In einer Stimme können Sprünge und Schleifen enthalten sein, die in anderen nicht benutzt werden. Außerdem können die Daten einer Stimme auch von anderen Stimmen benutzt werden, da die kompletten Daten als "Befehlsblock" vorliegen, für eine Stimme wird lediglich bestimmt, an welcher Stelle im Datenblock die Stimme beginnt zu arbeiten.

Dinge wie bedingte Sprünge, Unterprogrammaufrufe, Variablen und Stack erinnern hier mehr an ein Programm als an gewohnte Trackerdaten.

prISM erleichtert das Ganze aber ein wenig, indem es "Fenster" vorgibt, in denen die Befehle der einzelnen Stimmen eingegeben werden können. Die Startadressen der Stimmen sind auf ganze $200 (512) Words defaulted, dies entspricht der Größe für die Fenster, die ebenfalls jeweils $200 (512) Befehle aufnehmen können. Diese Anzahl wollte ich noch in 2er Potenzen einstellbar machen, aber momentan ist es erst einmal so. Die Stimmen-Startadressen können aber manuell geändert werden.

Die Anzeige der Werte kann hexadezimal oder dezimal erfolgen, die Befehle können in 4 Modi farblich hervorgehoben werden.

Abgesehen von den Befehlen mit einer Abspiellänge (die Töne selbst, dann noch Portamento =bending/binding, Ausklingen und Stille) gibt es noch viele Befehle, die keine Abspiellänge haben, sondern eher der Steuerung dienen. Somit wird es etwas schwieriger, wenn man wirklich "Tracker-artig" die Stimmen (also die einzelnen Spuren) nebeneinander "synchronisiert" darstellen will. Dies könnte man nur erreichen, indem man die Zwischenräume zwischen den Befehlen notfalls mit "NOP"s auffüllt (Befehle, die nichts tun).

Das, was in MODs durch entsprechend große Zwischenräume zwischen den Ton-Befehlen erreicht wird, nämlich deren Abspiellänge festzulegen, geschieht in ISM (und damit prISM) durch Längenparameter.

ISM unterstützt auch eine quasi-direkte Kommunikation zwischen dem Hauptprogramm und der ISM-Subroutine, d.h. das Senden von Werten über Puffer zwischen den Programm und ISM.

Eine weitere Besonderheit ist, daß Samples in ISM nur als "Beilage" unterstützt werden - die eigentliche "Stärke" bzw. das Hauptmerk wurde auf digitale Klangsynthese gelegt. Wer die Einstellungen für die Stimmen für Hüllkurven (Attack/Decay/Sustain/Release), und mischbare Wellenformen sieht. wird nicht überrascht sein, zu erkennen, daß das Ganze von der Arbeitsweise des SID (Sound Interface Device, der bekannte Soundchip, der z.B. im C64 verbaut ist) inspiriert ist - wenn auch in abgewandelter Form.

Eine weitere Schwäche oder Stärke (je nachdem, von welcher Seite aus man es betrachtet) ist die Arbeitsweise mit den Samples:
Speicher ist knapp, Samples brauchen viel Speicher. Im RealMode kann man keine Samples "live" abspielen, wenn sie sich im Adreßraum über 1 MB befinden. Dies brachte mich dazu, Samples "dynamisch" einsetzbar zu machen - und zwar direkt durch den Autor/Komponisten der Musikstücke. Somit können Samples "ein-/ausgeblendet" werden, je nachdem, ob sie gerade gebraucht werden oder nicht.

Nun zur Schwäche:
Samples werden numeriert erkannt/geladen. Deshalb müssen Samples immer einen Namen wie z.B. SAMPLE??.SMP haben, wobei ?? für eine hexadezimale Nummer $00 bis $FE steht. Möglich ist auch ein ganzer Pfad wie D:\SAMPLES\S??.SMP

prISM speichert generierte Stücke zusammen mit den genutzten Samples ab, aber beim Laden werden (derzeit) die Samples NICHT mit geladen. Die Samples müssen sich im selben Verzeichnis wie prISM befinden und SAMPLE00.SMP bis SAMPLEFE.SMP heißen und diese werden während des Abspielens geladen (durch die entsprechenden Befehle).

Das bedeutet, daß es derzeit (noch) nicht ohne weiteres möglich ist, ein Musikstück mit Samples "weiterzugeben" um es in einem anderen prISM abzuspielen, ohne die Samples weiterzugeben.(Dazu müßten diese manuell vom *.ISM File abgetrennt und als SAMPLE??.SMP gespeichert werden.) Dies ist der obengenannten Arbeitsweise von ISM geschuldet.

Der Plan sieht aber vor, daß prISM (vielleicht) später die Samples in ein separates Verzeichnis oder den XMS puffert. Außerdem wird es vielleicht noch ein zusätzliches kleines Programm geben, das nichts weiter tut außer ein *.ISM-File (inklusive Samples) abzuspielen.

Zusätzlich zu prISM gibt es das Tool SNDCHECK, das dazu dient, WAVs in ISM-formatige Samples umzuwandeln - Hauptsächlich wichtig ist dabei die Option, dem Sample den "Grundton" zuzuweisen, d.h. den "hauptsächlichen Ton", den man hört, wenn das Sample gespielt wird.
(Dient dazu, das Sample in ISM entsprechend zu "pitchen", wenn es in verschiedenen Tonhöhen abgespielt werden soll.)
Dieses Tool ist derzeit nur für PC-Speaker ausgelegt.

Ja, das Ganze sieht nicht gerade danach aus, was ein normaler "Tracker" (in diesem Sinne ein Musiker, der mit entsprechenden Programmen arbeitet) erwarten würde.

Der Hauptgrund für die derartige Gestaltung der Arbeitsweise von ISM ist deren geplanter Einsatz in Spielen.
Hier war mir vor allem wichtig, Speicher und Rechenzeit zu sparen, sowie eine möglichst einfach zu realisierende Kommunikation zwischen Programm und ISM zu ermöglichen. ISM ist nicht nur gedacht, um eine Hintergrundmusik abzuspielen, sondern auch dafür, Klangeffekte zu erzeugen - die natürlich abhängig vom Spielgeschehen ausgelöst werden sollten.

Technische Daten:
16 Stimmen
8-Bit Sound (mono, stereo geplant)
Sound gemischt aus 4-bit Ausgangswerten (Wellen, Samples)
8 Oktaven à 12 Halbtöne
(durch Transponieren bis zu 10 Oktaven nutzbar)
32 kByte (=16384 Befehle) maximal direkt ansprechbar
96 Bytes pro Stimme für die Werte
7 vorgegebene Wellenformen
(eigene Wellenformen nutzbar - aus Samples)
4-Bit Rauschgenerator mit 16 Bit Seed
8 Byte (4 Adressen) Stack pro Stimme
2 frei verfügbare Variablen/Register pro Stimme
(hauptsächlich für Schleifen)
Für prISM:
unterstützt PC-Speaker
unterstützt Sound Blaster[tm] (mit IRQ 2, 3, 5 oder 7 und DMA 0, 1 oder 3)
max. 16 "Stimmen"-Fenster
Bedienung mit Tastatur und Maus
Fenster schmal/breit und in 1-3 Reihen darstellbar
bis zu 7 Modes:
- Textmode 80x25 und 80x50,
- bis zu 5 Vesa-Grafik-Modes, als Pseudo-Textmode benutzt

Hinweis: Es kann möglich sein, daß bei Samples mit zu geringer oder hoher "Grundfrequenz" ISM mit Überlauf abstürzt. Da muß ich noch testen, wahrscheinlich werde ich diese Assembler-Sequenz in einem externen Testprogramm mal bruteforcen lassen.

Kurze Bedienung von prISM:
ALT gedrückt halten (oder mit Maus auf oberste Zeile fahren), dann die entsprechend rot markierte Taste drücken (oder in Leiste klicken) für die entsprechenden Menüs.
F1 = Hilfe zum markierten Befehl (kann unter Help auf deutsch umgestellt werden)
A bis Z, mit/ohne Shift = um die Befehle einzugeben.
A bis P, mit Ctrl = zum jeweiligen Fenster wechseln
TAB = zwischen den Fenstern wechseln
Ctrl+T = Startadresse des Fensters (der Stimme) eingeben.
Ctrl+Z = Startadresse des Fensters in "Tracks" eingeben.
Ctrl+Y = zu Zeile im Fenster wechseln.

Die komplette Bedienung zu erklären würde jetzt wohl zu weit führen. Learing-by-doing ist hier wohl die brauchbarere Methode.

Bis auf die Hilfen zu den Befehlen, die optional auch in deutsch verfügbar sind, ist das ganze prISM komplett in englisch.

So - nach all dem frage ich mich, ob es überhaupt Sinn macht, prISM jemandem anzutun. Es ist quasi benutzbar, allerdings außer von mir selbst noch von niemandem getestet - es besteht also noch Explosionsgefahr.
Soll ich dieses Ding wirklich hochladen und damit jedem erfahrenen Tracker-Musiker die Augen bluten lassen und dafür sorgen, daß er vor Entsetzen vom Glauben abfällt oder besteht eher kein Interesse daran, sich dieses Ding anzutun?
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon wobo » So 30. Okt 2016, 18:13

Ah - ein sachlich geschriebener, wohltuend strukturierter und sauber formulierter Fachbeitrag. Allein das hat in diesen turbulenten Forums-Zeiten schon gut getan.

Um Deine letzte Frage gleich vorweg zu nehmen: Ja, ich fürchte, Dein Tool "Imperial Games Sound Machine" wird leider nur ein inhouse-Produkt von Imperial Games bleiben. Ich fürchte der Ansatz, Musik aus Sicht eines Programmierers zu machen, dürfte zu speziell sein, um wirklich ein paar Kreative anzuziehen (ich wünsche Dir das natürlich!).

Was mich anbelangt, bin ich leider vollkommen untalentiert, was Töne anbelangt. Ich bin also darauf angewiesen, dass das Internet oder Zatzen Soundeffekte oder MOD-Files für mich zur Verfügung stellen. Und als Hobby-Programmierer gilt für mich "der Weg ist das Ziel" - ich möchte also vorrangig selber Programmieren und selber Verstehen und habe dementsprechend eigentlich eine API-Allergie und bin gegen die Verwendung jeden fremden Codes (Ich weiß, dass Du mich da verstehst :-)). Und ob und welches Ergebnis dann herauskommt, ist mir dann eigentlich schnurzpiepegal. Hauptsache, ich habe selbst herum gegurkt (Ok, das verstehst Du wahrscheinlich nicht ;-)).

Ich will damit sagen: Leider sehe ich für mich persönlich keinen Ansatz, Deine vielen interessanten Produkte (nicht nur ISM) zu nutzen. Ich bitte Dich aber, weiterhin von Deinen Projekten zu berichten. Auch würde mich interessieren, wie Dein ISM klingt. Super wäre, wenn Du z.B. mal ein Wav-Sample und eine ISM-Version mit entsprechendem ISM-Player irgendwo einmal zum Download anbieten würdest (gerne auch noch ein Beispiel über die Wellenform-Technik). Gerade etwas, was noch unter der Standard-Soundblaster- Qualität (8bit mono) ist, interessiert mich nämlich sehr,
wobo
DOS-Guru
 
Beiträge: 555
Registriert: So 17. Okt 2010, 13:40

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Mo 31. Okt 2016, 08:22

wobo hat geschrieben:Ah - ein sachlich geschriebener, wohltuend strukturierter und sauber formulierter Fachbeitrag.

Ich kann nichts dafür. Ich schreibe immer so. "Es ist eine Gabe - und ein Fluch..."[tm]

wobo hat geschrieben:Allein das hat in diesen turbulenten Forums-Zeiten schon gut getan.

Ja, mir ist aufgefallen, daß es hier in letzter Zeit etwas "laut" geworden ist. Früher[tm] hätte ich mich vielleicht an solchen Diskussionen noch beteiligt. Aber ich bin inzwischen zu alt dazu, das halten meine Nerven nicht mehr aus.

wobo hat geschrieben:Um Deine letzte Frage gleich vorweg zu nehmen: Ja, ich fürchte, Dein Tool "Imperial Games Sound Machine" wird leider nur ein inhouse-Produkt von Imperial Games bleiben. Ich fürchte der Ansatz, Musik aus Sicht eines Programmierers zu machen, dürfte zu speziell sein, um wirklich ein paar Kreative anzuziehen (ich wünsche Dir das natürlich!).


Zur Erklärung (ich habe es vielleicht schon an anderer Stelle angemerkt) :
Ich habe damals (auf C64) mit einem Musik-Maker (auch nicht wirklich "Tracker") gearbeitet, das da von einem Leser der 64'er geschrieben wurde und auf einer der Sonder-Disks herauskam. Dieser war auch lauflängen-basiert, wenn auch in der Umsetzung trotzdem etwas anders als ISM. Es gab auch so Sequenzer-Blöcke (aber einzeln für die Stimmen, nicht wie bei MOD für alle Stimmen gleichzeitig) und die Inhalte dieser Blöcke hatten auch keine feste Länge. Es gab aber keine "Leerräume", um die Abspiellänge der Noten festzulegen. Und es gab natürlich keine Samples, sondern "Instrumente", die aus den durch den SID verfügbaren Wertekombinationen in den Registern gebaut werden konnten. Alles war auf den SID - und natürlich auf geringen Speicherverbrauch - ausgelegt.

Samples, Leerräume... so etwas hätte sich damals[tm] auf einer Maschine mit 64kB RAM niemand erlaubt...

Und mir gefiel dieses Konzept. Für mein C64-Spiel "Rockus" (ein Jump'n'run, auf meiner Website in der C64-Sektion zu finden) habe ich die 9 Musiken mit diesem Tool gemacht.

wobo hat geschrieben:Was mich anbelangt, bin ich leider vollkommen untalentiert, was Töne anbelangt.

Ich leider auch. Ich kann wohl ein wenig herumbauen und nach einer Weile klingt es so wie eine Musik. Aber so richtige Meisterwerke bringe ich nicht zustande.

wobo hat geschrieben:Ich bin also darauf angewiesen, dass das Internet oder Zatzen Soundeffekte oder MOD-Files für mich zur Verfügung stellen.

Naja, da ich mein Zeug in Spielen verwenden will, die ich dann auch öffentlich mache (wenn auch als Freeware), werde ich natürlich keine bereits existierenden Musikstücke dafür benutzen, sondern etwas eigenes zurechtmurksen... -

Es sei denn, es würde sich ein talentierter Musiker finden, der Musiken speziell dafür macht... diese müßten natürlich schon irgendwie zum Spiel passen. Musik im Stil "verträumte Blumenwiese" paßt nicht zu einem Raumschiffshooter, "brutale Metalschlacht" paßt nicht zu einem Fantasy-Adventure... usw.


wobo hat geschrieben:Und als Hobby-Programmierer gilt für mich "der Weg ist das Ziel" - ich möchte also vorrangig selber Programmieren und selber Verstehen und habe dementsprechend eigentlich eine API-Allergie und bin gegen die Verwendung jeden fremden Codes (Ich weiß, dass Du mich da verstehst).

Ja, in der Tat.

wobo hat geschrieben:Und ob und welches Ergebnis dann herauskommt, ist mir dann eigentlich schnurzpiepegal. Hauptsache, ich habe selbst herum gegurkt (Ok, das verstehst Du wahrscheinlich nicht).

Ach, doch - das verstehe ich schon. Ich habe auch viele "Testprogramme" hier, die zwar interessant für einen Programmierer wären, aber bei der "breiten Masse" wahrscheinlich nur eine gerunzelte Stirn oder hochgezogene Augenbraue verursachen würden.

(Interessiert sich jemand für das 4-Farben-Problem? Braucht jemand ein Tool, um PCX/BMP Bilder in Textmode/ANSI zu wandeln? Braucht jemand ein Tool, um Reime zu finden? Oder ein Tool, mit dem man Programmcode für Warteschleifen auf µs genau bauen kann? ...)

Mir ist es zwar nicht völlig egal, was dabei herauskommt, wenn ich programmiere - denn langfristig (leider sehr, sehr langfristig, seufz...) ist der ganze Kram dazu gedacht, irgendwann mal wieder ein Spiel (oder mehrere) daraus zurechtzuzimmern.

Alles, was mir zum Bauen eines 2D-Spiels im Stile "Shoot'em'up" oder "Jump'n'run" oder sonstigem "Arcade"-Zeug bisher noch fehlte, war die klangliche Untermalung (Musik, SoundFX), um vollständige Spiele zu bauen - daher hatte ich mich nun endlich dazu durchgerungen, auch dieses Feld zu beackern.

Bei mir ist es also eigentlich dazu gedacht, Spiele zu machen - deshalb auch das "Games" in "Imperial Games". Aber inzwischen bin ich wohl leider wirklich zu einem Engine- und Tool- Macher verkommen... Ich könnte aus dem jetzigen "Material" sicher einen ganz brauchbaren "Game-Maker" machen.

Ich habe aber auch Spielideen, die jetzt schon Jahre/Jahrzehnte auf ihre Umsetzung warten. Diese sollte ich bald mal in Angriff nehmen.

Daß XPYDERZ (ein Spiel von mir) überhaupt mal "fertig" (bzw spielbar) wurde, lag nur daran, daß ich - entgegen meiner sonstigen Arbeitsweise - hier einfach "auf die kalte Maschine" programmiert habe, ohne Plan, ohne Vorbereitung. Sicher, so bekommt man auch Ergebnisse - aber ich habe während der Programmierung dieses Dings derart viel am Code ändern müssen und viele Dinge so "nachträglich angeflanscht" - teilweise doppelt vorhandenen Code, der das gleiche tut usw. usf. Den Programmcode davon möchte ich nicht mehr anfassen, das ist alles so "mit Heißluft zusammengetackert", daß es gerade mal so funktioniert. Es ist geradezu erstaunlich, daß es von außen noch einigermaßen vernünftig aussieht...

Bei kleinen Projekten mag so etwas gehen. Ich habe so viele selbstgebaute Units hier, die ich nur noch irgendwo einzusetzen brauche - ein kleines Tool ist dadurch manchmal in einer Stunde oder weniger fertig.

Aber XPYDERZ hat mich gelehrt, daß bei größeren Projekten eine Planung unumgänglich ist. Inzwischen habe ich die ganzen Dinge, die ein Spiel so braucht, derart "modular" gehalten, mit Schnittstellen, über die ein Hauptprogramm dann nur noch zwischen den Untersektionen (Grafikdarstellung, Klangausgabe, Spielfigurensteuerung, Menüsystem, interne Verwaltung (Laden/Speichern, Speicherverwaltung)) zu vermitteln braucht. Das ist nun endlich das, was eigentlich immer schon das Ziel war.

Ich bin (bedingt durch Job, ständige Müdigkeit u.ä.) leider weitaus weniger produktiv als noch vor 20 Jahren, als ich quasi jede freie Minute vor dem Rechner saß und programmierte. - Und daher hat es so lange gedauert, bis ich jetzt endlich an einem Punkt angelangt bin, alles zu haben, um ein Spiel zu machen. Ja, am Leveleditor fehlen vielleicht noch ein paar Kleinigkeiten, an ISM sind die Software-Klangfilter und Stereo noch nicht vorhanden - aber das sind Dinge, die auch noch nachträglich, abwärtskompatibel eingebaut werden können.

Durch die schlechten Erfahrungen, die ich mit Spaghetticode und planlosem Drauflosprogrammieren gemacht habe, bin ich eben leider in die gegenseitige "Falle" gerutscht: Ich will es jetzt "ganz richtig" machen und halte mich mit Kleinigkeiten auf, wenn etwas "nicht perfekt" ist. Der Grund dafür ist, daß ich nicht bereits, wenn ich erst 20% eines Spiels fertig habe, schon wieder damit anfangen will, mein eigenes Zeug zu workarounden, irgendwelche Fixes "außenrum anzuflanschen" usw. So etwas wird wahrscheinlich später ohnehin unumgänglich werden - sollte aber (meiner Meinung nach) im Anfangsstadium möglichst minimiert werden, damit es sich nicht später zu einer Epidemie auswächst.

wobo hat geschrieben:Ich will damit sagen: Leider sehe ich für mich persönlich keinen Ansatz, Deine vielen interessanten Produkte (nicht nur ISM) zu nutzen.

Ja, natürlich. Das Problem ist hier, daß ich - wie auch viele andere Hobby-Programmierer - mein eigenes Süppchen koche. Meine Formate sind zu nichts kompatibel außer zu sich selbst; ähnlich wird es auch bei anderen Hobbycodern aussehen. Eventuell würde das Software-Interface, um die Formate/Subroutinen verschiedener Leute miteinander zu verbinden, größer werden als das eigentliche Projekt.

Ich könnte mir bei der Zusammenarbeit für ein Spiel eher vorstellen, daß es jemanden für die reine Programmierung gibt, dann jemanden, der die kompletten Grafiken macht und dann jemanden, der Musik und Klangeffekte baut. Es läge dann beim Programmierer, die Daten der anderen so aufzubereiten, um sie in das Programm "einzupassen". Vielleicht sollte einer der Leute (oder jemand zusätzliches) auch ein Projektleiter sein. Früher habe ich so etwas nicht wichtig gefunden - aber viele Projekte verlaufen leider einfach im Sande, weil keiner da ist, der mal Meilensteine festlegt oder den Überblick über den Gesamtplan behält.

Was speziell die Grafiken oder Levels betrifft, so kann man hier immer noch Konvertier-Programme einsetzen. Mir würde es nicht einmal etwas ausmachen, wenn jemand das Level einfach mit einem "Malprogramm" malt (vorausgesetzt, er hält sich wenigstens an ein Levelblock-"Raster" wie z.B. 16x16 Pixel Blöcke, die sich auch anderswo wiederholen) und die Spawnpunkte für die Gegner irgendwo markiert...

Für die Musiken hatte ich schon überlegt, einen MOD-zu-ISM Konverter zu bauen. Allerdings gibt es da für mich 2 "Probleme":
1.) Es gibt inzwischen einen ziemlichen Wildwuchs an MOD-Formaten und jeder Musiker hat seinen Lieblings-Tracker, der wieder andere Features hat. Das alles zu unterstützen, könnte wieder so ausarten, daß ich ein weiteres halbes Jahr nur für das Schreiben eines Konverters verbringe. Die Speicherersparnis, die in ISM durch das nur einmalige Schreiben zu wiederholender Sequenzen erbracht wird (indem "Unterprogramme" oder Schleifen benutzt werden, sowie Mehrfachverwendung von Tonsequenzen mit verschiedener Geschwindigkeit und/oder transponiert usw.), ginge eventuell verloren - außer, der Konverter ist dann wirklich so "geschickt programmiert", solche Dinge zu erkennen und entsprechend umzuwandeln.
2.) Ich favorisiere für meine Spiele eher so den Stil "8-bit-Ära" (z.B. C64) und der "frühen 16-bit Ära" der Spielkonsolen, (z.B. SNES). Daher ist in ISM viel Mühe auf die Unterstützung von Software-Klangsynthese verwendet worden, also Hüllkurven+Wellenformen. Das ist es, was ich hauptsächlich verwenden will - Samples nur dort, wo es "nicht anders geht". Somit habe ich diesen "Synthesizer-Chip"-Klang, den ich möchte. MOD-artige Formate dagegen basieren ausschließlich auf Samples. Somit würde ich große Sample-Brocken mitschleppen (und gänzlich auf die Klangsynthese verzichten) - was ich genau durch den Einsatz von ISM eigentlich vermeiden wollte.

wobo hat geschrieben:Ich bitte Dich aber, weiterhin von Deinen Projekten zu berichten.

Ach, naja... Selbst ohne diese Bitte würde ich wahrscheinlich weiterhin die Leser des DOSforums mit meinen Errungenschaften belästigen. Wem soll ich's sonst erzählen? Interessiert ja sonst keinen und selbst hier im DOSforum geht es meines subjektiven Empfindens nach vor allem in letzter Zeit eher um Hardware (der DOS-Ära), um deren Tausch und (Wieder-)Aufbau usw. - so daß selbst in diesem Forum die Zielgruppe für meine "Romane" eher im eínstelligen Bereich liegen dürfte.

wobo hat geschrieben:Auch würde mich interessieren, wie Dein ISM klingt.

Das wäre kein Problem - ISM kann die erzeugten Sounddaten als WAV ausgeben. Mein Test-Musikstück "Alle meine Entchen", das ich 4-stimmig erweitert habe, könnte ich z.B. mal hochladen.
Ansonsten habe ich selbst noch nicht viel damit gemacht. Ich habe lediglich viele meiner damals für PC-Speaker gemachten Musiken (damals mit einem anderen ebenfalls selbstgebauten Musik-Programm) konvertiert in das ISM Format - das sind z.B. die ganzen Musiken meines "4 Gewinnt" Spiels oder die Musiken von "Playbox", das Spiel, das ich mal für shakky4711 gemacht habe.

wobo hat geschrieben:Super wäre, wenn Du z.B. mal ein Wav-Sample und eine ISM-Version mit entsprechendem ISM-Player irgendwo einmal zum Download anbieten würdest (gerne auch noch ein Beispiel über die Wellenform-Technik).

Ja, ich habe ein kleines Testprogramm hier, das die erzeugten Wellenformen für alle möglichen Kombinationen grafisch ausgibt (so wie es ISM auch intern macht), damit könnte man auch herumspielen, um "die perfekte Welle" für sich zu finden. Es benutzt die Subroutine von ISM dazu.

wobo hat geschrieben:Gerade etwas, was noch unter der Standard-Soundblaster- Qualität (8bit mono) ist, interessiert mich nämlich sehr,

Naja, der erzeugte Sound ist 8-Bit. Die einzelnen Stimmen erzeugen 4-Bit-Sound, der dann zusammenaddiert und hochskaliert wird.

Und: Weil ich mich für ISM auch (endlich mal) mit dem Soundblaster auseinandersetzen mußte, habe ich dazu viel gelesen. Der echte Soundblaster supportet übrigens auch das direkte Abspielen von 4-Bit und 2-Bit Sound, sowie ADPCM. (Leider tun das viele der SB-Derivate anderer Hersteller nicht.) Das habe ich aber absichtlich nicht unterstützt.

Da das Endziel ja die Fertigstellung eines Spiels ist, das möglichst viele Leute mit DOS-Rechnern spielen können, will ich immer bei meiner Mindest-Systemanforderung (CPU 386er oder kompatibel, Grafik VGA oder kompatibel, Sound SB oder kompatibel) bleiben. Eigentlich ist es schade, daß ich nicht auf 286er oder 8086er dabei runtergehe - aber viele der Units sind nun schon fertig und voller 386er-Code. Ich weiß, daß zu den Haupt-DOS-Zeiten der 386er schon eher mittlerer Standard war.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Mo 31. Okt 2016, 15:31

Zusatz-Information:
Ich habe soeben auf meinen Webspace unter
www.imperial-games.de/z/prism.zip
hochgeladen. Dieses enthält:
* prISM.exe, wav2smp.exe, sndcheck.exe, outwave3
* die ISM-Beschreibungstexte _ISM.TXT und _ISMFILE.TXT
* die Beispielfiles playbox.ism und shooter.ism
* Ente.wav (als Hörbeispiel)
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon wobo » Mo 31. Okt 2016, 22:18

DOSferatu hat geschrieben:(Interessiert sich jemand für das 4-Farben-Problem? Braucht jemand ein Tool, um PCX/BMP Bilder in Textmode/ANSI zu wandeln? Braucht jemand ein Tool, um Reime zu finden? Oder ein Tool, mit dem man Programmcode für Warteschleifen auf µs genau bauen kann? ...)


Ein Tool, um Reime zu finden??? Brauchen zwar nicht, aber stelle die exe bitte auch zum Download - muss ich mir ansehen :-)
Und was ist das 4-Farben-Problem?

Prism habe ich mir gerade downgeloaded. Gugge ich mir gerne an - Ausgiebig rumprobieren und Rückmeldung gibt's aber wohl erst am WE (muss derzeit leider sehr viel arbeiten, egal ob Feiertag oder WE...).
wobo
DOS-Guru
 
Beiträge: 555
Registriert: So 17. Okt 2010, 13:40

Re: Nicht-Tracker prISM

Beitragvon zatzen » Di 1. Nov 2016, 16:29

So weit entfernt von einem Tracker ist prISM ja gar nicht. Immerhin werden die Befehle auch
vertikal abgearbeitet, und die Notendarstellung mit Oktave und in der Form z.B. C#3 ist mir
auch sehr vertraut. Allein die nicht-parallele Darstellung von zeitlich zusammenfallenden
Ereignissen fordert ein, dass das komplette Musikstück was man einprogrammieren will schon
fertig vorliegt, weil ein Improvisieren so ziemlich schwierig ist.

Aber es ist ein sehr umfangreiches und wohldurchdachtes System, das gefällt mir.
Und ich möchte gern einmal ein etwas komplexeres kleines Musikstück einprogrammieren.
Für den Anfang habe ich mir PLAYBOX.ISM genommen und wollte dort die Konfiguration
von Hüllkurve und Wellenform auf Kanal B kopieren. Das Problem war, dass ich die
Markierung nicht mehr wegbekam und in der Statuszeile fortan immer nur Modify-
Aktionen dargestellt wurden. Zudem konnte man das Programm dann nicht mehr
normal beenden.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Mi 2. Nov 2016, 07:15

wobo hat geschrieben:Ein Tool, um Reime zu finden??? Brauchen zwar nicht, aber stelle die exe bitte auch zum Download - muss ich mir ansehen

Ja, derzeit eigentlich eher eine Suche aus einer 8 MB großen Wortliste, die ich aus einem Übersetzungsprogramm "rausgekratzt" habe und entsprechende Vergleiche.
Aber die Erweiterung sieht vor, die Wörter in "Silben" zu teilen - wobei es eigentlich keine Silben sind, sondern alle möglichen Folgen von Vokalen und Konsonanten, die es gibt. Für Vokale z.B. A E I O U Ä Ö Ü AA AI AU EE EI EU... usw... und für Konsonanten neben den einzelnen dann auch sowas wie ST STR PR KL PL und so...
Diesen wird dann zugeordnet, wie "stark" sie sich reimen, d.h. zu jeder Kombination gibt es dann einen "Nchtreimwert", der umso geringer ist, je besser der Reim. E und E ergibt 0, E und Ä ergibt 1 usw. Und bei Konsonanten ebenfalls. z.B. reimt sich K ganz gut auf CK, aber auf G reimt es sich etwas schlechter (aber kann zur Not noch gehen, gerade wenn G am Ende steht) aber auf L oder P reimt K sich gar nicht, bekommt also einen entsprechend hohen "Nichtreimwert".
(Ich mache das deshalb "umgekehrt", (also best = 0, schlechtest = X), weil es keine genaue Definition dafür gibt, wie schlecht sich etwas reimt - dafür aber eine exakte Definition für einen exakten Reim (bei Gleichheit)).
Der Plan sieht dann vor, daß bei der Reimsuche dann die Wörter in die entsprechenden "Kombinationen" aufgeteilt werden:
Reimsuche = R|EI|M|S|U|CH|E
und die Wortliste durchgerasselt wird, wobei jedes Wort ebenfalls diese Trennung erlebt. Dann können die Reime absteigend mit ihrer "Qualität" aufgelistet werden, vom besten zum schlechtesten Reim. (Das Wort selbst, das natürlich "Summe" 0 hat, würde immer als erstes stehen, das könnte man auch weglassen.

Ich weiß nicht, wie andere das Problem angehen würden - das ist mein Ansatz dazu.
Man könnte das Ganze natürlich auch ohne Wortliste machen, dann würde das Ding alle Kombinationen ausgeben, die es so gibt und der Benutzer muß dann entsprechend sehen, was davon ein richtiges Wort ist und was nur Kauderwelsch.
Allerdings hätte das natürlich den Vorteil, daß so Wörter gefunden werden könnten, die in der Wortliste nicht enthalten sind.

wobo hat geschrieben:Und was ist das 4-Farben-Problem?

Das Problem ist inzwischen durch einen Wissenschaftler gelöst/bewiesen worden - aber es ist trotzdem interessant, damit "herumzuspielen".
Angefangen hatte die ursprüngliche Fragestellung mit Landkarten. Es ging darum, wieviele Farben man minimal braucht, um bei einer Landkarte mit beliebig geformten Ländergrenzen die einzelnen Länder so einzufärben, daß in keinem Fall die gleiche Farbe an einer Grenze aufeinanderstößt - daß sich also nur unterschiedliche Farben an den Grenzen berühren. Die (inzwischen bewiesene) Aussage ist, daß dafür höchstens 4 Farben gebraucht werden, egal wie komplex die Grenzen geformt sind.
Ich habe für das Ganze mal ein Testprogramm (mit einer Test- und Füll-Funktion) gebaut.
Ich habe es quasi "grafisch" gelöst. Normalerweise würde man hier die Flächen durchnumerieren und dann iterativ vorgehen, ohne hier jedesmal zu füllen bzw "test-füllen". Es funktioniert bei mir auch nicht bei allen Formen, also muß irgend ein Rechenfehler meinerseits vorliegen.

wobo hat geschrieben:Prism habe ich mir gerade downgeloaded. Gugge ich mir gerne an - Ausgiebig rumprobieren und Rückmeldung gibt's aber wohl erst am WE (muss derzeit leider sehr viel arbeiten, egal ob Feiertag oder WE...).

Ja, der Job stiehlt einem eine Menge Lebenszeit - und vor allem Kraft.
Aber laß Dir ruhig Zeit mit dem Kram. Das eilt nicht.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Mi 2. Nov 2016, 09:35

zatzen hat geschrieben:So weit entfernt von einem Tracker ist prISM ja gar nicht. Immerhin werden die Befehle auch vertikal abgearbeitet, und die Notendarstellung mit Oktave und in der Form z.B. C#3 ist mir
auch sehr vertraut.

Das ist ja auch die meiner Meinung nach plausibelste Darstellungsmöglichkeit (außer wenn man es als Notenblatt darstellt). Da die Werte (Noten, Lauflänge, andere Befehle/Parameter) ja quasi "breiter als hoch" sind, weil als "Text" dargestellt, wäre es hier sehr unübersichtlich, wenn man diese dann auch noch nebeneinander darstellt - somit ist die senkrechte Darstellung hier die beste Wahl. In dieser Hinsicht stimme ich mit allen Trackern überein.

zatzen hat geschrieben:Allein die nicht-parallele Darstellung von zeitlich zusammenfallenden Ereignissen fordert ein, dass das komplette Musikstück was man einprogrammieren will schon fertig vorliegt, weil ein Improvisieren so ziemlich schwierig ist.

Versuche mal die Tasten EINFG und ENTF. Das könnte das Problem schon lösen.

zatzen hat geschrieben:Aber es ist ein sehr umfangreiches und wohldurchdachtes System, das gefällt mir.

Schön, daß Du das so siehst. Ja, ich habe mir reichlich Mühe gegeben, hier trotz meines leicht anderen Ansatzes etwas Logik in das Ganze hineinzubekommen. Für mich sind die Stimmen eben einzeln laufende Spuren, die nicht unbedingt etwas miteinander zu tun haben müssen.
Und: Normalerweise neigt man ja als "Tracker" dazu, einer Stimme ein bestimmtes Instrument zuzuordnen und wenn das gerade gebraucht wird, spielt diese Stimme das Instrument, wenn nicht, bleibt sie stumm.
Auf dem C64 mit seinem SID mit 3 Stimmen konnte man sich so etwas nicht erlauben. Hier kann eine Stimme ihr "Instrument" auch wechseln (genau wie in ISM/prISM) - somit kann man mit weniger Stimmen trotzdem eine vollständige Musik erreichen - indem jeweils eine Stimme, wenn sie gerade nicht für Instrument A gebraucht wird, dann mit Instrument B etwas anderes tun kann... Und ja, ich weiß, daß das in MOD (u.ä.) auch geht - aber die Leute neigen selten dazu, das so zu machen.

Weil gern mit "Instrumenten" gearbeitet wird und um die Arbeit zu erleichtern, muß man hier nicht immer nur mit den Hüllkurven/Wellenform/Filter Befehlen arbeiten, sondern kann eine Einstellung unter einer Instrument-Nummer (0 bis 127) sichern und auch wieder laden, das wird über eine externe Tabelle geregelt.

Eigentlich sah der Plan auch vor, daß es noch einen Menüpunkt gibt, diese Instrumente quasi "extern"(außerhalb der Musik) zu erstellen - so daß diese innerhalb der Musik "geladen" werden können (ohne sie zu speichern). ISM (die Unit) und auch das entsprechende File-Format hat dies bereits vorgesehen.

zatzen hat geschrieben:Und ich möchte gern einmal ein etwas komplexeres kleines Musikstück einprogrammieren.

Ja, tu Dir keinen Zwang an, dazu ist das Ding ja da.

zatzen hat geschrieben:Für den Anfang habe ich mir PLAYBOX.ISM genommen und wollte dort die Konfiguration von Hüllkurve und Wellenform auf Kanal B kopieren. Das Problem war, dass ich die Markierung nicht mehr wegbekam und in der Statuszeile fortan immer nur Modify-Aktionen dargestellt wurden.

Hier hilft ESC, dies setzt nacheinander gesetzten Modus und Markierung zurück.
Wenn z.B. Markierung da ist und COPY gesetzt ist:
erstes ESC: COPY-Modus ist wieder aus (kein Modus)
zweites ESC: Markierung ist auch wieder aus
Ist nur eine Markierung da, reicht natürlich einmaliges ESC.

Ja, das ist etwas "tricky", das hätte ich vielleicht erwähnen sollen.
(Entsprechende Ausgaben habe ich jetzt in der Statuszeile hinzugefügt.)

zatzen hat geschrieben:Zudem konnte man das Programm dann nicht mehr normal beenden.

Ja, diesen Bug habe ich jetzt entfernt. (Wenn man das Ganze intern als so eine interaktive GUI aufbaut und z.B. ENTER als Bestätigung für jedes und alles ist, muß man natürlich berücksichtigen, in welchem Modus man ist. Ist ein Pulldown offen, sollte das natürlich Priorität gegenüber der Bestätigung der Kopier-Funktionen haben...)

Ich habe noch ein paar kleinere Dinge gefixt, außerdem den Stack geringfügig vergrößert (es gab hier Probleme mit Überschreiben von Parser-Daten).

Das Ganze kann jetzt wieder von gleicher Stelle
http://www.imperial-games.de/z/prism.zip
geladen werden, Version 0.08

Ich hoffe, Du kommst mit prISM ansonsten einigermaßen klar.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon wobo » Do 3. Nov 2016, 19:07

Der Wertung von Zatzen,
zatzen hat geschrieben: Aber es ist ein sehr umfangreiches und wohldurchdachtes System, das gefällt mir.

möchte ich mich uneingeschränkt anschließen. Mich hat der Funktionsumfang des Programms richtig erschlagen. Ich habe im ersten Moment gedacht, dass Du da ein Jahrzehnt dran rumprogrammiert haben musst. (Aber ich weiss, Du warst schneller. Es war nur der Eindruck vom Aufwand her, den das Programm gemacht hat.)

Leider ging es mir noch schlimmer als Zatzen, was die Bedienung anbelangt. Ich habe es nicht geschafft, ein ISM einzuladen oder irgendwie Wellenformen abzuspielen. Ich habe das aber so erwartet, da ich auch bei Verwendung eines ganz normalen Trackers (z.B. die bekannten Fast-Tracker oder Scream-Tracker) nicht mehr schaffe, als Mod-Files einzuladen und abzuspielen. Es liegt bei mir einfach an fehlendem Hintergrundwissen und der fehlenden Verwendungsabsicht, was klangerzeugende Programme anbelangt, die über einfache Player hinaus gehen (Ich bin einfach zu 100% Konsument!).

Super fand ich auch Dein ENTE.WAV - hat mir sehr gefallen. Und es ist gerade das, was mir am PC-Klangspektrum noch fehlte. Für mich ist purer 8-bit-mono Sound bei 22 Khz für den Retro-Bereich schon absolute Oberklasse. Ich habe mir immer gedacht, dass es zwischen PC-Piepser und AdLib/SB-DAC noch etwas dazwischen geben müsste. MEine Erwartung war da immer auf etwas wie den C64-Sound gerichtet. Meines Erachtens ist ISM also gerade das, nach was ich klangmäßig im PC-Bereich immer gesucht habe und was meiner Ansicht nach im PC-Bereich ewig gefehlt hat.

Dir und Zatzen sind jeweils Programme gelungen, die nach meinem Geschmack genau das ausfüllen, was aus meiner Sicht im PC-Bereich gefehlt. Einmal nämlich etwas sehr kompaktes C64-mäßiges, was ich klanglich unterhalb klassischer AdLib/SB-TEchnik einordnen würde (das ist nicht abwertend gemeint, sondern ganz im Gegenteil!). Andererseits ein sinnvolles Erweitern von 4ch-Tracker-Musik, ohne in die Gigantomie der Formate a la s3m etc. auszuarten. Kann nur sagen: weiter so und freue mich darauf, Eure Produkte zu konsumieren :-)
wobo
DOS-Guru
 
Beiträge: 555
Registriert: So 17. Okt 2010, 13:40

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Fr 4. Nov 2016, 07:49

wobo hat geschrieben:Der Wertung von Zatzen,
zatzen hat geschrieben: Aber es ist ein sehr umfangreiches und wohldurchdachtes System, das gefällt mir.

möchte ich mich uneingeschränkt anschließen. Mich hat der Funktionsumfang des Programms richtig erschlagen. Ich habe im ersten Moment gedacht, dass Du da ein Jahrzehnt dran rumprogrammiert haben musst. ...

Naja, es war schon eine ganze Weile. Das "Wichtige" ist ja eigentlich nicht das Programm (prISM) - das ist ja nur der Editor, sondern ISM, der eigentliche "Kern", der wirklich die Klangdaten generiert.

wobo hat geschrieben:Leider ging es mir noch schlimmer als Zatzen, was die Bedienung anbelangt. Ich habe es nicht geschafft, ein ISM einzuladen oder irgendwie Wellenformen abzuspielen.

Hm. Dann scheint es ja doch nicht so "wohldurchdacht" zu sein...

Also: ALT gedrückt halten, dadurch wird ja die obere Menüzeile sichtbar, in der dann steht:
File Values Modify Display Windows Output Play Help
Wenn man dann (mit weiterhin gedrückter ALT) den entsprechenden (roten) Anfangsbuchstaben drückt, erscheinen die Pulldowns dazu.
Beispiel:
ALT+F, und im Pulldown O wählen, damit öffnet man erst das Menü "File" und dann führt man "Open" aus. Dann erscheint ein File-Pulldown, aus dem man die Files auswählen kann. Es werden nur Verzeichnisse und Laufwerke angezeigt - und Files mit der Erweiterung .ISM
Diese dann mit Enter auswählen. Dann erscheint ein weiteres Pulldown, in dem gewählt werden kann, was alles (sofern vorhanden) aus dem File geladen werden soll. Da braucht man erstmal nichts ändern, sondern einfach nochmals Enter drücken (der Balken steht schon auf >> LOAD MUSIC).
Und damit wird geladen.

Wie in Borlands Turbo Pascal kann man das ALT+F und O auch abkürzen:
Mit F3 kommt man direkt zum Laden (Open) mit F2 direkt zum Speichern als... (Save As...) und mit Shift+F2 zum Speichern unter gleichem Namen.

Außerdem kann all das auch mit der Maus bewerkstelligt werden (vorausgesetzt, ein Maustreiber ist geladen und eine Maus ist angeschlossen).
Ich sehe schon, ich werde nicht umhin kommen, eine längere Bedienungsanleitung dazu zu schreiben.

Kleiner Tip: Mit F10 kann man sich einige der Hotkeys anzeigen lassen (mit Cursortasten blättern).

wobo hat geschrieben:Ich habe das aber so erwartet, da ich auch bei Verwendung eines ganz normalen Trackers (z.B. die bekannten Fast-Tracker oder Scream-Tracker) nicht mehr schaffe, als Mod-Files einzuladen und abzuspielen. Es liegt bei mir einfach an fehlendem Hintergrundwissen und der fehlenden Verwendungsabsicht, was klangerzeugende Programme anbelangt, die über einfache Player hinaus gehen (Ich bin einfach zu 100% Konsument!).

Ja, aber ich hatte angenommen, das System mit einer Kopf-Menüzeile (wo als erstes immer File - im Deutschen wäre es Datei - steht) und daraus herausfahrenden Pulldowns wäre inzwischen so eine Art Bedienungsstandard.

Achja, wichtig:
Um das File abzuspielen das Menü Play aufrufen - oder die Tasten F5, F6, F7, F8, F9 versuchen:
F5: spielt das ganze File beginnend in Fenster A ab. Gedacht für Stücke, wo die erste Stimme mit Befehlen andere Stimmen generiert und startet. (So sind meine eigenen Stücke gemacht.)
F6: spielt alle Fenster ab, die nicht mit einem "Stop-Befehl" (QQQ) starten, also valide Daten enthalten. Für Stücke, wo die Spuren unabhängig voneinander eingegeben sind, ohne Startbefehle.
F7: spielt nur das aktuell gewählte Fenster ab, also nur die Spur darin. Wenn es allerdings Fenster A ist und dieses andere Stimmen startet, verhält es sich wie F5.
F8: spielt ab der aktuellen Cursorposition in irgend einem Fenster - generiert aber davor schon Daten (ohne sie abzuspielen), damit ab der Stelle alle Werte so gesetzt sind, wie sie bis zu diesem Punkt gesetzt sein müssen. Mit SHIFT+F8 wird wirklich ab dieser Stelle gespielt OHNE vorheriges "Mute-Play".
F9: spielt (immer mit vorherigem "Mute-Play"!) ab der gesetzten Sekunde (Timecode) ab, die man im Play-Menü einstellen kann. Nehmen wir an, man macht eine Musik, die 5 Minuten lang ist und will eine bestimmte Stelle testen. So kann man vermeiden, immer vorher wieder die ganze Musik bis zu dieser Stelle durchspielen/durchhören zu müssen (das Gleiche ist auch bei F8 gedacht).

F1 ist die Hilfe-Taste. Ist man in einem Fenster (also keine Pulldowns offen) steht man immer auf einem der "Befehle". Hier wird dann eine entsprechende Hilfe/Erklärung zu diesem Befehl und seinen Parametern angezeigt. Das Gleiche erreicht man, indem man mit der rechten Maustaste auf den Befehl klickt.

Vielleicht noch wichtiger:
Unter Output kann das Ausgabegerät gewählt werden - per Default ist dies auf den PC-Speaker eingestellt. Manche Menschen bauen (unglaublicherweise) in einen DOS-Rechner keinen PC-Speaker ein - und würden dann natürlich erst einmal GAR NICHTS hören.
Im Menü Output kann man dann auch den Sound Blaster auswählen. Achtung: Hier sind Port 220h, IRQ 5, DMA 1 voreingestellt. Dies sollte man auf die Werte ändern, auf die man selbst seinen SB gestellt hat - oder alternativ auch die Env. BLASTER= Option aus dem Output-Menü benutzen, um gleich die Werte aus der Umgebungsvariable einzulesen.

wobo hat geschrieben:Super fand ich auch Dein ENTE.WAV - hat mir sehr gefallen.

Naja, ich bin nicht gerade ein Musiker. Das Ganze ist nur ein Test für die Mehrstimmigkeit von ISM und der vielen (auch "Spezial"-) Befehle. Das ist auch der Grund, wieso ich das dazugehörige ENTE.ISM nicht mitliefere: Es ist vollgestopft mit solchen Spezialbefehlen, sowie mit zusätzlichen Sachen, die an der Musik erst einmal nichts ändern würden. Das würde einen "prISM-Anfänger" wahrscheinlich zu sehr verwirren und verunsichern, wenn er diesen "Code" sieht...

Normalerweise wird bei einem Musikstück, bei dem die Stimmen später einsetzen, auf die noch stillen Stimmen so lange ein oder mehrere (oder in Schleifen) MUT (Mute = Stille) Befehle gesetzt, bis der Einsatz erfolgt.
In ENTE.WAV habe ich aber die Stimmen wirklich erst nacheinander einsetzen lassen, d.h. die 2., 3. und 4. Stimme werden erst eingeschaltet/aktiviert als sie gebraucht werden (immer jeweils von Stimme 1). Erst beim 4. Durchlauf hört man alle 4 Stimmen. Ab dem 5. Durchlauf spielt die 1. Stimme nicht mehr Klangsynthese (Welle+Hüllkurve), sondern ein "Quak"-Sample ab, ein echtes Entenquaken in den verschiedenen Tonhöhen des Musikstücks.
DIe Benutzung von Samples ist in prISM aber (derzeit) noch etwas andersartig gelöst, weil es ja hauptsächlich dazu gedacht ist, in Spielen Anwendung zu finden. Hier werden die Samples ja dann auch extern (außerhalb der Musikfiles) gespeichert, damit sie in mehreren Musikstücken "wiederverwendet" werden können, ohne mehrmals im Datenfile vorliegen zu müssen.

wobo hat geschrieben:Und es ist gerade das, was mir am PC-Klangspektrum noch fehlte. Für mich ist purer 8-bit-mono Sound bei 22 Khz für den Retro-Bereich schon absolute Oberklasse. Ich habe mir immer gedacht, dass es zwischen PC-Piepser und AdLib/SB-DAC noch etwas dazwischen geben müsste. MEine Erwartung war da immer auf etwas wie den C64-Sound gerichtet. Meines Erachtens ist ISM also gerade das, nach was ich klangmäßig im PC-Bereich immer gesucht habe und was meiner Ansicht nach im PC-Bereich ewig gefehlt hat.

Schön, daß Dir dieser Minimalklang so gefällt. Für mich war es eher eine Speicher-/Rechenzeit-Entscheidung und ich bin eigentlich selbst erstaunt, daß es trotzdem noch relativ anhörbar klingt.
Bedenkt man, daß ich hier eigentlich mit Klangsynthese arbeite, hätte ich das Ganze wohl besser gleich für AdLib auslegen sollen. Ich habe mir aber ein riesiges dickes Buch zu AdLib/Soundblaster komplett durchgelesen, in dem das alles erklärt wird - auch die AdLib Register und wie die Klangsynthese dort vonstatten geht. Und ich fand es ehrlich gesagt zu kompliziert als daß ich glauben könnte, jemals selbst aus einer AdLib irgend ein Geräusch erzeugen zu können...

ISM und prISM wurden übrigens auch vollständig mit dem PC-Speaker entwickelt (PC-Ticker hochsetzen und den "Digital"-Mode des Speakers nutzen), die SoundBlaster-Unterstützung habe ich erst nachträglich eingebaut.

wobo hat geschrieben:Dir und Zatzen sind jeweils Programme gelungen, die nach meinem Geschmack genau das ausfüllen, was aus meiner Sicht im PC-Bereich gefehlt. Einmal nämlich etwas sehr kompaktes C64-mäßiges, was ich klanglich unterhalb klassischer AdLib/SB-TEchnik einordnen würde (das ist nicht abwertend gemeint, sondern ganz im Gegenteil!). Andererseits ein sinnvolles Erweitern von 4ch-Tracker-Musik, ohne in die Gigantomie der Formate a la s3m etc. auszuarten. Kann nur sagen: weiter so und freue mich darauf, Eure Produkte zu konsumieren :-)


ENTE.WAV nutzt zwar nur 4 Stimmen.
ISM (und auch Zatzens ZSTM) können aber bis zu 16 Stimmen gleichzeitig generieren/abspielen.

Ich habe von Klangerzeuung (und auch Klangauswertung) weitaus weniger Ahnung als Zatzen. Für mich ist das Ganze (wie alles, was ich so auf Computern herstelle) immer nur so "mathematisch". Deshalb kann ich musikalisch nur so "Einheitsbrei" machen - an mir ist nicht gerade ein Komponist/Musiker verlorengegangen...

Vielleicht sollte ich dann aber bald mal damit anfangen, meine schon ewig geplanten Spiele umzusetzen. Das wird wahrscheinlich WIRKLICH so ablaufen, daß ich mir einen "Rahmen" basteln werde, der so "generelles Spiel"-mäßig aussieht (also als Sourcecode) und in den dann die einzelnen Units (je nach Bedarf und Compilerschaltern) eingeklinkt werden.
Das wird dann aber wohl trotzdem kein "Game-Maker" im eigentlichen Sinne werden, sondern eher ein "Datenzusammenfasser" oder so, der die Einzelteile dann zu Spieldaten zusammenkehrt.

Da muß ich mir noch etwas überlegen...
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Di 15. Nov 2016, 21:28

Ich habe die Hilfstexte etwas fehlerbereinigt. Es waren einige Rechtschreibfehler und geringfügige Informationsfehler enthalten. Der Programmcode selbst ist unverändert.

Hier ist Version 0.09 von prISM:
www.imperial-games.de/z/prism.zip
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » So 27. Nov 2016, 21:23

Achja, ich schon wieder.
Ich will keinesfalls nerven - aber mal kurz zwei Dinge:
1.) Hat schon jemand mit diesem prISM etwas herumexperimentiert? Kann man damit arbeiten? Musik damit gemacht?

2.) Mir ist neulich aufgefallen, daß irgendwas mit der Umrechnung der eingestellten Samplefrequenz zur Abspielfrequenz nicht hinhaut. Da muß ich wohl nochmal drüber. Irgendetwas mit dem Faktor stimmt nicht ganz.
Aber wenn das Ganze meinerseits geändert wurde und jemand mit der jetzt "falschen" Routine schon Samples genutzt hätte, wäre das trotzdem nicht so schlimm, weil man ja einerseits nur die Grundfrequenz im Sample selbst anpassen müßte (ist nur ein Wert) - ohne die Musikdaten zu ändern. - Oder bei den Musikdaten eben einen entsprechenden Transponier-Befehl einfügen müßte, wenn man die Samples nicht ändern will.
Ich gebe natürlich sofort Bescheid, wenn das Problem gefixt wurde.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Nicht-Tracker prISM

Beitragvon zatzen » Mi 30. Nov 2016, 15:30

Ich bin leider noch nicht dazu gekommen, ein Musikstück in ISM zu programmieren.
Bin gerade noch zu sehr mit dem Update von ZSMPLAY beschäftigt, welches diesmal
auch soetwas wie ein kleines Spiel beinhalten wird, einfach auch um alle Funktionen
von ZSM und ZVID zusammen zu testen.
Aber ich hole das nach.
ZSM habe ich eine Funktion zsm_playfx hinzugefügt, mit der extra geladene Samples
in beliebiger Samplerate und Lautstärke jederzeit abgespielt werden können.
Dabei habe ich noch eine kleine Frage.
Ich habe hier z.B. die obige Procedure zsm_playfx(sample: byte; freq: word; vol: byte);
Wenn ich diese nun auch mal innerhalb asm aufrufen will, wie übergebe ich dann die Parameter?
Ich merke, wie sich die Schleifen und IFs und Procedure-Aufrufe anhäufen wenn man
etwas interaktives mit Animationen macht, da wäre es gut wenn man einiges mit
Registern statt Variablen machen könnte und booleans mit schnellen OR Operanden
handlen könnte. Wenn Pascal das nicht ohnehin schon tut. Aber wie sieht es überhaupt
mit der Pascal Funktion INC (oder DEC) aus? Ist das eine Procedure mit Stackrahmen usw?
Dann wäre man doch mit "asm inc variable end;" besser bedient.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Nicht-Tracker prISM

Beitragvon zatzen » Do 1. Dez 2016, 18:08

Sorry, das war etwas Off-Topic.

Da du selbst sagst, dass der Editor eigentlich nicht das wichtigste ist,
wäre vielleicht so nebenbei ein halbwegs intelligenter Converter Trackermodul -> ISM sinnvoll,
der die Vorzüge deines Programmiersprachen-ähnlichen Konzepts berücksichtigt und die
Daten entsprechend effizienter codiert?
Dazu müsste ich das Format natürlich ersteinmal gänzlich verstehen, und der prISM
Editor wäre letztlich doch immer noch sinnvoll, allein schon wegen der Kontrolle
oder Optimierung der konvertierten Daten.
ISM kann z.B. Portamento, das kann mein ZSM nicht, aber mein eigentlicher Tracker
in dem ich Musik programmiere kann es.
Benutzeravatar
zatzen
617K-Frei-Haber
 
Beiträge: 310
Registriert: Di 17. Apr 2012, 04:10
Wohnort: bei Köln

Re: Nicht-Tracker prISM

Beitragvon DOSferatu » Mi 7. Dez 2016, 19:35

zatzen hat geschrieben:Ich bin leider noch nicht dazu gekommen, ein Musikstück in ISM zu programmieren.

Naja, es eilt ja nicht.

zatzen hat geschrieben:Bin gerade noch zu sehr mit dem Update von ZSMPLAY beschäftigt, welches diesmal
auch soetwas wie ein kleines Spiel beinhalten wird, einfach auch um alle Funktionen
von ZSM und ZVID zusammen zu testen.

Ein Spiel? Cool!

zatzen hat geschrieben:Aber ich hole das nach.

Ja, wie gesagt: Es eilt nicht. Daß ich meine Programme hier präsentiere verpflichtet nicht zur Benutzung.

zatzen hat geschrieben:Dabei habe ich noch eine kleine Frage.
Ich habe hier z.B. die obige Procedure zsm_playfx(sample: byte; freq: word; vol: byte);
Wenn ich diese nun auch mal innerhalb asm aufrufen will, wie übergebe ich dann die Parameter?

Code: Alles auswählen
push sample; push freq; push vol; call zsm_playfx;

Zur Beachtung: Wenn die Procedure als FAR deklariert ist (also entweder genereller Compilerschalter {$F+} oder FAR hinter der Procedure angegeben) muß der Call in Assembler natürlich call far ptr heißen.
Weiterhin zu beachten: Auf den Stack können nur Words (oder DWords) geschoben werden, keine Bytes. D.h. sample und vol müssen dann als Words gePUSHt werden, so geschieht es auch in Pascal selbst.
also dann eigentlich:
Code: Alles auswählen
push word ptr sample; push freq; push word ptr vol; call zsm_playfx;

In dem Fall werden sample und vol als Words gePUSHt, das Lowbyte ist der Inhalt der Variable, das Highbyte ist das Byte, das zufällig nach der Variable im Speicher steht. Sollte eigentlich nichts ausmachen, weil die Procedure selbst ja nur die Lowbytes verwendet.
Sollten sich die Werte in Registern befinden, so ist nur darauf zu achten: Byte-Register (sowas wie AL oder BH) kann man nicht PUSHen. Wer AL PUSHen will, pusht AX. Wer BH PUSHen will, muß BX pushen. Soll es an eine Pascal-Procedure als Byte-parameter übergeben werden, müßte man dann natürlich die Bytes von BX vorher tauschen (weil BH ja das obere Byte ist), z.B. mit xchg BL,BH oder rol BX,8


zatzen hat geschrieben:Ich merke, wie sich die Schleifen und IFs und Procedure-Aufrufe anhäufen wenn man
etwas interaktives mit Animationen macht, da wäre es gut wenn man einiges mit
Registern statt Variablen machen könnte und booleans mit schnellen OR Operanden
handlen könnte.

Ich bin mittlerweile generell ein großer Freund davon geworden, zeitkritische Dinge in
Assembler zu tun. Am liebsten würde ich ALLES in Assembler machen, aber da bleibt mir
nicht die Zeit dafür und in manchen Fällen spart man dadurch auch kaum etwas ein.
IF-Kaskaden kann man unter anderem mit sogenannten Entscheidungstabellen verhindern.
Kann das bei Bedarf gern mal genauer erklären.

zatzen hat geschrieben:Wenn Pascal das nicht ohnehin schon tut. Aber wie sieht es überhaupt
mit der Pascal Funktion INC (oder DEC) aus? Ist das eine Procedure mit Stackrahmen usw?
Dann wäre man doch mit "asm inc variable end;" besser bedient.

Nein. Diese "internen" Funktionen/Procedures, zu denen auch inc/dec u.ä. gehören werden
direkt in den dazugehörigen Assemblerbefehl umgewandelt, ohne Stackrahmen.
(Ich habe es sogar extra getestet.)
Im Falle von Variablen ist das dann in Assembler ein INC auf die Speicherstelle, wo die
Variable liegt, mit entsprechender Größe (also byte/word/dword).
(Anmerkung; Ein INC mit Parameter, also z.B. INC(Variable,5) wird natürlich in einen ADD
gewandelt, klar.)
Einzig vielleicht zu erwähnen: In Borland-TurboPascal wird für maximal 286er compiliert,
da gibt es kein 32bit. Longints werden dann wohl 2 Befehle draus, meiner Meinung nach
ein ADD für das untere Word und ein folgendes ADC für das obere Word. Das habe ich nicht
getestet, aber wär ja schön dämlich, wenn's anders wäre.
Dem könnte man natürlich mit einem entsprechenden 32-Bit-Befehl etwas entgegenwirken.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Nächste

Zurück zu Programmierung

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste