Nicht-Tracker prISM

Diskussion zum Thema Programmierung unter DOS (Intel x86)
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von DOSferatu »

zatzen hat geschrieben:Sorry, das war etwas Off-Topic.
Naja, in Deinen Threads zu ZVID und ZVM habe ich mich ja auch schon desöfteren zu Off-Topic verleiten lassen,
ich bin da nicht so empfindlich, wenn ein Thema mal ETWAS neben die Spur gerät. Das passiert schon mal.
zatzen hat geschrieben: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?
Wie ich schon angedeutet hatte, bin ich von dieser Idee allenfalls semi-begeistert, da auf diese Art
die Stärken von ISM überhaupt nicht ausgenutzt werden und ca. 80% bis 90% der Features die ISM
bietet gar nicht nutzbar wären. Desweiteren setzen MOD-artige Tracker ausschließlich auf Nutzung
von Samples - in ISM hingegen soll dies ja durch elektronische Klangsynthese kompensiert werden
und Samplenutzung eher eine Nebenrolle spielen.
Außerdem hat das ursprüngliche MOD-Format inzwischen einen derartigen Wildwuchs erlebt, daß
ich mich vor eine etwas größere Aufgabe gestellt sehe, diesen ganzen Kram für einen Konverter
wieder intern auf einen "gemeinsamen Nenner" zu bringen. Vom anschließender Datenoptimierung,
um Schleifen/Sprünge/Wiederholungen geschickt zu finden und in ISM dann einzusetzen ist an
diesem Punkt noch nicht einmal die Rede.
zatzen hat geschrieben: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.
Naja, das von mir mitgelieferte ZIP enthält ja netterweise sogar einen Text, der das komplette Format
der Befehle und Register beschreibt, sowie auch einen Text, der das von prISM genutzte Fileformat
erklärt.
zatzen hat geschrieben:ISM kann z.B. Portamento, das kann mein ZSM nicht, aber mein eigentlicher Tracker
in dem ich Musik programmiere kann es.
ISM kann aber einiges nicht "direkt", was in MOD Standard ist - ich denke da z.B. an Vibrato.
Da ISM aber so "programmiert" werden kann, also frei belegbare Register und Schleifen hat, kann
so etwas nachgebildet werden.
Den HLD ("Hold") Befehl, den es anfangs nicht gab, habe ich extra noch nachträglich eingebaut. Dieser
kann einen beendeten Ton wiederaufnehmen = weiterspielen. Somit besteht auch für ISM die Möglichkeit,
während der Laufzeit eines Tons einige seiner Parameter zu ändern.
Portamento wollte ich aber unbedingt "direkt" haben, da die "Nachbildung" zu eklig zu organisieren
gewesen wäre und man es selbst dann wohl nicht so "stufenlos" (bzw quasi-stufenlos) wie in ISM selbst
hinbekommen würde.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von zatzen »

DOSferatu hat geschrieben:Ein Spiel? Cool!
Erwarte mal nicht zu viel. Ich werde zwar einiges an Sound und Grafik auftischen, habe
mir auf die Schnelle aber kein besonders komplexes Spielprinzip einfallen lassen.
Alles sehr improvisiert und ist eher als ein kleiner Gag zu verstehen, es ist
alles nur entstanden weil ich mich mal etwas mit ZSMPLAY und ZVIDVIEW austoben wollte.
Zu jedem Musikstück soll eine Highscore gespeichert werden können, wobei
die Tabelle in einer Datei ZSMPLAY.HSC gespeichert wird. Dabei fehlt mir
noch das Know-How über CRC32, was ich gerne verwenden würde um z.B.
anhand der Patterndaten die Musikstücke eindeutig identifizieren zu können.
Ich habe noch nicht sonderlich viel dazu recherchiert, bis jetzt scheint mir:
- zu prüfende Daten kann man als eine seeeehr große Zahl verstehen,
die man durch das 32 (oder 33?)- Bit Polynom dividiert.
- das ganze passiert in der Praxis schrittweise durch Shiften und XOR
- Der Divisionsrest ergibt die Prüfsumme (?)
DOSferatu hat geschrieben:Ja, wie gesagt: Es eilt nicht. Daß ich meine Programme hier präsentiere verpflichtet nicht zur Benutzung.
Es wäre aber mal ganz spannend, ISM komplexe Musik spielen zu hören.
Dass ich mich in prISM noch nicht so gut zurechtfinde und man dort nicht einfach so drauflos
improvisieren kann ist allerdings eine Hürde. Statt eines Converters von Tracker nach ISM
wäre ein Tool sinnvoll, welches meine Trackerstücke analysiert und mir das ganze auf eine
übersichtliche Weise darstellt, was ich mir dann z.B. ausdrucken könnte, um es dann in
prISM unter Benutzung aller Möglichkeiten einzuprogrammieren.
Wenn ich etwas im Tracker "komponiere", dann achte ich nämlich gar nicht auf die
Notennamen und Oktaven etc., ich höre nur hin wie es klingt, und kann im Nachhinein
gar nicht sagen welche Noten oder Harmonien ich da verwendet habe.
Eine Vorbereitungsmaßnahme für diesen Musikstück-Darsteller wäre, dass man im
Sample-Namen die Note vermerkt, welche das Sample tatsächlich auf C-3 spielt.
Meine Samples sind nämlich wild durcheinander getunet und nur so, dass sie
zusammen nicht schief klingen.
DOSferatu hat geschrieben:
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.
Das funktioniert aber prima, ich habe einfach die Variablen gepusht, "word ptr" davor war nicht nötig.
Für eine asm-Routine ohne Stackrahmen setzt man wohl einfach entsprechende Register oder Variablen
vorher, wenn ich mich nicht irre. Eigentlich klar.
Zum Verständnis nur noch etwas: Wenn ich mir deine XPYDERZ.EXE mit ihren 166K ansehe, dann dünkt
es mir, dass man in Pascal mehr als 64K Code haben kann.
Aber dafür muss ja dann zwischendurch das Code-Segment geändert werden.
Geschieht das evtl. für jede TPU? Und wäre dann nicht jeder Funktionsaufruf aus einer TPU ein FAR Call?
DOSferatu hat geschrieben: IF-Kaskaden kann man unter anderem mit sogenannten Entscheidungstabellen verhindern.
Kann das bei Bedarf gern mal genauer erklären.
Ich habe das bei ZVIDVIEW auch schon umgesetzt, allerdings nicht mit Sprüngen sondern
mit CALLs. Ich weiss nicht genau was schneller ist, Sprünge oder eben CALLs.
Für einfache Sprünge anhand Entscheidungstabellen fehlt mir das Wissen, wie
man die Adressen von Labels innerhalb von asm Anweisungen ermittelt.
Bzw. wie man einen JMP formuliert, der nicht an ein Label sondern an eine
Adresse springt, die sich z.B. in einem Register befindet.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von zatzen »

Du erwähntest noch das Programmieren der AdLib Karte.
So schwierig ist das gar nicht, für mich war es leicht weil man nichts mit Samples
und Software Mixing zu tun hat. Also reicht es, wenn man keine Portamento-Effekte
machen will, wie auch bei meinem ZSM, nur jede neue Zeile einen Befehl zu senden.
Der FM-Synthesizer verlangt ca. einen dutzend Parameter pro Stimme, aber da bekommt
man nach kurzer Übung schnell brauchbare Sounds hin.
Ich habe 1995 einen simplen Tracker in QuickBASIC geschrieben, die Musik habe
ich in Kotzman II benutzt.
Das einzig dumme an der AdLib ist, zumindest so wie sie in dem Buch beschrieben
wurde, dass man für bestimmte Register ein Delay einarbeiten muss, weil die
Daten sonst nicht richtig ankommen. Und ich hatte dann auch noch das Problem,
dass es beim ändern der Parameter für einen Kanal zu Soundmüll kam wenn
man das zwischendurch machte, bzw. habe ich damals auch die Delays so
eingeschätzt, dass sie sich nicht in den Ablauf eines Musikstücks integrieren
lassen. Deshalb habe ich für jeden Kanal nur einen festen Klang definiert.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von DOSferatu »

zatzen hat geschrieben:Dabei fehlt mir noch das Know-How über CRC32, was ich gerne verwenden würde um z.B.
anhand der Patterndaten die Musikstücke eindeutig identifizieren zu können.
Ich habe noch nicht sonderlich viel dazu recherchiert, bis jetzt scheint mir:
- zu prüfende Daten kann man als eine seeeehr große Zahl verstehen,
die man durch das 32 (oder 33?)- Bit Polynom dividiert.
- das ganze passiert in der Praxis schrittweise durch Shiften und XOR
- Der Divisionsrest ergibt die Prüfsumme (?)
Ja, so in der Art. In der Praxis verwendet man da eine Tabelle mit 256 DWord-Werten.
Ich kann Dir mal ein Programmbeispiel zeigen.
zatzen hat geschrieben:
DOSferatu hat geschrieben:Ja, wie gesagt: Es eilt nicht. Daß ich meine Programme hier präsentiere verpflichtet nicht zur Benutzung.
Es wäre aber mal ganz spannend, ISM komplexe Musik spielen zu hören.
Ja, für mich auch.
zatzen hat geschrieben: Dass ich mich in prISM noch nicht so gut zurechtfinde und man dort nicht einfach so drauflos
improvisieren kann ist allerdings eine Hürde. Statt eines Converters von Tracker nach ISM
wäre ein Tool sinnvoll, welches meine Trackerstücke analysiert und mir das ganze auf eine
übersichtliche Weise darstellt, was ich mir dann z.B. ausdrucken könnte, um es dann in
prISM unter Benutzung aller Möglichkeiten einzuprogrammieren.
Naja, wie gesagt: ISM/prISM ist eigentlich nicht so sehr für Samples ausgelegt - während die normalen, "MOD"-artigen Tracker ja ausschließlich mit Samples arbeiten - teilweise mit leider viel zu großen Samples.
Ja, ich weiß: Samples sind nicht zu groß, solange 15 oder 31 Samples zusammen in die unteren 640 kByte passen... ABER: ISM ist zur Verwendung in Spielen gedacht. Spiele haben außer Musik auch noch Grafik, Steuerung und eine Menge "Drumherum", das dann ebenfalls noch in den Speicher passen muß und ich für meinen Teil bin NICHT bereit, 80%-90% des Speichers für große lange Samples bereitzustellen, so daß sich alles andere zusammen dann 50 bis 60 kByte teilen müßte.
Um "Real-Mode" (16-bit) Spiele zu machen, muß JEDER Bereich sparen: Meine Grafiken, mit ihrer 4-Bit-Option, meine Steuerung, die über ASM-artigen Bytecode in einer in 100% ASM programmierten VM erfolgt und eben auch Musiken/Soundeffekte, die mit Synthesizing und allemal kleinen Samples arbeiten sollten.

Das heißt natürlich nicht, daß man mit ISM nicht auch größere "standalone" "Musikprojekte machen könnte/sollte.

Und, wie bereits erwähnt: Mit den Einfg/Entf-Tasten sollte das "Improvisieren" dann einfacher gehen.
zatzen hat geschrieben:Wenn ich etwas im Tracker "komponiere", dann achte ich nämlich gar nicht auf die
Notennamen und Oktaven etc., ich höre nur hin wie es klingt, und kann im Nachhinein
gar nicht sagen welche Noten oder Harmonien ich da verwendet habe.
Naja - ich muß immer alles berechnen, anders traue ich dem Frieden nicht --- obwohl die normale "Tracker"-Ansicht natürlich auch etwas für sich hat - man sieht die Töne nebeneinander und wann sie einsetzen. Allerdings sind im "normalen MOD" Wiederholungen nur dann möglich, wenn sie gleichzeitig alle Stimmen betreffen und - mal abgesehen von den "ein Pattern in der Mitte starten/unterbrechen" Sub-Befehlen - nur auf ganze Patterns bezogen.
Was besser oder schlechter ist, läßt sich schwer beurteilen - wahrscheinlich die "MOD-Variante", weil so viele Leute sie seit Jahrzehnten erfolgreich benutzen ... - manche allerdings vielleicht auch, weil es die einzige Variante ist, die sie bisher kennen.

ISM ist eben ein komplett anderer Ansatz - und ja, mir ist bewußt, daß mit Trackern erfahrene Musiker hier eventuell Schwierigkeiten haben könnten. Aber siehe dazu meinen nächsten/neuen Beitrag.
zatzen hat geschrieben:Zum Verständnis nur noch etwas: Wenn ich mir deine XPYDERZ.EXE mit ihren 166K ansehe, dann dünkt
es mir, dass man in Pascal mehr als 64K Code haben kann.
So ist es.
zatzen hat geschrieben:Aber dafür muss ja dann zwischendurch das Code-Segment geändert werden.
Genau!
zatzen hat geschrieben:Geschieht das evtl. für jede TPU?
Jein. Man kann einstellen, ob es für jede TPU passiert oder diese auch "gruppieren", d.h. Pascal sucht dann aus, was noch alles in das gleiche Segment paßt.
zatzen hat geschrieben:Und wäre dann nicht jeder Funktionsaufruf aus einer TPU ein FAR Call?
Soweit ich weiß, schon (außer vielleicht, wenn alles in's gleiche Segment compiliert werden konnte).
Das "Problem" ist hier, daß eine Subroutine einer TPU ja "von überall im Programm" aufrufbar sein muß, auch von Stellen, die "zu weit entfernt" für einen near call sind. Man kann eine Subroutine aber leider nicht so programmieren, daß sie sowohl als near als auch als far aufgerufen werden kann - das liegt an den verschiedenen RET-Befehlen am Ende. Der "near RET" holt ja nur den Offset zurück (geht ins gleiche Segment), der "far RET" holt den Offset und das Segment. Selbst WENN man einen Mechanismus an's Ende einer Routine (procedure/function) manuell bastelt, der dann entscheiden würde, ob near oder far, muß die Routine ja auch WISSEN, als was sie aufgerufen wurde, um am Ende entsprechend zurückzuspringen.
D.h. man müßte der Routine das beim Aufruf mitteilen und am Ende wäre dann eine Entscheidung (evtl auch mit bedingten Sprüngen), die das ganze managt. --- Ob man DAMIT dann die Zeit rausholen würde, die einem durch den FAR CALL (statt NEAR CALL) "verlorengeht", wage ich ernsthaft zu bezweifeln.

Anmerkung: Mit dem Compilerschalter $G kann man die "Gruppierung" anschalten und die Units nennen, die zur gleichen "Gruppe" gehören sollen (funktioniert natürlich nur so lange, wie alle aus den entsprechenden Units eincompilierten procedures/functions in ein Segment passen). Diese Segmentgrößen werden mit $S festgelegt (default ist 16 kByte).
Dazu einmal mal die Hilfen zu $G und $S in Pascal aufrufen, jeweils die erste (also "Unitsegmente gruppieren" und "Segmentgröße").
Diese Schalter haben noch eine zweite Funktion, wenn man sie mit direkt folgendem + oder - benutzt (286er-Code generieren und Stack-Prüfung), das hat mit diesem Gruppieren nichts zu tun.
zatzen hat geschrieben:
DOSferatu hat geschrieben: IF-Kaskaden kann man unter anderem mit sogenannten Entscheidungstabellen verhindern.
Kann das bei Bedarf gern mal genauer erklären.
Ich habe das bei ZVIDVIEW auch schon umgesetzt, allerdings nicht mit Sprüngen sondern
mit CALLs. Ich weiss nicht genau was schneller ist, Sprünge oder eben CALLs.
CALLs sind natürlich etwas langsamer als Sprünge, weil bei CALLs der "Ausgangspunkt" vorher
auf den Stack gesichert wird, was bei Sprüngen entfällt. Sprünge "wissen" dafür nicht mehr,
wo sie hergekommen sind. Wenn die "Ziele" (also wohin gesprungen wird) immer nur von
einer einzigem Stelle aus angesprungen werden, ist ein kombinierter Sprung und Rücksprung
besser/schneller als ein CALL.

Anmerkung: Ich habe "Doppelrücksprünge" schon öfters mit PUSHs gelöst (z.B. benutze ich das öfter in GAMESYS).
Erklärung: Man springt irgendwo hin, innerhalb dieser Untersektion werden verschiedene CALLs
durchgeführt, die irgendetwas tun. Ist das letzte, was diese "Untersektion" macht, ebenfalls ein CALL und danach
folgt gleich ein Sprung oder Rücksprung zu X, habe ich das statt so:

Code: Alles auswählen

CALL Beispiel; JMP X;
so gelöst:

Code: Alles auswählen

PUSH CS:offset X; JMP Beispiel;
(der obige CALL ist in dem Fall ein NEAR CALL).
Was passiert? Ich lege die Rücksprungadresse auf den Stack. Und anstatt Beispiel zu "CALLen", springe ich nur dahin.
Am Ende von Beispiel (die ja eigentlich eine Subroutine ist, die einen CALL erwartet), ist ein RET. Und dieser RET holt sich dann X vom Stack und springt zurück. Somit habe ich mir einiges an Sprüngen/Aufrufen eingespart.
zatzen hat geschrieben:Für einfache Sprünge anhand Entscheidungstabellen fehlt mir das Wissen, wie
man die Adressen von Labels innerhalb von asm Anweisungen ermittelt.
Bzw. wie man einen JMP formuliert, der nicht an ein Label sondern an eine
Adresse springt, die sich z.B. in einem Register befindet.
Labeladresse in ein Register laden:

Code: Alles auswählen

mov BX,CS:offset @labelname;
Wenn es um eine "dynamische" Adresse geht, die erst zur Laufzeit des Programms (also nicht
während des Compilierens) bekannt ist, hilft natürlich LEA:

Code: Alles auswählen

lea BX,irgendwas;
Vor "irgendwas" setzt man dann das Segmentpräfix für das gewünschte Segment. lea ermittelt dann den Offset, den "irgendwas" zum Segment hat. Oder anders ausgedrückt: Wenn man

Code: Alles auswählen

lea BX,CS:@irgendwas;
benutzt, steht danach in CS:[BX] die Adresse, wo @irgendwas anfängt. Ich weiß gerade nicht, ob hier ein Fehler ausgelöst wird, falls sich @irgendwas nicht gar nicht im Segment (also in den 64kByte ab Segmentanfang) befindet oder nicht.
zatzen hat geschrieben:Du erwähntest noch das Programmieren der AdLib Karte.
So schwierig ist das gar nicht, für mich war es leicht weil man nichts mit Samples
und Software Mixing zu tun hat. Also reicht es, wenn man keine Portamento-Effekte
machen will, wie auch bei meinem ZSM, nur jede neue Zeile einen Befehl zu senden.
Der FM-Synthesizer verlangt ca. einen dutzend Parameter pro Stimme, aber da bekommt
man nach kurzer Übung schnell brauchbare Sounds hin.
Mir geht es da weniger um die Programmierung/Ansteuerung der AdLib Register.
Und diese Warteschleifen-Problematik habe ich auch schon gelöst. Aber ich als
Formel-Mensch komme mit diesen komischen Dingen, wo ich aus zwei kombinierten
Sinuswellen einen Klang generieren soll, nicht klar - da habe ich keinen Nerv dafür,
wie ich mir dann daraus sowas unnatürliches wie Dreieck-/Rechteck-/Sägezahnwellen
basteln könnte, das ist mir zu kraß. Dafür müßte ich mir wohl ein Tool bauen.
zatzen hat geschrieben:Ich habe 1995 einen simplen Tracker in QuickBASIC geschrieben, die Musik habe
ich in Kotzman II benutzt.
Das einzig dumme an der AdLib ist, zumindest so wie sie in dem Buch beschrieben
wurde, dass man für bestimmte Register ein Delay einarbeiten muss, weil die
Daten sonst nicht richtig ankommen. Und ich hatte dann auch noch das Problem,
dass es beim ändern der Parameter für einen Kanal zu Soundmüll kam wenn
man das zwischendurch machte, bzw. habe ich damals auch die Delays so
eingeschätzt, dass sie sich nicht in den Ablauf eines Musikstücks integrieren
lassen. Deshalb habe ich für jeden Kanal nur einen festen Klang definiert.
Ja, das ist ein bekanntes "Problem". Oft wurden solche Dinge früher[tm] auch entweder
GAR NICHT eingebaut (weil die Rechner so langsam waren, daß diese Wartezeit
allein schon durch den Abstand zweier Befehle alleine erreicht wurde) oder mit
Warteschleifen - die auf zu schnellen Rechnern dann Über- oder Unterläufe
produzierten (ja, wir ALLE kennen die besagten Spiele, die man dann im SlowMode
laufen lassen muß, weil sie sonst mit Fehlermeldung aussteigen und selbst im
Slow hat man dann wenn man Pech hat, noch diese schicken "hängenden Noten"...)

Aber gut - genug erstmal davon. In meinem nächsten Beitrag geht es wieder um ISM/prISM...
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von DOSferatu »

Neu: prISM v0.10 jetzt offiziell auf meiner Website freigegeben!
http://www.imperial-games.de
Dort in Sektion MS-DOS, dann in Sektion Tools prISM suchen.
Direkter Link: http://www.imperial-games.de/html/dosa27.htm
(Der direkte Link kann sich ändern, da neue Tools hier immer alphebetisch einsortiert werden.)

Es gab noch einige kleinere Änderungen am Code von ISM, aber viele Änderungen an prISM !

Die auffälligste Änderung ist das Tutorial (englisch und deutsch), das quasi die ganze Zeit in der untersten Zeile eingeblendet sein kann und das schrittweise an die Arbeit mit prISM heranführt - zuerst mit den einfachsten Befehlen, die komplexeren werden später erklärt, alles auch teilweise anhand von Beispielen zum Selbermachen.

Damit habe ich mir viel Mühe gegeben und sehr viel Zeit aufgewendet.
Und vielleicht hilft es dem einen oder anderen, prISM / ISM am Ende doch noch etwas zu mögen.

Achja, noch etwas: Es besteht ebenfalls die Möglichkeit, die in prISM enthaltenen Texte auszudrucken - mit dem Programm ISMPRINT, das sich dafür nur im gleichen Verzeichnis wie prISM befinden muß.
Das Tutorial sieht ausgedruckt natürlich etwas "kompakt" aus, da es ja eigentlich für die zeilenweise Anzeige in einer einzigen Bildschirmzeile konzipiert ist. Vielleicht baue ich noch einen Modus ein, der das Ganze nach Sätzen trennt und entsprechende Absätze macht - mal sehen.

Über Feedback zu prISM und den neuen Features (hauptsächlich neu ist das Tutorial) würde ich mich selbstredend wie immer freuen. Aber ich weiß natürlich, daß man auch noch andere Verpflichtungen hat als krude privatgemachte Fremdsoftware zu testen/nutzen.

Trotzdem viel Spaß damit.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von zatzen »

Mir ist aufgefallen, dass PRISM.EXE 643 KB groß ist.
Das passt ja eigentlich gar nicht in den Speicher.
Und mir wäre auch ein Rätsel wie ein Programm kompiliert so
groß werden würde, da müsste man ja Monate lang Code schreiben...
Vielleicht hast Du an die Datei etwas angehängt,
oder irgendwie etwas darin verlinkt. Oder für verschiedene
Konfigurationen den Code eher redundant mehrmals kompiliert,
so dass beim Start nur ein Teil der EXE geladen wird.
Ich kenne mich in dem Bereich nicht (mehr) so aus, aber es wäre
interessant zu erfahren, wie Du es schaffst, solche großen EXE Dateien zu machen.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von DOSferatu »

zatzen hat geschrieben:Mir ist aufgefallen, dass PRISM.EXE 643 KB groß ist.
Das passt ja eigentlich gar nicht in den Speicher.
Am Anfang von DOS-EXEn steht ja immer, wieviel Speicher sie belegen. Nur das wird von DOS geladen - egal, ob man zusätzlich etwas anhängt.
zatzen hat geschrieben:Und mir wäre auch ein Rätsel wie ein Programm kompiliert so groß werden würde, da müsste man ja Monate lang Code schreiben...
Eher Jahrzehnte... Immerhin enthält prISM auch einige meiner Units, die ich über die letzten 20 Jahre entwickelt habe.
zatzen hat geschrieben:Vielleicht hast Du an die Datei etwas angehängt,
Selbstverständlich.
Wenn man sich mal XPYDERZ anschaut, ist zusätzlich zu XPYDERZ.EXE ein ziemlich großes File namens XPYDERZ.FSY im selben Verzeichnis - dies enthält alle möglichen Daten für das Spiel. Die von mir entwickelten *.FSY Files kann man sich so vorstellen wie die *.WAD-Files bei DOOM[tm] und ähnlichen. Es ist quasi ein kleines "Filesystem im File", das verschiedene Files enthält, wahlweise auch gepackt und/oder verschlüsselt. Meine File-Unit kann diese lesen, als wären es normale Files - sie entpackt auch gleich beim Lesen (und packt beim Schreiben), so daß es für das Programm aussieht, als würde man das File "in Reinform" lesen/schreiben. Die neuere Version meiner File-Unit erlaubt nun auch, diese FSY an eine EXE anzuhängen und trotzdem von dort lesen zu können. So muß die EXE nicht immer ein zusätzliches FSY "mitschleppen", sondern es ist gleich an der EXE dran. Das ist die ganz Magie dahinter.
zatzen hat geschrieben:oder irgendwie etwas darin verlinkt.
Ja, prISM selbst lädt aus diesem Anhang verschiedene Sachen. So muß nicht immer alles im Speicher gehalten werden, was gerade nicht gebraucht wird.
zatzen hat geschrieben:Oder für verschiedene Konfigurationen den Code eher redundant mehrmals kompiliert, so dass beim Start nur ein Teil der EXE geladen wird.
Das eher nicht.
zatzen hat geschrieben:Ich kenne mich in dem Bereich nicht (mehr) so aus, aber es wäre interessant zu erfahren, wie Du es schaffst, solche großen EXE Dateien zu machen.
Während ich an der EXE arbeite (in der Entwicklungsumgebung) liegen diese ganzen Files einfach im Verzeichnis herum. Ich gestalte meine EXEn dann so, daß sie im Entwicklungsmodus die Files normal aus dem Verzeichnis lesen und wenn sie als "Compilat" auf die Reise gehen, dann aus dem angehängten Overlay.
Die ganzen Files da einzeln zu packen, so daß nach dem Entpacken dann ein ganzes Verzeichnis voller kryptischer Datenfiles herumliegt, das war nie so meins - daher bin ich froh, daß ich vor etwas über 15 Jahren mein FSY erfunden habe und vor 6 oder 7 Jahren dann noch die Option, es gleich an die EXE zu hängen.

Die PRISM.EXE selbst ist nur etwas über 188 kByte groß - der Anhang enthält z.B. die ganze Hilfe/Tutorial und die Skripte, um die Befehle/Parameter darzustellen, außerdem die Texte _ISM.TXT und _ISMFILE.TXT, die quasi das "Datenblatt" für ISM sind.

Wie ich ja bereits erwähnte, habe ich hier unzählige nützliche Programme und Units herumliegen, die ich nur noch einzusetzen brauche, falls nötig. Auf diese Art kann ich kleinere Tools oft in wenigen Stunden zurechtzaubern.

Und auch diese Tools selbst sind oft ganz hilfreich und brauchbar.
Außer mir selbst will das Zeug ja keiner haben oder benutzen - teilweise natürlich, weil viele (genau wie ich) eher auf selbstgemachtes Zeug vertrauen und daher nicht mit Fremdsoftware oder Fremdcode herumbauen wollen.

Und teilweise wohl auch, weil man sich dazu eventuell auf meine selbstentwickelten Formate oder Schnittstellen einlassen müßte - was wohl auch zuviel Mühe ist/wäre für jemanden, der da quasi "neu dazukommt".

@Alle:
Momentan arbeite ich übrigens gerade an meinem "Spiel-Rahmen" - also ein generalisiertes Stück Code, das (wahlweise) alle meine (für Spiele geeigneten) Units benutzt/Formate unterstützt. Hier werden auch gleich die Schnittstellen zwischen den einzelnen Teilen automatisch eingebunden und müssen nicht extra vom Programmierer jedesmal neu manuell "verbunden" werden.

Das wird dann sozusagen das "Grundgerüst" für meine künftig geplanten Spiele. Und ja, ich weiß, daß das Ganze schon sehr nach "Game-Maker" aussieht - aber es wird immer noch compiliert werden. Es wird also keine "generalisierte" EXE, die als Spiel dann den jeweiligen Datenklotz mit sich schleppt. Ich will bei alledem trotzdem flexibel bleiben und mir die Option, zusätzliche Dinge einzubauen, jederzeit offenhalten. Diese "zusätzlichen Dinge" sind es erst, die ein Spiel "besonders" machen. Game-Maker Spiele neigen irgendwann dazu, "alle gleich auszusehen". Will sagen: Sowohl ein Xpyderz, ein R-Type, ein Turrican, ein Zelda oder ein Maniac Mansion werden noch gleichermaßen möglich sein.

(Und ja, ich habe auch meine (alten) 3D-Routinen hier. Sollte ich die erstmal in 100% Assembler umsetzen, dann wären auch DOOM[tm]-artige Levels möglich... - aber das ist noch Zukunftsmusik.)

Inzwischen habe ich alles beisammen, was ich für ein gescheites Arcade-2D-Spiel im Stile der NES / SNES-Ära brauche (sowohl Tools als auch Units). An sich eine nette Sache, finde ich. Und für viele Leute, die viele Spielideen haben, gerne mal ein Spiel machen wollten, aber an Dingen wie Sprites, Scrolling, Steuerung, Kollisionsabfrage, Klanggeneration/-ausgabe usw. scheitern, könnte das wohl eigentlich ein Fest sein - sollte man vielleicht meinen...

In Wirklichkeit kann man natürlich heutzutage mit Spielen, die lediglich unter DOS/DOSbox oder bis max. WinXP laufen, kaum noch Ruhm/Ehre/Geld gewinnen und außerdem macht ein Spiel zu entwickeln, selbst wenn 95% der nötigen Programmierung jemand anderes getan hat, immer noch Mühe - denn Levels/Grafiken/Musiken/Steuerskripte etstellen sich auch nicht von alleine. Und so wie ich es sehe, hat kaum jemand ein wirkliches Interesse bzw. übrige Zeit, um an einem selbstgemachten DOS-Spiel mitzuwirken...

Schon damals[tm] vor über 15 Jahren gab es viele Leute, die "prinzipiell" schon gern an einem Spiel mitgemacht hätten, nur hatten sie gerade nie Zeit. Ihren Namen als "Ideengeber" unter dem fertigen Produkt hätten sie natürlich trotzdem gern gelesen. - Nur: Ideen habe ich selbst - ich habe so viele davon, daß ich 3 Leben bräuchte, um die alle umzusetzen. Quasi von allem was ich für ein Spiel brauche, sind das allerwenigste neue Spielideen. Grafiker / Musiker / Levelbauer wären viel eher gefragt - aber so etwas artet ja auch irgendwie in Arbeit aus...

Kurzum: Sobald der "Rahmen"/das "Gerüst" (Arbeitstitel: SLOT - und ja, mal wieder ein Wortspiel) fertig ist (kann sich nur noch um Wochen handeln), schmeiße ich mich auf die Bastelei meines ersten Spiels "der neuen Art".
Meine Prognose: Wenn es fertig ist, werden es wohl maximal 10 Leute (Schätzung nach oben aufgerundet) herunterladen, 5 Minuten anspielen, 3 davon werden etwas sagen wie "Ja, ganz nett." und das war's. Da kann ich echt froh sein, daß das ein Hobby ist und es mir mehr ums "Machen" geht als um alles andere...

Ja, manche halten Leute wie mich deshalb für verrückt oder schlagen vor, daß ich so Zeug lieber für ANDROID u.ä. machen soll (wegen des größeren Publikums und der Verdienstmöglichkeiten). Das sind wohl auch Leute, die nie verstehen werden, daß man Dinge auch einfach aus Spaß an der Sache machen kann, ohne eine zusätzliche Belohnung (Ruhm/Geld) zu brauchen und daß, wenn etwas nach mühsamer Arbeit funktioniert und es so geworden ist wie man dachte (oder vielleicht sogar besser), so etwas Belohnung genug sein kann. Natürlich freut es einen, gerade wenn man ein SPIEL macht, wenn möglichst viele Leute es auch spielen - denn das ist ja der eigentliche Zweck. -

Aber in der heutigen schnellebigen Zeit, wo kaum noch jemand Zeit hat oder sich ausreichend Zeit für etwas nimmt, wo alles gleich und sofort da sein und gehen muß, da muß man natürlich auch verstehen, daß jedes neue "Produkt" (und dann auch noch privatgemacht) nur eines von Millionen ist und natürlich auch kaum jemand die Zeit und das Interesse hat, alles zu testen, "was da ist" - und hinzu kommt ja auch noch der große Kreis von Personen, die sich für (Computer-)spiele gar nicht interessieren und der ebenfalls große Kreis von Personen, für die jedes Spiel, das älter ist als 2 Jahre bzw. dem technischen Stand von vor mehr als 2 Jahren entspricht (oder auch 1 Jahr), alter Müll ist, der ist nicht wert ist, gestartet zu werden oder Festplattenplatz zu belegen.

Andererseits ist man als Spielemacher (im alten Stil) so auch in einer "bequemen" Lage: Niemand wartet auf dein Spiel, niemand drängelt dich, wann es endlich fertig ist - im Gegenteil: Sollte man wirklich mal etwas vorzeigbares/spielbares haben, muß man quasi die Leute damit schon aktiv belästigen und es ihnen quasi aufdrängen, damit jemand überhaupt Notiz davon nimmt. Ich überlege da jedes Mal, wie ich die Information, daß etwas Neues von mir da ist, formulieren soll, damit es als Hinweis und nicht als aufdringliche Werbung empfunden wird. Ist auch gar nicht so einfach...

OK, das soll's erstmal von mir gewesen sein für heute.

Hinweis zum Schluß (um wenigstens mal kurz On-Topic zu sein) :
prISM gilt in der vorliegenden Version als "vorläufig fertig". Alles, was damit hergestellt wird, wird in dieser Form auch in SLOT (s.o.) und ähnlichem verwendbar sein. Eventuell noch nachgelieferte Konverter oder vielleicht später hinzugefügte alternative Editor-Ansichten werden am Format nichts mehr ändern - mit Ausnahme des WFI (Filter) Befehls, der noch endgültig definiert wird, sobald Softwarefilter in ISM impementiert sind.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von zatzen »

Hallo!

Ich habe jetzt auch mal eine grobe ganz gute Idee für ein Spiel - die Ideen fehlten mir bisher im Gegensatz zu Dir...
Von meiner generellen Game-Engine bin ich erstmal wieder ab.

Ich möchte Dich nur wissen lassen dass ich Dir gerne als Musiker zur Verfügung stehe.
Musik machen lohnt sich für mich so oder so - ob es ins Spiel kommt oder nicht, oder
ob das Spiel ein Erfolg wird oder nicht. Also kein Risiko für mich aber volle Motivation.

Das einzige Problem ist nur, dass ich nicht in prISM komponieren kann, und ich könnte
drauf wetten dass Du ISM gern in einem Spiel verwenden willst, wenn Du nun endlich
bald ein neues veröffentlichst.
Ansonsten, ich muss mich fast entschuldigen es in diesem Thread zu schreiben, kann ich Dir
kompakte Musik als ZSM anbieten, diese dürfte unter 64KB oder auch weniger bleiben können,
einziges Manko: SFX wären auch Samples, allerdings auch 4 Bit und wenn es nur eher Töne sind
die generiert werden sollen kommt man da auch mit so seltsamen Samplerates wie 1 kHz aus, da
würden 256 Byte schon für einen kurzen Soundeffekt reichen.
Du schriebst einmal, ZSM würde wohl besser performen als ISM, daher auch nur mein Angebot.

Ich sehe klar die Vorteile von ISM - wenn die Möglichkeiten ausgereizt werden hat es großes
Potential und ZSM wirkt steif dagegen. Im Zweifelsfall komponiere ich Musik auf meine Weise
und lasse sie Dir zukommen, damit Du sie in ISM programmierst - wenn Du das willst, wir hatten
über dieses Thema ja schon ewig lang geschrieben.


Bearbeitet: In erster Linie geht es mir um die Entscheidung, ISM oder ZSM.
Wobei ich absolut verstehe, wenn man lieber das eigene Format verwendet.
Das siehst Du ja an mir, auch wenn ZSM nur ein abgespeckter (naja immerhin max. 16 Kanäle)
MOD Player mit Speichersparenden Eigenschaften ist, wäre es mir ein Fest wenn mal
ein Spiel damit ausgestattet würde.
Aber genauso wird es Dir mit ISM gehen.
Also können wir es auch anders machen, wenn es mal soweit ist dass das Spiel Musik
bekommen soll: Ich kann mich dann auch näher mit prISM auseinandersetzen und Dir
die Arbeit des Einprogrammierens abnehmen, und nebenbei habe ich dann die künstlerische
Kontrolle über alle Klangparameter. Versprechen will ich es nicht, das hängt davon ab
wie gut und ob ich mit prISM klarkomme.
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von DOSferatu »

Ich hätte schon eher geantwortet - aber ich war die letzten Monate zwischendurch immer wieder mal mit etwas beschäftigt, das ich heute - vorläufig - "fertig"gestellt habe...
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Es schlägt 13! - prISM und AtavISM v0.13 jetzt draußen!

Beitrag von DOSferatu »

Es schlägt 13! - prISM und AtavISM v0.13 jetzt draußen!

prISM hat einen zweieiigen Zwilling bekommen: AtavISM - ein Programm basierend auf der gleichen Codestruktur, aber mit einer neuen Ansicht: Eine Eingabe im Trackerformat ist nun möglich! AtavISM nutzt dazu einen im "ISM-Code" geschriebenen "Daten-Container", umgeben mit einem vorgefertigten ISM-Programmcode, der es ermöglicht, Daten in fixen Sequenzen einzugeben - mit nebeneinanderliegenden Tönen und Abläufen für 1 bis 8 Stimmen.

AtavISM hat ebenfalls ein (mühsam über mehrere Tage geschriebenes) Tutorial in Englisch und Deutsch.

Das Format erlaubt im Sequenzer bis zu 64 Patterns und bis zu 64 Blöcke, die den einzelnen Patterns zugeordnet werden können (es wäre in der jetzigen Form auf bis 80 Patterns erweiterbar).

Der AtavISM-Daten-Container selbst belegt zusätlich ca. 2 kByte.

AtavISM beginnt mit Version 0.13, damit prISM und AtavISM, die künftig parallel weiterentwickelt werden, immer die gleiche Version haben.

Es ist problemlos möglich, AtavISM-Files in prISM zu laden und abzuspielen - allerdings wäre Editieren hier etwas umständlich, da der oben erwähnte "Programm-/Daten-Container" nicht zum Normalfall in prISM gehört.

Daten, die (ohne "Container") in prISM erstellt wurden, sind dagegen NICHT in AtavISM ohne Weiteres nutzbar - hier müßte ein Konverter die Daten an das "Containerformat" anpassen. Ein solcher Konverter existiert derzeit nicht.

AtavISM enthält einige "intelligente" Subroutinen, die quasi "live" automatisch die Daten intern anpassen und packen, sie nutzen intern sowohl die Möglichkeiten von Schleifen als auch von Unterprogrammen, die ISM bietet. Außerdem wird geprüft, ob Sequenz-Blocks identisch sind und diese dann nur einmalig gespeichert.

Ich hatte ja gesagt, dass ich, sobald ich eine Idee für eine entsprechende Umsetzung habe, diese verwirklichen könnte. Nun ist die Idee sogar besser geworden als ich dachte - da man nun keinen anschließenden Konverter benötigt, der die "Trackerdaten" von AtavISM für ISM umwandelt, sondern in AtavISM live die Musiken abspielen kann.

Eine weitere Neuerung ist das "Instr" Untermenü, das sowohl in prISM als auch in AtavISM verfügbar ist, mit dem "Instrumente" im Vorfeld konfiguriert werden können. Hier ist es möglich, die Hüllkurven-Phasen (Attack/Decay/Sustain/Release) und die kombinbierten Wellenformen einzustellen (Ergebniswelle wird angezeigt) - für 128 "Instrumente" (digitale Klangsynthese), sowie die Dauer der einzelnen Phasen (für alle Instrumente). Außerdem kann hier ein Samplepfad (wo die Samplefiles liegen) angegeben werden, sowie auch einzelne Filenamen für Samples, falls sie vom Standardnamen (z.B. SAMPLE??.ISM) abweichen - für bis zu 256 Samples - wobei in AtavISM aber nur maximal 127 benutzt werden können (so viele Samples werden ohnehin kaum genutzt werden, weder in prISM noch in AtavISM - schon allein, weil der verfügbare Speicher hier Grenzen setzt).

AtavISM zeigt 8 Stimmen nebeneinander an, dabei hat jede Stimme 3 Spalten. In der ersten Spalte wird das Instrument angegeben (00-7F = Instrument digitaler Klangsynthese, 80-FE = Sample (0-7E)), d.h. das oberste Bit entscheidet, ob "Instrument" oder Sample. Die mittlere Spalte ist ausschließlich für die Noten gedacht, wird hier nichts eingetragen, bedeutet das, die Note weiterzuführen - d.h. ein Eintrag ist ein neuer Anschlag eines Tons, die "Leerräume" bestimmen die Länge - so wie es von Trackern bekannt ist. (Daß es intern auf ISM-Befehlssequenzen "umgerechnet" wird, ist unerheblich. - Man kann übrigens sogar am rechten Bildschirmrand dezent angedeutet sehen, wie die jeweils aktive Stimme in ISM-Code aussieht.) Die rechte Spalte ist für jegliche "Sonder-" befehle gedacht. Um erweiterbar zu sein, sind hier diese Zeichen erlaubt: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

Benutzt werden davon derzeit: 0123456789ABCDEF - Lautstärke einstellen $0 bis $F (0 bis 15) M - Stille (für den Zeitraum statt einer Note. Es kann trotzdem eine Note angegeben werden, da diese auch für Portamento benutzt werden) P - Portamento (gleiten von einer Note zur nächsten) R - Release (leiser werden, mit dem Release-Wert für "Instrumente", über die Gesamtlänge für Samples) U - Transponieren hoch (Wert in Halbtönen wird in der "Instrument"-Spalte angegeben, Instrument/Samplewechsel hier nicht möglich) V - Transponieren runter (Wert in Halbtönen wird in der "Instrument"-Spalte angegeben, Instrument/Samplewechsel hier nicht möglich) (um auf Normalwert zu setzen, muß 00 angegeben werden)

Als Hilfe werden alle Buchstaben als Kleinbuchstaben dargestellt, die noch keine zugewiesene Funktion haben. Für Vorschläge für neue Funktionen bin ich offen - intern werden diese dann - FALLS MÖGLICH - in ISM-Codesequenzen umgesetzt.

Neuerungen in prISM: Auch prISM, das ursprüngliche Programm, hat einige Neuerungen erfahren: Das obengenannte Menü "Instr" ist auch in prISM verfügbar. Ebenfalls gab es einen kleinen Bugfix in ISM (betraf nur eine nicht im "Normalbetrieb" genutzte Funktion, die aber für AtavISM wichtig war). Außerdem wurde das Tutorial nochmals überarbeitet.

Ich wäre gespannt, ob mit dem neuen AtavISM einige der "Tracker-Musiker" hier arbeiten können/wollen. Hinweis: Einige Dinge, die den ISM-Befehl "HLD" betreffen, scheinen im Zusammenhang mit Samples noch etwas zu haken. Der HLD-Befehl wird in AtavISM desöfteren eingesetzt, um Änderungen an Tönen ohne neuen Anschlag zu verwirklichen (wie es der eigentlich Einsatzzweck von HLD ist). EVentuelle Fehler/Auffälligkeiten in der Arbeitsweise von prISM/AtavISM können jederzeit an mich gemeldet werden - diese Dinge werden entsprechend geprüft und, falls möglich, beseitigt/bereinigt.

Alternativ möglich wäre eine Ansicht mit 4 Spalten pro Stimme (damit man die erste Spalte nicht als Parameterlieferant für Portamento nutzen muß). Dann wären immer nur 7 Stimmen gleichzeitig sichtbar (außer in den höheren Grafikmodi), und man müßte hin und her scrollen.

Bisher hat AtavISM keine Möglichkeit, mehr als 8 Stimmen zu bedienen - das liegt daran, daß auch ISM auf 8-stimmige Musik ausgelegt ist. Man kann zwar prinzipiell 16 Stimmen benutzen, aber die anderen 8 Stimmen sollen für Klangeffekte vorgesehen bleiben (für Spiele).

Das heißt: Bis auf weiteres wird in AtavISM keine 16-stimmige Musik möglich sein. In prISM dagegen kann 16-stimmige Musik benutzt werden, weil man hier die "programmatische" Aktivierung der Stimmen umgehen kann. AtavISM dagegen stellt quasi ein für dem Bediener unsichtbares "Framework" zur Verfügung (das intern aus ISM-Befehlen besteht), in das dann die sichtbaren Daten eingebettet sind.

Die Mausunterstützung in AtavISM ist noch mangelhaft - die Dinge, die auch in prISM funktionieren, gehen hier auch (Menüzeile, Pulldowns) - aber die Track-Fenster und der Sequenzer reagieren noch nicht auf Mausklicks. Das wird in kommenden Versionen noch ergänzt.

Eventuell schreibe ich noch einen "Finisher", der ein fertiges AtavISM-File etwas verkleinert (unbenutzte Bereiche entfernt usw).

Achja: Zu finden hier: http://imperial-games.de/html/dosa28.htm
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

AtavISM v0.14 mit Piano-Modus

Beitrag von DOSferatu »

AtavISM v0.14 mit Piano-Modus.

Falls es jemanden interessieren sollte: AtavISM - das "Schwesterprogramm" von prISM - ist in Version 0.14 draußen!
(prISM hat ebenfalls Version 0.14, - hier sollten aber keine Änderungen sichtbar sein, da nur an AtavISM weitergearbeitet wurde. Es werden nur beide Tools mit gleicher Version weitergeführt.)

Was ist neu?
Der Piano-Modus in AtavISM, der auch standardmäßig aktiviert ist (kann mit F12 umgeschaltet werden auch den normalen Modus).
Der Piano-Modus ähnelt in der Bedienung der Bedienung des X-Trackers - auch wenn natürlich lange nicht die komplette Funktionalität des X-Trackers vorhanden ist. Bestimmte Dinge, die im ursprünglichen (jetzt "Notes" genannten) Modus vorhanden sind, funktionieren nicht bzw. anders im Piano-Modus. Im Einzelnen sind das:

1.) YXCVBNM, SDGHJ, QWERTZU, 23567 funktionieren jetzt als "Klaviertasten" für zwei übereinanderliegende Oktaven (jeweils "weiße" und "schwarze" Töne), wenn man sich in der Trackeransicht befindet (natürlich nicht in den Menüs, wo sie zur Bedienung/Eingabe gebraucht werden). Nach Eingabe einer Note wird zur nächsten Zeile (oder nächsten "Quantisierungs-"Zeile, siehe 7.) gewechselt.

2.) Die beiden Oktaven werden mit den Tasten , und . gewechselt. (Bedeutet auch: Sie stehen nicht mehr zum Scrollen der Tutorialzeile zur Verfügung. Hier sind jetzt Ö/Ä zu benutzen.)

3.) Die Taste links neben Y ( <>| ) und die Taste links neben Enter (#) haben beide die gleiche Funktion (Grund: Auf USA/UK Tastaturen gibt es die links-neben-Y-Taste nicht) : sie setzt den "Release"-Modus (R). Drückt man sie zusammen mit Shift, wird stattdessen "Mute" (Stille) gesetzt für diese Spur.

4.) P setzt den "Portamento" Effekt.

5.) Entf gibt eine Leerzeile ein und wechselt genauso wie die Noten in Quantisierungsschritten zur nächsten Zeile.

6.) Backspace löscht in einer Zeile alles außer der Note und springt in die nächste Zeile (unabhängig von "Quantisierung")

7.) F4 ruft jetzt ein kleines Fenster auf, in dem die "Quantisierung" eingegeben werden kann - dies ist der Zeilenabstand, zu dem nach Drücken einer "Notentaste" oder "Entf" gesprungen wird.

8.) Enter ruft jetzt ein Pulldown auf, in dem man die "Instrumente" oder Samples auswählen kann. Mit nochmals Enter werden sie direkt gesetzt. Drückt man in diesem Menü F4, wird automatisch das entsprechende (auch über Hauptmenü "Instr" erreichbare) Untermenü entweder für Instrument oder Sample aufgerufen, um es editieren zu können: Bei Instrumenten die Attack/Decay/Sustain/Release/Wellenformen/Faktor-Werte, bei Samples den Dateinamen/Pfad für die Samples. (Diese Menüs gab es auch schon in v0.13.)
(Anmerkung meinerseits dazu: ENTER/RETURN - die Taste, die eigentlich dazu da ist, jedes und alles zu bestätigen - für den Aufruf einer Subfunktion zu benutzen, ist meiner Meinung nach die blödeste Idee, die jemand im Design eines Programms hätte haben können. Aber ich habe es eben jetzt so wie im X-Tracker gemacht.)

9.) Strg+V (und, zur X-Tracker-Kompatibilität auch Alt+V) öffnet ein kleines Fenster, in dem die Lautstärke eingegeben werden kann. Mit Strg+W (bzw Alt+W) wird die zuletzt gesetzte Lautstärke erneut gesetzt. (Dadurch ist Values und Windows im Hauptmenü nicht mehr direkt erreichbar, man kann aber im Hauptmenü auch Hin-/Her wechseln. Vielleicht werden die entsprechenden Hotkeys in AtavISM noch durch Alt+A und Alt+N ersetzt).

10.) Mit Strg+S und Strg+I kann das zuletzt gewählte Sample bzw. zuletzt gewählte Instrument erneut gesetzt werden.

11.) Größte Neuerung: Wird eine Notentaste gedrückt, wird nicht nur die Note in den Track gesetzt, sondern die Note wird auch mit dem zuletzt gewählten Sample/Instrument abgespielt (für max. 2 Sekunden). Man kann diesen Klang auch vorher mit ESC stoppen. Diese Notentasten funktionieren auch in den Menüs, in denen Instrument oder Sample editiert werden können (siehe 8.) Es ist NICHT möglich, dies zu tun, während die restliche Musik gerade abgespielt wird.

12.) Um Zeilen eihzufügen oder zu löschen, wird jetzt statt Einfg/Entf mit Strg+Einfg/Strg+Entf gearbeitet. Das, und auch die andere Entf-Funktion führen dazu, daß im Piano-Modus die praktischen "Direkt-Tasten"-Kombinationen, um Kopieren/Verschieben/Einfügen zu setzen, deaktiviert sind. Diese müssen aus dem "Modify" (Alt+M) Menü ausgewählt werden.

Anmerkungen:
a.) Bisher wurde nichts dazu gesagt, wie vorgegangen werden soll, wenn beim Drücken der Notentasten das Ende eines Tracks erreicht wurde. Hier verbleibt der Cursor auf der letzten Trackzeile. (Theoretisch wäre z.B. ein Wechsel in das nächste im Sequenzer eingestellte Pattern möglich.)

b.) Desweiteren gibt es derzeit noch keine Unterstützung für variable Patternlängen. Hierzu gibt es auch noch keine Tasten oder Menüs. (Habe nie mit X-Tracker gearbeitet. AtavISM kann außerdem kein vollständiger Ersatz eines anderen Trackers sein - und soll es auch nicht.)

c.) Das Kopieren eines kompletten Patterns über mehrere Spalten hinweg (wie in X-Tracker mit F7/F8-Markierung) ist derzeit nicht eingebaut. Mal sehen, ob das noch kommt. Einzelne Spalten (oder Teile davon) können aber wie gewohnt markiert/kopiert werden.

Vielleicht kann man (zatzen) jetzt damit arbeiten - obwohl ich es immer noch nicht glaube...
Hier ist die neue Version zu finden:
http://www.imperial-games.de/html/dosa28.htm
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von DOSferatu »

Und, kurz vor Weihnachten habe ich es (dank Urlaub) endlich "fertig"gestellt bekommen.
(Wie "fertig" es wirklich ist, wird dann sicher zatzen feststellen.)
prISM und AtavISM Version 0.15 ist da!

Langer Rede kurzer Sinn... kommen wir zu den Neuerungen gegenüber der letzten Version:

1.) Das Wechseln der Sequenzerblöcke (wo die Patterns liegen), geht jetzt, zusätzlich zu CTRL_N und CTRL_M, was vorher schon ging), auch mit den - / + Tasten des Ziffernblocks. Wird mit Ziffernblock gewechselt (nur bei +), wird am Ende des Sequenzers ein neuer Sequenzerblock angefügt - außer, die maximale Anzahl 64 (40hex) ist bereits erreicht.
Es wird auch immer unten das im Sequenzerblock liegende Pattern angezeigt.

2.) Zusätzlich dazu, daß Einfg/Entf jeweils Zeilen hinzufügen/löschen, wurde noch die Funktion hinzugefügt, daß mit Shift_Einfg/Shift_Entf nicht nur eine Zeile hinzugefügt/gelöscht wird, sondern sich auch die Länge des Patterns ändert. Die maximale Größe 64 Zeilen (40hex) wird natürlich nicht überschritten - minimale Größe ist 1. Wenn Spuren/Stimmen hinzugefügt oder entfernt werden, werden die entsprechenden Anpassungen auch an den neuen Spuren/Stimmen vorgenommen - es findet intern eine Überwachung statt, damit alle zum gleichen Pattern gehörenden Spuren die gleiche Länge haben. Werden Files geladen, bei denen bestimmte Dinge nicht zusammenpassen, so wird dies, soweit möglich, repariert.

3.) Kopieren geht jetzt auch über mehrere Spuren hinweg. Es ist mir nicht ganz verständlich, wie man "mit der Kopierfunktion nicht klarkommen" kann: Man muß nur einfach Shift gedrückt halten und die Markierung dann in die entsprechenden Richtungen ziehen. Dann (mit ALT-M) das Modify-Menü aufrufen und eine der Funktionen auswählen. Dann (ohne Shift) mit den Richtungstasten (oder auch Patternwechsel) den Zielort suchen und die Funktion mit Return/Enter bestätigen. Löschen (Delete) muß auch so bestätigt werden (auch wenn es keinen Zielort gibt) - zwar etwas merkwürdig, aber die Funktionen haben alle einen einheitlichen Ablauf, um Programmspeicher zu sparen.

4.) Genau wie bei prISM, läuft nun auch während des Abspielens der Cursor mit. Drückt man ESC (oder eine andere Abbruchtaste), bleibt der Cursor genau dort stehen.
Kleine Zusatzinformation: Das Ganze ist übrigens mehr "Voodoo" als man denkt: Die ISM-Routinen verstehen ja kein Trackerfenster-Format - das Ganze ist nur eine andere Ansicht, die ständig live mit den wirklichen Daten abgeglichen wird. Die Position des Cursorbalkens wird komplett unabhängig von den Abspielroutinen, synchron dazu berechnet, anhand der abgespielten Puffer (mit 1/65536 Tick Genauigkeit, also wesentlich genauer als nötig).

5.) Die 5 Abspieltasten, die es auch bei prISM gibt, sind jetzt auch in AtavISM mit Abspielfunktionen belegt - leicht anders als bei prISM, aufgrund des abweichenden Formats:
F5 = Ganze Musik ab Anfang abspielen (wie prISM)
F6 = Das aktuelle Pattern in einer Schleife abspielen (Beginn ab Cursorposition)
F7 = Nur die aktuelle Spur/Stimme abspielen (Beginn ab Cursorposition)
F8 = Die ganze Musik ab "Mitte" (Cursorposition) abspielen, sonst wie F5
F9 = Die Musik ab einer bestimmten Sekunde abspielen (wie prISM). Der Zeitpunkt wird im "Play"-Pulldown, an Option "Timecode" eingestellt.

Somit sollte allen von zatzens Zusatzwünschen Genüge getan worden sein.

Zusätzlich habe ich noch selbst - neben einigem Debugging - einige Dinge hinzugefügt/geändert/erweitert:

6.) Das Tutorial wurde nochmals komplett überarbeitet und fehlerbereinigt - außerdem wurden natürlich auch die neu hinzugekommenen Funktionen mit berücksichtigt.

7.) Die Hotkey F10 zeigt nun (je nach Modus Notes/Piano und je nach Sprache Englisch/Deutsch) die dazugehörigen Listen von Hotkeys an.

8.) Das Tool ISMPRINT wurde debuggt und etwas erweitert. Nun können auch zusätzlich die in AtavISM enthaltenen Files ausgedruckt werden: Das AtavISM-Tutorial und die entsprechenden Hotkey-Listen. Das Tool kann bekanntlich auf dem Drucker ausdrucken oder in ein File hineinschreiben. Bisher druckt es allerdings ausschließlich im EPSON-Druckprotokoll (ESC/P). Möglicherweise baue ich IRGENDWANN eine Unterstützung für das PCL-Protokoll ein, falls es wichtig sein sollte.

Jetzt noch etwas Negatives: Die Mausunterstützung ist bei AtavISM noch lange nicht so komplett wie bei prISM. Ich habe das - zugunsten wichtigerer Features - etwas vernachlässigt. Die Dinge, die bei prISM und AtavISM identisch sind, sollten funktionieren (Pulldowns, Menüs), direkt auf die "neuen" Trackfenster bezogenen Dinge sind nicht vorhanden,

Durch die Erweiterung stehen nun ca. 5kByte RAM weniger für Samples zu Verfügung (irgendwo muß der neue Programmcode ja hin....)

Abgesehen von eventuell noch vervollständigter Mausabfrage (wie wichtig ist das bei diesem Tool?) und von noch eventuell vorhandenen Bugs - betrachte ich die vorliegende Version von AtavISM als fertig.
Es werden also keine neuen "Extra-Features" mehr folgen (außer denen, die auch im Zuge einer eventuellen Fortentwicklung von prISM sowieso entstehen). nachfolgende Änderungen an AtavISM werden sich aber hauptsächlich auf das Entfernen eventueller Bugs beschränken. (Und nein, ein nicht vorhandenes aber gern gewolltes Extrafeature einfach als Bug zu bezeichnen, wird daran nichts ändern.)

Anm.: An prISM, dem "Hauptprogramm" sind nur unwesentliche Änderungen gemacht worden, die sich hauptsächlich auf Speichersparen oder Auslagern von Routinen in externe Units beziehen.

Ich hoffe, die neue Version von AtavISM ist ein passendes Vor-Weihnachtsgeschenk für alle, die es eventuell interessiert. (Interessiert es eigentlich noch irgend jemanden außer zatzen?)

Zu finden ist das Tool, wie immer. auf meiner Website: http://www.imperial-games.de
oder, als direkter Link: http://www.imperial-games.de/html/dosa28.htm
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von zatzen »

Hallo!

Möchte mich nur mal kurz zwischendurch melden!

Ich habe noch mit dem Aussieben der ZSMs zu tun, habe
mir das neue AtavISM aber schonmal angesehen.

Die Editier- bzw Abspielmöglichkeiten sind wunderbar, super!

Die Vorschau der Instrumente beim Konfigurieren kommt
mir auch besser vor, es stottert nicht mehr (nur noch im PC
Speaker Modus), evtl. wäre noch eine Reaktion
auf das Drücken der Release-Taste ('<') sinnvoll,
aber das sind Luxuswünsche, es geht erstmal auch so.

Insgesamt wäre es wünschenswert wenn beim Konfigurieren
und beim Editieren der Patters die Klänge in der Lautstärke
gespielt würden wie sie auch hinterher zu hören sind.

Dieser hohe Lautstärkekontrast zwischen Editieren und
Anhören ist etwas krass. Aber dass das Instrument nicht
mehr in einer Schleife gespielt wird ist auch sehr viel Wert.

Man kann also auch so schon gut damit arbeiten.

Danke soweit für Deine Mühen, ich melde mich wieder
wenn ich ein neues Stück ge-atavism't habe!
mov ax, 13h
int 10h

while vorne_frei do vor;
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von DOSferatu »

zatzen hat geschrieben:Hallo!
Möchte mich nur mal kurz zwischendurch melden!
Cool.
zatzen hat geschrieben:Ich habe noch mit dem Aussieben der ZSMs zu tun, habe mir das neue AtavISM aber schonmal angesehen.
Die Editier- bzw Abspielmöglichkeiten sind wunderbar, super!
Schön, daß es endlich benutzbar erscheint.
zatzen hat geschrieben:Die Vorschau der Instrumente beim Konfigurieren kommt mir auch besser vor, es stottert nicht mehr (nur noch im PC Speaker Modus),
Ja, hier wird Sample immer live geladen und gespielt. Prinzipiell wird intern ein Mini-ISM-Soundprogramm erzeugt, das das Instrument/Sample lädt und diese eine Note abspielt. So brauche ich keine Extra-Funktionalität einbaue, sondern benutze gleich die sowieso schon vorhandenen Routinen von ISM.
zatzen hat geschrieben:evtl. wäre noch eine Reaktion auf das Drücken der Release-Taste ('<') sinnvoll, aber das sind Luxuswünsche, es geht erstmal auch so.
Mal sehen...
zatzen hat geschrieben:Insgesamt wäre es wünschenswert wenn beim Konfigurieren und beim Editieren der Patters die Klänge in der Lautstärke gespielt würden wie sie auch hinterher zu hören sind.
Dieser hohe Lautstärkekontrast zwischen Editieren und Anhören ist etwas krass.
Ja, da muß ich eben das oben erwähnte "Mini-Programm" entsprechend erweitern, so daß die restlichen Stimmen quasi mit-aktiviert werden und "Stille" spielen - das sollte den gewünschten Effekt bringen (weil ISM dann automatisch die entsprechende Lautstärke genau so anpaßt wie es auch im Zusammenspiel wäre).
zatzen hat geschrieben:Aber dass das Instrument nicht mehr in einer Schleife gespielt wird ist auch sehr viel Wert.
Das kommt ganz darauf an, wie man die Hüllkurve definiert.
zatzen hat geschrieben:Man kann also auch so schon gut damit arbeiten.
Schön zu hören/lesen.
zatzen hat geschrieben:Danke soweit für Deine Mühen, ich melde mich wieder wenn ich ein neues Stück ge-atavism't habe!
Scheinst Dich ja doch mit dem Tool anfreunden zu können.
Ja, ich weiß. Es ist um Längen schlechter als X-Tracker und die Klangqualität ist so gar nichts im Verhältnis zu dem, was Du heute so mit Renoise und auf CD produzierst. Als Musiker bluten einem da bestimmt schon die Ohren von diesem dumpfen Klang, den ISM erzeugt...
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Nicht-Tracker prISM

Beitrag von zatzen »

Ich habe das gleiche Stück was ich in ZSM bzw. X-Tracker gemacht habe, auch einmal in AtavISM gemacht.

http://www.zatzen.net/DKONGJR.ISM

Hat mich ein wenig Zeit gekostet, ich bin eben noch nicht so versiert in dem Programm,
aber das ist alles (fast) eine Sache der Gewöhnung. Fast, weil solche Dinge wie Patterns
kopieren fehlen - aber ich verstehe schon warum Du an soetwas ersteinmal nicht gedacht
hast, schliesslich lebt ISM ja von Nicht-Redundanz. Allerdings wird man es beim Trackern
nicht vermeiden können dass sich Spuren wiederholen, und es wäre eine Frage, wie intelligent
AtavISM mit diesen Daten umgeht.
mov ax, 13h
int 10h

while vorne_frei do vor;
Antworten