DE69632748T2

DE69632748T2 - Bearbeitungssystem für Musikdaten

Info

Publication number: DE69632748T2
Application number: DE69632748T
Authority: DE
Inventors: Yasushi Hamamatsu-shi Shizuoka-ken Kurakake; Takuya Hamamatsu-shi Shizuoka-ken Nakata
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 1995-09-29
Filing date: 1996-09-25
Publication date: 2005-07-14
Anticipated expiration: 2016-09-26
Also published as: KR970017169A; EP0766225A1; KR100187960B1; EP1011088B1; HK1010765A1; JPH09152876A; DE69617853D1; DE69617853T2; EP1011088A1; US5808223A; DE69632748D1; JP3218946B2; EP0766225B1

Description

HINTERGRUND DER ERFINDUNG
a) Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein Verarbeitungssystem für Musikdaten, in welchem Spieldaten zur gleichen Zeit verarbeitet werden, bei der Textdaten oder Hilfsdaten desselben verarbeitet werden.
b) Beschreibung verwandter Technik
Karaokemaschinen zum Mitsingen und andere Maschinen verwenden gespeicherte automatische Spieldaten und Textdaten. Während des Abspielens von Karaokemusik, während automatische Spieldaten wiedergegeben werden, werden ihre Textdaten auf einem Anzeigeschirm angezeigt. Mehrere Arten von Datenformaten werden zum Speichern von automatischen Spieldaten und Textdaten verwendet. Für ein einzelnes Verarbeitungssystem von Musikdaten war es schwierig, mit mehreren Arten von Datenformaten umzugehen.
Bei einem Datenformat werden sowohl automatische Spieldaten als auch Textdaten im gleichen Speichermedium in einem gemischten Zustand gespeichert, um die Wiedergabe der automatischen Spieldaten mit der Anzeige der Textdaten zu synchronisieren. Mit diesem Format werden zur selben Zeit, zu der die Spieldaten aus dem Speichermedium ausgelesen und wiedergegeben werden, auch die Textdaten ausgelesen und angezeigt. Wenn daher die Textdatenmenge groß ist, kann eine Verzögerung bei der Wiedergabe (Tonerzeugung) der Spieldaten auftreten.
Es gibt eine große Menge von Spieldaten, die nicht von Karaokemaschinen zum Mitsingen verwendbar sind, wie zum Beispiel automatische Spieldaten für elektronische Musikinstrumente. Es besteht ein Bedarf, solche Spieldaten bei Karaokemaschinen zum Mitsingen zu verwenden. Es ist jedoch nicht einfach, solche Spieldaten bei herkömmlichen Karaokemaschinen zum Mitsingen zu verwenden.
Auch besteht ein Bedarf, Textdaten oder Hilfsdaten zu solchen Spieldaten hinzuzufügen. Hilfsdaten sind Daten, die zum Suchen von Spieldaten verwendet werden, wie zum Beispiel ein Musikkomponistenname, ein Musiktextautorname und ein Sängername. Es ist jedoch nicht einfach, Spieldaten zu editieren, um ihnen Textdaten oder Hilfsdaten hinzuzufügen. EP-A-598 597 offenbart eine Vorrichtung zum Verfassen eine Skripts für eine auf Text-/Sprache basierende Multimediapräsentation. Ein Multimediaskriptfile enthält Texterzählungs- und Multimediaskript-Befehle, welche vom Text durch Steuerzeichen abgesetzt werden. Das Skriptfile wird verarbeitet, um die Skriptbefehle zu detektieren, wenn ein Steuerzeichen angetroffen wird.
KERN DER ERFINDUNG
Ein Ziel der vorliegenden Erfindung ist es, ein Verarbeitungssystem für Musikdaten bereitzustellen, das im der Lage ist, Textdaten oder Hilfsdaten mehrerer Arten von Datenformaten zu verarbeiten.
Ein weiteres Ziel der Erfindung ist es, ein Verarbeitungssystem für Musikdaten bereitzustellen, das eine durch Textdaten hervorgerufene Spielverzögerung beseitigen kann.
Ein noch weiteres Ziel der Erfindung ist es, ein Verarbeitungssystem für Musikdaten bereitzustellen, das auf einfache Weise Textdaten oder Hilfsdaten zu Spieldaten ohne Textdaten oder Hilfsdaten hinzufügen kann. Gemäß der vorliegenden Erfindung werden Systeme, wie es in Ansprüchen 1 und 3 dargelegt ist, Verfahren, wie es in Ansprüchen 7 und 9 dargelegt ist, und Speichermedien bereitgestellt, wie es in Ansprüchen 13 und 15 dargelegt ist.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Diagramm, welches die Funktion eines Musikdatenbearbeitungssystems gemäß einer Ausführungsform der Erfindung zeigt.
2 ist ein Blockschaltbild, welches die Hardwarestruktur des Musikdatenbearbeitungssystems der Ausführungsform zeigt.
3A und 3B zeigen ein erstes Datenformat, 3A zeigt das Format eines sequentiellen Files, und 3B zeigt die Datenstruktur des Spurabschnitts.
4A bis 4C zeigen ein zweites Datenformat, 4A zeigt das Format eines sequenziellen Files, 4B zeigt die Datenstruktur eines Spurabschnitts und 4C zeigt die Datenstruktur eines Textabschnitts.
Die 5A bis 5C zeigen ein drittes Datenformat, 5A zeigt die Formate eines sequenziellen Files und eines Textfiles, 5B zeigt die Datenstruktur eines Spurabschnitts und 5C zeigt die Datenstruktur eines Textfiles.
Die 6A und 6B zeigen ein Standarddatenformat, 6A zeigt das Datenformat in einem Spielereignisbereich im RAM und 6B zeigt das Datenformat in einem Textereignisbereich im RAM.
7A und 7B zeigen ein Beispiel für die Umwandlung von Textereignisdaten in Zeilenereignisdaten, 7A zeigt ein Beispiel für Textereignisdaten der ersten bis dritten Datenformate, und 7B zeigt ein Beispiel für Zeilenereignisdaten, die im Textereignisbereich gespeichert sind.
8 ist ein Flussdiagramm, dass einen durch die CPU auszuführenden Fileauswahlprozess zeigt.
9 ist ein Diagramm, dass eine Prioritätsreihenfolge eines Spielereignisprozesses und eines Textereignisprozesses zeigt.
10 ist ein Flussdiagramm, dass einen Spielereignisprozess zeigt.
11 ist ein Flussdiagramm, dass einen Textereignisprozess zeigt.
12A und 12B zeigen ein erstes Datenformat, welches Hilfsdaten enthält, 12A zeigt das Format eines sequenziellen Files und 12B zeigt die Datenstruktur eines Spurabschnitts.
13A bis 13C zeigen ein zweites Datenformat, welches Hilfsdaten enthält. 13A zeigt das Format eines sequenziellen Files, 13B zeigt die Datenstruktur eines Spurabschnitts, und 13C zeigt die Datenstruktur eines Textabschnitts.
14A bis 14C zeigen ein drittes Datenformat, welches Hilfsdaten enthält, 14A zeigt die Formate eines sequenziellen Files, eines Textfiles und eines Hilfsfiles, 14B zeigt die Datenstruktur eines Spurabschnitts, und 14C zeigt die Datenstruktur eines Textfiles.
15 ist ein Flussdiagramm, das einen Fileauswahlprozess zeigt, der verwendet wird, wenn Hilfsdaten bearbeitet werden.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
1 ist ein Diagramm, weiches die Funktion eines Musikdatenbearbeitungssystems gemäß einer Ausführungsform der Erfindung zeigt.
Erste Musikdaten D1, zweite Musikdaten D2 und dritte Musikdaten D3 enthalten jeweils Spieldaten und Textdaten. Die Datenformate der ersten bis dritten Daten D1 bis D3 sind verschieden. Zum Beispiel enthält ein Musikdatum Spieldaten und Textdaten in einem gemischten Zustand, und ein weiteres Musikdatum enthält perfekt getrennte Spieldaten und Textdaten.
Ein Datenumwandler 1 wandelt jede der eingegebenen Musikdaten D1 bis D3 in Musikdaten D0 des Standarddatenformats um. Die Musikdaten D0 des Standarddatenformats weisen Spieldaten und Textdaten auf, die voneinander getrennt sind. Die unterschiedlichen Formate der Musikdaten D1 bis D3 werden in das Standarddatenformat der Musikdaten D0 umgewandelt.
Eine Wiedergabevorrichtung 2 weist einen Spieldatenprozessor 3 und einen Textdatenprozessor 4 auf und gibt die empfangenen Musikdaten D0 wieder. Der Spieldatenprozessor 3 gibt die Spieldaten wieder und erzeugt Töne. Der Textdatenprozessor 4 zeigt die Textdaten auf einer Anzeige an.
Da die Spieldaten und Textdaten getrennt wiedergegeben werden, tritt eine Verzögerung der Spieldaten in Abhängigkeit der Menge von Textdaten kaum auf. Die Spieldaten und Textdaten werden mit geeigneter Taktung unter Verwendung von Zeitdaten wiedergegeben, deren Einzelheiten später angegeben werden.
Das Musikdatenbearbeitungssystem dieser Ausführungsform kann jedes der Eingabemusikdaten D1 bis D3 mit jeweils unterschiedlichem Datenformat wiedergeben. Sogar zu Musikdaten eines Formats, das nur Spieldaten enthält, wie z. B. automatische Spieldaten eines elektronischen Musikinstruments, können Textdaten hinzugefügt werden, deren Details später angegeben werden.
2 ist ein Blockschaltbild, welches die Hardwarestruktur des Musikdatenbearbeitungssystems der Ausführungsform zeigt.
Eine CPU 20 ist über einen BUS 24 mit einem ROM 18, einem RAM 19, einem Zeitgeber 21, einer MIDI-Schnittstelle 11, einem Detektor 12, einer Anzeige 14, einem Tongenerator 15, einem Festplattenlaufwerk 22, einem Diskettenlaufwerk 23, einem CD-ROM-Laufwerk 41 und einer Kommunikationsschnittstelle 43 verbunden.
Der RAM 19 weist einen Spielereignisbereich 31 und einen Textereignisbereich 32 auf. Der Spielereignisbereich 31 ist ein Bereich zum Speichern von Spielereignisdaten des umgewandelten Standardformats, und der Textereignisbereich 32 ist ein Bereich zum Speichern von Textereignisdaten des umgewandelten Standardformats.
Der RAM 19 weist außerdem Arbeitsbereiche für die CPU 20 auf, wie z. B. Register und Zwischenspeicher. Der ROM 18 speichert Computerprogramme und verschiedene Parameter. Die CPU 20 führt verschiedene Prozesse unter Verwendung der im ROM 18 gespeicherten Computerprogramme aus.
Die CPU 20 empfängt Musikdaten vom Festplattenlaufwerk 22, Diskettenlaufwerk 23, CD-ROM-Laufwerk 41, der MIDI-Schnittstelle 11 oder der Kommunikationsschnittstelle 43 und wandelt sie in Musikdaten des Standardformats um. Die Spieldaten der Musikdaten werden in den Spielereignisbereich 31 hineingeschrieben, und deren Textdaten werden in den Textereignisbereich 32 hineingeschrieben.
Der Zeitgeber 21 versorgt die CPU 20 in einem vorgegebenen Zeitintervall mit Zeitgeberunterbrechungssignalen. Nach Empfangen eines Zeitgeberunterbrechungssignals beginnt die CPU 20, einen vorbestimmten Unterbrechungsprozess auszuführen.
Das Diskettenlaufwerk 23 kann Daten auf eine entfernbare Diskette schreiben und von dieser lesen. Sobald die Diskette, die die Musikdaten speichert, in das Diskettenlaufwerk 23 eingelegt wird, kann die CPU 20 die Musikdaten lesen.
Das Festplattenlaufwerk 22 ist ein Speicher mit großer Kapazität, der eine große Menge an Musikdaten speichern kann. Die CPU 20 kann Musikdaten zwischen dem Diskettenlaufwerk 23 und dem Festplattenlaufwerk 22 übertragen und kann Musikdaten vom Festplattenlaufwerk 22 lesen.
Die MIDI-Schnittstelle 11 überträgt MIDI-Daten, wie z. B. Musikdaten, zu und von einer externen Vorrichtung.
Der Detektor 12 ist mit einem Eingabegerät 13, wie z. B. einer Tastatur und einer Maus, verbunden. Die CPU 20 detektiert den Zustand von Schaltern und dergleichen über den Detektor 12. Ein Bediener kann durch Bedienen des Eingabegerätes 13 verschiedene Anweisungen bestimmen. Zum Beispiel können wiederzugebende Musikdaten bestimmt werden. Das Eingabegerät 13 weist auch einen Wiedergabeschalter für die Anweisung auf, Musikdaten wiederzugeben.
Die Anzeige 14 zeigt Textdaten an, die im Textereignisbereich 32 des RAM 19 gespeichert sind, und kann die Art der Musikdatenanzeige anzeigen, die im Festplattenlaufwerk 22 gespeichert sind.
Der Tongenerator 15 erzeugt ein Tonsignal nach Empfang von Spieldaten, die im Spielereignisbereich 31 des RAM 19 gespeichert sind. Zum Erzeugen eines Tonsignals kann der Tongenerator 15 ein Wellenformspeicherschema, ein FM-Schema, ein Schema eines physikalischen Modells, ein Schema für eine harmonische Synthese, ein Formantsynthese-Schema, ein Analog-Synthese-Schema, einschließlich VCO (spannungsgesteuerter Oszillator), VCF (spannungsgesteuertes Filter) und VCA (spannungsgesteuerter Verstärker) und andere Schemata verwenden.
Ein D/A-Wandler 16 empfängt ein digitales Tonsignal vom Tongenerator 15 und wandelt es in ein analoges Tonsignal um.
Ein Tonsystem 17 weist einen Verstärker und einen Lautsprecher auf, empfängt ein analoges Tonsignal vom D/A-Wandler 16, um es durch den Verstärker zu verstärken und Töne aus dem Lautsprecher zu erzeugen.
Das Festplattenlaufwerk 22 ist eine Speichereinheit zum Speichern zahlreicher Daten wie Computerprogramme, Musikdaten (automatische Spieldaten) und dergleichen. Wenn Computerprogramme nicht im ROM 18 gespeichert sind, werden Computerprogramme auf einer Festplatte des Festplattenlaufwerks 22 gespeichert und in den RAM 19 geschrieben, um die CPU 20 zu betreiben. Auf diese Weise werden eine Hinzufügung, Aktualisierung und dergleichen von Computerprogrammen einfach.
Das CD-ROM-Laufwerk 41 liest die Computerprogramme und verschiedene auf einer Compact-Disk 42 gespeicherten Daten aus. Die Computerprogramme und verschiedene Daten werden auf einer Festplatte des Festplattenlaufwerks 22 gespeichert, was die Neuinstallation und Aktualisierung von Computerprogrammen erleichtert. Andere Laufwerke können auch installiert werden, um andere externe Speichermedien, wie z. B. eine magnetooptische Disk, zu verwenden.
Die Kommunikationsschnittstelle 43 wird mit einem Kommunikationsnetzwerk 44, wie z. B. einem LAN (lokales Netzwerk), dem Internet und Telefonleitungen, und über das Kommunikationsnetzwerk 44 mit einem Servercomputer 45 verbunden. Wenn Computerprogramme und verschiedene Daten nicht im Festplattenlaufwerk 22 gespeichert werden, werden sie vom Servercomputer 45 heruntergeladen. Das Musikdatenbearbeitungssystem dieser Ausführungsform überträgt als ein Client einen Befehl, der das Herunterladen von Computerprogrammen anfordert, und Daten auf den Servercomputer 45 über die Kommunikationsschnittstelle 43 und das Kommunikationsnetzwerk 44. Nach Erhalt dieses Befehls stellt der Servercomputer 45 die angeforderten Computerprogramme und Daten dem Musikdatenbearbeitungssystem über das Kommunikationsnetzwerk 44 und die Kommunikationsschnittstelle 43 zur Verfügung, und das Musikdatenbearbeitungssystem speichert die empfangenen Programme und Daten im Festplattenlaufwerk 22, um das Herunterladen abzuschließen.
Die Ausführungsform kann durch kommerzielle Personalcomputer oder dergleichen durch Laden der Computerprogramme und verschiedenen Daten dieser Ausführungsform praktiziert werden. Die Computerprogramme und verschiedenen Daten der Ausführungsform können Benutzern in Form von Speichermedien, wie z. B. einer durch einen Personalcomputer lesbare Compact-Disk oder Floppydisk, zur Verfügung gestellt werden. Wenn ein Personalcomputer verwendet wird, der mit einem Kommunikationsnetzwerk, wie z. B. einem LAN, dem Internet und Telefonleitungen, verbunden ist, können die Computerprogramme und verschiedene Daten über das Kommunikationsnetzwerk zur Verfügung gestellt werden.
Die Anwendung solcher Konfigurationen des Systems dieser Ausführungsform ist nicht nur auf Karaokemaschinen zum Mitsingen beschränkt, sondern auch auf ein elektronisches Musikinstrument und eine Kombination eines Personalcomputers und Anwendungssoftware.
Der Tongenerator 15 kann durch bestimmte Hardware, einen DSP (digitaler Signalprozessor) und Mikroprogramme, durch eine CPU und Software, durch mehrere Tonerzeugungskanäle mit Zeiteinteilung oder durch mehrere Tonerzeugungskanäle ausgebildet werden, die jeweils aus einem separaten Schaltkreis bestehen.
Das Festplattenlaufwerk 22, das Diskettenlaufwerk 23, das CD-ROM-Laufwerk 41, die MIDI-Schnittstelle 11 oder die Kommunikationsschnittstelle 43 stellt Musikdaten mit verschiedenen Arten von Formaten der CPU 20 zur Verfügung.
Als nächstes werden drei Beispiele für das Format von Musikdaten eines Standard-MIDI-Filetyps mit Bezug auf die 3A bis 5C beschrieben.
Die 3A und 3B zeigen ein erstes Datenformat. Die 3A zeigt das Format eines Sequenzfiles FL1. Ein Satz von Musikdaten wird durch das Sequenzfile FL1 dargestellt. Das Sequenzfile FL1 wird im Festplattenlaufwerk 22 oder dergleichen gespeichert. Das Sequenzfile FL1 weist einen. Kopfabschnitt HC und einen Rumpfabschnitt TC auf. Der Kopfabschnitt HC enthält Informationen (Identifikationscode des ersten, zweiten oder dritten Datenformats) und Informationen über die Zeitauflösung der Daten. Die Struktur des Spurabschnitts TC wird nun beschrieben.
3B zeigt die Datenstruktur des Spurabschnitts TC. Der Spurabschnitt TC weist mehrere Sätze von Rumpfabschnittdaten von TCD1, TCD2, ... auf. Jeder Rumpfabschnitt TCD1, TCD2, weist dieselbe Datenstruktur auf. Z. B. weist der Rumpfabschnitt TCD1 Spieldaten SS1 und Textdaten LL1 auf.
Die Spieldaten SS1 weisen Zeitdaten TS1 und Spielereignisdaten SD1 auf. Die Spielereignisdaten SD1 werden im wesentlichen zum Erzeugen von Musiktönen verwendet. Die Zeitdaten TS1 zeigen eine Zeitdauer vom Spielbeginn zum ersten Spielereignisdatum SD1 an. Die Zeitdaten TS2 zeigen eine Zeitdauer zwischen den Spielereignisdaten SD1 und den nächsten Spielereignisdaten SD2 an.
Die Textdaten LL1 weisen Zeitdaten TL1 und Textereignisdaten LD1 auf. Die Textereignisdaten LD1 werden im wesentlichen zum Anzeigen von Texten verwendet. Die Zeitdaten TL1 zeigen eine Zeitdauer vom Spielbeginn bis zum ersten Textereignisdatum LD1 an. Die Zeitdaten TL2 zeigen eine Zeitdauer zwischen den Textereignisdaten LD1 und den nächsten Textereignisdaten LD2 an.
Obwohl nicht gezeigt, kann ein Programmname, Komponistenname und dergleichen im Rumpfabschnitt TC enthalten sein.
Die 4A bis 4C zeigen eine zweites Datenformat.
4A zeigt das Format eines Sequenzfiles FL1. Ein Satz von Musikdaten wird durch ein Sequenzfile FL1 dargestellt. Das Sequenzfile FL1 weist einen Kopfabschnitt HC, einen Rumpfabschnitt TC und einen Textabschnitt LC auf. Der Kopfabschnitt HC weist dieselbe Struktur wie der Kopfabschnitt des ersten Datenformats (3A) auf. Die Strukturen des Spurabschnitts TC und des Textabschnitts LC werden nun beschrieben.
4B zeigt die Datenstruktur des Spurabschnitts TC. Der Spurabschnitt TC weist mehrere Spieldatensätze SS1, SS2, ... auf. Jedes Spieldatum SS1, SS2, weist dieselbe Datenstruktur auf. Die Spieldaten SS1 haben dieselbe Struktur wie die der Spieldaten des ersten Datenformats (3B) und haben dieselbe Zeitdaten TS1 und Spielereignisdaten SD1.
4C zeigt die Datenstruktur des Textabschnitts LC. Der Textabschnitt LC weist mehrere Textdatensätze LL1, LL2, ... auf. Jedes Textdatum LL1, LL2 weist dieselbe Datenstruktur auf. Die Textdaten haben dieselbe Struktur wie die Textdaten des ersten Datenformats (3B) und haben Zeitdaten TL1 und Textereignisdaten LD1.
Die 5A bis 5C zeigen ein drittes Datenformat.
5A zeigt die Formate eines Sequenzfiles FL1 und eines Textfiles FL2. Ein Satz von Musikdaten wird durch ein Sequenzfile FL1 und ein Textfile FL2 dargestellt und in einem Festplattenlaufwerk oder dergleichen gespeichert.
Bei dem Sequenzfile FL1 kann es sich um automatische Spieldaten eines herkömmlichen elektronischen Musikinstruments handeln. Das Spielfile FL2 ist ein neugebildetes File, um das File FL1 des elektronischen Musikinstruments beispielsweise mit einer Karaokemaschine zum Mitsingen zu verwenden. Durch Neubilden von nur dem Spielfile FL2, können die Files FL1 und FL2 für eine Karaokemaschine zum Mitsingen konfiguriert werden.
Das Sequenzfile FL1 weist einen Kopfabschnitt HC und einen Rumpfabschnitt TC auf. Der Kopfabschnitt HC weist dieselbe Struktur auf, wie der Kopfabschnitt des ersten oder zweiten Datenformats (3A, 4A).
5B zeigt die Datenstruktur des Spurabschnitts TC. Der Spurabschnitt TC weist dieselbe Struktur auf, wie der Rumpfabschnitt des zweiten Formats (4B) und weist mehrere Sätze von Spieldaten SS1, SS2, ... auf. Die Spieldaten SS1 weisen Zeitdaten TS1 und Spielereignisdaten SD1 auf.
Es bedarf keiner Erwähnung, dass in jedem der ersten bis dritten Datenformate die Spieldaten und Textdaten vorzugsweise so erzeugt werden, dass das Timing der Noten der Spieldaten mit dem Timing des Textes der Textdaten zusammenfällt.
5C zeigt die Datenstruktur des Textfiles FL2. Das Textfile FL2 weist dieselbe Struktur auf wie der Spielabschnitt des zweiten Formats (4C) und weist mehrere Sätze von Textdaten LL1, LL2, ... auf. Die Textdaten LL1 weisen Zeitdaten TL1 und Spielereignisdaten LD1 auf. Bezugnehmend auf 2 wandelt die CPU 20 Spieldaten jedes oben beschriebenen Datenformats in Spieldaten des Standardformats um, die in den Spielereignisbereich 31 und Textereignisbereich 32 des RAM 19 geschrieben werden.
Als nächstes werden die Formate der Daten beschrieben, die in den Spielereignisbereich 31 und Textereignisbereich 32 geschrieben werden.
Die 6A und 6B zeigen das Standarddatenformat. Die Musikdaten werden in Spieldaten und Textdaten aufgeteilt, die jeweils im Spielereignisbereich 3i und Textereignisbereich 32 gespeichert werden.
6A zeigt das Datenformat von Daten im Spielereignisbereich 31 des RAM 19. Mehrere Sätze von Spieldaten SS1, SS2, ... werden in dem Spielereignisbereich 31 gespeichert. Jedes Spieldatum SS1, SS2 weist dieselbe Datenstruktur auf. Zum Beispiel weisen die Spieldaten SS1 Zeitdaten TS1 und Spielereignisdaten SD1 ähnlich zur oben beschriebenen Datenstruktur auf.
6B zeigt das Datenformat von Daten im Textereignisbereichs 32 des RAM 19. Mehrere Sätze von Textdaten LL1', LL2', ... werden im Textereignisbereich 32 gespeichert. Jedes Textdatum LL1', LL2' weist dieselbe Datenstruktur auf. Zum Beispiel weisen die Textdaten LL1' Zeitdaten TL1' und Zeilenereignisdaten LD1' auf, die sich von der oben beschriebenen Datenstruktur unterscheiden.
Die Zeilenereignisdaten LD1' beinhalten ein Stück aus einer Zeile von Textdaten. Beispielsweise beschreiben die ersten bis dritten Datenformate vor Umwandlung in das Standardformat Textdaten in Einheiten von Silben. Um daher Texte Zeile für Zeile auf der Anzeige 14 während des Abspielens von Musik darzustellen, muss eine Zeichenkette in Zeilen umgewandelt werden. Die Zeitdaten TL1' einer Textzeile entsprechen den Zeitdaten einer Summe von Zeitdaten bei entsprechenden Silben. Dies wird unter Verwendung eines speziellen Beispiels genauer ausgeführt.
7A und 7B zeigen ein Beispiel der Umwandlung von Textereignisdaten in Zeilenereignisdaten.
7A zeigt ein Beispiel von Textereignisdaten der ersten bis dritten Datenformate. Der Textabschnitt LC weist vier Sätze von Textdaten LL1 bis LL4 auf. Vier Sätze von Zeitdaten TL1 bis TL4 der Textdaten sind t1, t2, t3 und t4, und die vier Sätze der Textereignisdaten LD1 bis LD4 sind „beau", „ti", „ful_" und „sky/".„_" steht für ein Leerzeichen und „/" steht für einen Zeilenumbruch. Jedes Textdatum LL entspricht einer Note und ist eine Einheit, die zum Beispiel durch eine Silbe eingeteilt ist. Die Textdaten LL können zwei oder mehr Silben oder ein Wort enthalten.
7B zeigt ein Beispiel von Zeilenereignisdaten, die im Textereignisbereich 32 gespeichert sind. Textdaten LL1' sind im Textereignisbereich 32 gespeichert. Zeitdaten TL1' der Textdaten LL1' sind eine Summe (td +, ..., + t1) von Zeitdaten von der ersten Silbe des einen vorangehenden Zeilenereignisdatums LD0' bis zur ersten Silbe des Zeilenereignisdatums LD1'. Das Zeilenereignisdatum LD1' ist „beautiful_sky/". Das Zeitdatum TL2' des nächsten Zeilenereignisdatums LD2' ist „t2 + t3 + t4 + t5". Das Zeilenereingisdatum LD1' ist das Datum, das man durch Rekonfigurieren des Textes der in 7A gezeigten Textereignisdaten erhält, und die Zeichen bis zum Zeilenumbruchsymbol bilden einen Satz von Zeilendaten. Textdaten werden auf der Anzeige in Einheiten von Zeilen angezeigt.
8 ist ein Flussdiagramm, welches einen von der CPU auszuführenden Fileauswahlprozess zeigt.
In Schritt SA1 wird ein File bestimmt. Sequenzfilenamen von Musikdaten, die im Festplattenlaufwerk 22 oder dergleichen gespeichert sind, werden auf der in 2 gezeigten Anzeige 14 angezeigt. Ein Bediener wählt ein gewünschtes File unter Verwendung des Eingabegeräts 13, wie zum Beispiel einer Tastatur und einer Maus, aus. Das Format des vom Bediener ausgewählten Files kann jedes der ersten bis dritten Datenformate sein.
Im Schritt SA2 werden Daten des Spurabschnitts des ausgewählten Files ausgelesen. Ein Identifizierungscode, der den Beginn des Spurabschnitts darstellt, ist in dem File enthalten. Die Position des Spurabschnitts kann durch den Identifikationscode identifiziert werden. Die aus dem Spurabschnitt ausgelesenen Daten sind eine Kombination aus Zeitdaten und Textereignisdaten oder eine Kombination aus Zeitdaten und Spielereignisdaten.
In Schritt SA3 wird geprüft, ob die ausgelesenen Daten Textdaten oder Spieldaten sind. Im Fall von Textdaten fährt der Programmablauf mit Schritt SA4 fort, wobei die gelesenen Daten zum Textereignisbereich 32 des RAM übertragen werden, und anschließend rückt der Programmablauf zu Schritt SA6 vor.
Wenn die gelesenen Daten Spielereignisdaten sind, rückt der Programmablauf zu Schritt SA5 vor, in welchem die gelesenen Daten an den Spielereignisbereich 31 des RAM übertragen werden, und anschließend rückt der Programmablauf zu Schritt SA6 vor. Wenn Zeitdaten ausgelesen werden, werden sie sowohl zum Bereich 31 als auch 32 in den Schritten SA4 und SA5 übertragen. Wie im Falle des ersten Datenformats (3A und 3B) befinden sich, wenn sowohl die Spieldaten als auch die Textdaten sich im selben Abschnitt in einem gemischten Zustand befinden, die Zeitdaten für die Spieldaten und Textdaten auch in demselben Abschnitt in einem gemischten Zustand und werden an beide Bereiche 31 und 32 übertragen. Die Spieldaten und Textdaten teilen sich dieselben Zeitdaten.
In Schritt SA6 wird geprüft, ob alle Daten im Spurabschnitt ausgelesen sind oder nicht. Wenn nicht, kehrt der Programmablauf zu Schritt SA2 zurück, um denselben Prozess wie oben für die nächsten Daten im Spurabschnitt zu wiederholen. Wenn alle Daten ausgelesen sind, rückt der Programmablauf zu Schritt SA7 vor.
Es wird im Schritt SA7 geprüft, ob die vom Spurabschnitt ausgelesenen Daten Textereignisdaten enthalten. Falls enthalten, handelt es sich um das erste Datenformat (3A und 3B), und der Programmablauf rückt zu Schritt SA8 vor. In diesem Fall sind sowohl die Textdaten aus auch die Spieldaten zu den Ereignisbereichen 31 und 32 übertragen worden.
In Schritt SA8 werden die Daten im Textereignisbereich rekonfiguriert, um diesen Prozess abzuschließen. Mit dieser Rekonfiguration werden Textereignisdaten in Zeilenereignisdaten rekonfiguriert.
Wenn in Schritt SA7 entschieden wird, dass die aus dem Spurabschnitt ausgelesenen Daten keine Textereignisdaten enthalten, handelt es sich entweder um das zweite oder dritte Datenformat (4A bis 4C, 5A bis 5C), und der Programmablauf rückt zu Schritt SA9 vor, um einen anderen Prozess für Textereignisdaten auszuführen.
In Schritt SA9 wird ein Textabschnitt aus dem ausgewählten Sequenzfile gesucht. Ein Identifikationscode, der den Beginn des Textabschnittes darstellt, ist in dem File enthalten. Die Position des Textabschnittes kann durch diesen Identifikationscode identifiziert werden.
In Schritt SA10 wird geprüft, ob der Textabschnitt gefunden wurde oder nicht. Falls gefunden, liegt das zweite Datenformat (4A bis 4C) vor, und der Programmablauf rückt zu Schritt SA11 vor.
In Schritt SA11 werden die aus dem Textabschnitt ausgelesenen Daten an den Textereignisbereich 32 des RAM übertragen. In Schritt SA8 werden die Daten im Textereignisbereich 32 rekonfiguriert, um den Prozess zu beenden.
Wenn in Schritt SA10 entschieden wird, dass kein Textabschnitt gefunden wurde, liegt das dritte Datenformat vor (5A bis 5C), und der Programmablauf rückt zu Schritt SA12 vor.
In Schritt SA12 wird ein Textfile mit dem selben Filenamen wie das ausgewählte Sequenzfile gesucht. Das dritte Datenformat weist zwei Files auf, das Sequenzfile FL1 und das Textfile FL2, wie in den 5A bis 5C gezeigt ist.
Zum Beispiel weist ein sequenzielles File den Filenamen „ABCD.MID" und ein Textfile einen Filenamen „ABCD.LYR" auf. Ein Filename weist einen Hauptteil wie zum Beispiel ABCD und einen Erweiterungsteil wie zum Beispiel MID oder LYR auf. Diese beiden Files haben denselben Filenamenhauptteil „ABCD" und verschiedene Filenamenerweiterungsteile „MID" und „LYR". Der Erweiterungsteil des Filenamens „MID" zeigt ein Sequenzfile an, und „LYR" zeigt ein Textfile an.
Angenommen das Sequenzfile „ABCD.MID" wurde ausgewählt, so wird ein Textfile „ABCD.LYR" mit demselben Hauptteil des Filenamens gesucht.
In Schritt SA13 wird geprüft, ob ein Textfile gefunden wurde oder nicht. Falls es gefunden wurde, rückt der Programmablauf zu Schritt SA14 vor.
In Schritt SA14 werden die aus dem Textfile ausgelesenen Daten zum Textereignisbereich 32 des RAM übertragen. In Schritt SA8 werden die Daten im Textereignisbereich 32 rekonfiguriert, um den Prozess zu beenden.
Wenn in Schritt SA13 entschieden wird, dass kein Textfile gefunden wurde, rückt der Programmablauf zu Schritt SA15 vor. Im Schritt SA15 wird eine Nachricht „keine Textdaten" auf der Anzeige angezeigt, um den Prozess zu beenden.
Mit dem obigen Prozess werden Ereignisdaten des ersten bis dritten Datenformats in Ereignisdaten des Standardformats umgewandelt und in den Spiel- und Textereignisbereichen 31 und 32 gespeichert.
9 ist ein Diagramm, welches den Prioritätsgrad zwischen einem Spielereignisprozess und einem Textereignisprozess zeigt, welche durch den Spielereignisprozessor 3 und Textereignisprozessor 4 ausgeführt werden, die in 1 gezeigt sind.
Der Spielereignisprozess und der Textereignisprozess sind beide Unterbrechungsprozesse. Die Prioritätsordnung des Unterbrechungsprozesses ist für den Spielereignisprozess höher als die für den Textereignisprozess.
Der Spielereignisprozess ist ein Prozess der Wiedergabe von Spieldaten. Der Textereignisprozess ist ein Prozess des Anzeigens von Textdaten. Sogar, wenn die Menge von Textereignisdaten groß ist, kann eine Verzögerung beim Wiedergeben von Spieldaten dadurch verhindert werden, dass den Spielereignisdaten eine höhere Prioritätsordnung verliehen wird. Dieser Prioritätsprozess wird möglich, weil die Spieldaten und Textdaten in getrennten Ereignisbereichen gespeichert werden.
Ein Hörer ist bei einer kleinen Verzögerung beim Anzeigen von Textdaten nicht so sehr nervös, jedoch sehr empfindlich aufgrund einer Verzögerung bei der Wiedergabe eines Spiels. Es ist daher nötig, bevorzugt eine Verzögerung bei der Wiedergabe eines Spiels zu vermeiden.
Als nächstes werden der Spielereignisprozess und der Textereignisprozess beschrieben.
10 ist ein Flussdiagramm, dass den Spielereignisprozess zeigt, wobei es sich um einen Unterbrechungsprozess mit einem Unterbrechungsintervall von zum Beispiel 10 ms handelt.
In Schritt SB1 wird geprüft, ob eine Wiedergabesignal LAUF = „1" ist. Das Wiedergabesignal LAUF wird im Anfangszustand auf „0" gesetzt. Sobald ein Bediener einen Wiedergabeschalter drückt, ändert es sich auf „1", und sobald ein Stoppschalter gedrückt wird, ändert es sich wieder auf „0".
Wenn das Wiedergabesignal LAUF = „0" ist, liegt keine Wiedergabeanweisung vor, so dass der Prozess vor dem Unterbrechungsprozess erneut ausgeführt wird, ohne den Wiedergabeprozess auszuführen. Wenn das Wiedergabesignals LAUF = „1" ist, rückt der Programmablauf zu Schritt SB2 vor, um den Wiedergabeprozess auszuführen.
In Schritt SB2 wird K von einem Wert eines Registers ZEIT subtrahiert. Wenn der Bediener den Wiedergabeschalter drückt, werden die Zeitdaten der ersten Spielereignisdaten im Register ZEIT im Anfangszustand gespeichert. Diese Zeitdaten zeigen eine Zeit an, zu der Töne nach Drücken des Wiedergabeschalters zuerst erzeugt werden. Der Wert K wird entsprechend eines Spieltempos und eines Unterbrechungsintervalls wie folgt bestimmt. K = (Spieltempo × Auflösung × Unterbrechungsintervall)/(60 × 1000)
Die Auflösung ist die Auflösung einer viertel Note, z. B. 96. Je größer der Wert K ist, desto mehr Spieldaten pro Zeiteinheit werden zum Erzeugen von Tönen ausgelesen.
Wenn man z. B. annimmt, dass das Spieltempo 120 und das Unterbrechungsintervall 10 ms beträgt, so ergibt sich K = (120 × 96 × 10)/(60 × 1000) = 1,92.
Die Zeitdaten werden durch Verwenden einer kleinsten Einheit der Auflösung einer Viertelnote (z. B. 96) angezeigt.
In Schritt SB3 wird geprüft, ob oder nicht ein Register ZEIT = „0" beträgt oder kleiner ist. Wenn nicht, werden die Spieldaten nicht verarbeitet, um den Prozess zu beenden und zum Prozess vor dem Unterbrechungsprozess zurückzukehren.
Da der Unterbrechungsprozess alle 10 ms wiederholt wird, wird das Register ZEIT in Schritt SB2 allmählich reduziert. Wenn in Schritt SB3 entschieden wird, dass das Register ZEIT = „0" oder kleiner ist, so fährt der Programmablauf mit Schritt SB4 fort.
In Schritt SB4 wird eine Adresse des Spielereignisbereichs des RAM inkrementiert, um die Daten entweder der Zeitdaten oder Spielereignisdaten auszulesen.
In Schritt SB5 wird geprüft, ob die gelesenen Daten Zeitdaten sind oder nicht. Wenn nicht, sind die gelesenen Daten Spielereignisdaten, und der Programmablauf rückt zu Schritt SB7 vor.
In Schritt SB7 werden die Spielereignisdaten dem Tongenerator 15 zugeführt, und der Programmablauf kehrt zu Schritt SB4 zurück, um den obigen Prozess für die nächsten Daten zu wiederholen. Wenn der Tongenerator 15 mit den Spielereignisdaten versorgt wird, erzeugt er ein Musiktonsignal, welches über den D/A-Wandler 16 dem Tonsystem 17 zugeführt wird, um Töne zu erzeugen.
Wenn in Schritt SB5 entschieden wird, dass die gelesenen Daten Zeitdaten sind, so rückt der Programmablauf zu Schritt SB6 vor, wo die gelesenen Zeitdaten zum Register ZEIT hinzugefügt werden.
In Schritt SB8 wird geprüft, ob das Register ZEIT größer als „0" ist oder nicht. Wenn nicht, d. h. wenn das Register ZEIT negativ ist, sogar wenn die Zeitdaten zum Register ZEIT in Schritt SB6 hinzuaddiert werden, da das Register ZEIT aufgrund der Subtraktion von K in Schritt SB2 einen negativen Wert angenommen hat, kehrt der Programmablauf zu Schritt SB4 zurück, um den obigen Prozess für die nächsten Daten zu wiederholen.
Wenn in Schritt SB8 entschieden wird, dass das Register ZEIT größer als „0" ist, wird der Unterbrechungsprozess beendet, um zum Prozess vor dem Unterbrechungsprozess zurückzukehren.
11 ist ein Flussdiagramm, das den Textereignisprozess zeigt, bei dem es sich um einen Unterbrechungsprozess mit einem Unterbrechungsintervall von beispielsweise 20 ms handelt. Wenn der Spielereignisprozess nicht häufig durchgeführt werden braucht, kann das Unterbrechungsintervall länger als das des Spielereignisprozesses gemacht werden. Dasselbe Unterbrechungsintervall kann sowohl für den Spiel- als auch für den Textereignisprozess eingestellt werden.
In Schritt SC1 wird geprüft, ob das Wiedergabesignal LAUF = „1" ist oder nicht. Wenn das Wiedergabesignal LAUF = „0" ist, bedeutet dies keine Wiedergabeanweisung, so dass der Prozess vor dem Unterbrechungsprozess wieder ausgeführt wird, ohne den Wiedergabeprozess durchzuführen. Wenn das Wiedergabesignal LAUF = „1" ist, fährt der Programmablauf mit Schritt SC2 fort, um den Wiedergabeprozess durchzuführen.
In Schritt SC2 wird K von einem Wert des Registers ZEIT subtrahiert. Wie oben beschrieben, wird der Wert K entsprechend dem Spieltempo und einem Unterbrechungsintervall bestimmt.
In Schritt SC3 wird geprüft, ob das Register ZEIT = „0" oder kleiner ist oder nicht. Wenn nicht, werden die Textdaten nicht verarbeitet, um den Prozess zu beenden und zum Prozess vor dem Unterbrechungsprozess zurückzukehren. Wenn entschieden wird, dass das Register ZEIT = „0" oder kleiner ist, rückt der Programmablauf zu Schritt SC4 vor.
In Schritt SC4 wird eine Adresse des Textereignisbereichs des RAM inkrementiert, um die Daten entweder von den Zeitdaten oder den Zeilenereignisdaten zu lesen.
In Schritt SC5 wird geprüft, ob die gelesenen Daten Zeitdaten sind oder nicht. Wenn nicht, handelt es sich bei den gelesenen Daten um Zeilenereignisdaten und der Programmablauf rückt zu Schritt SC7 vor.
In Schritt SC7 werden die Zeilenereignisdaten der Anzeige 14 zugeführt, und der Programmablauf kehrt zu Schritt SC4 zurück, um den obigen Prozess für die nächsten Daten zu wiederholen.
Wenn in Schritt SC5 entschieden wird, dass die gelesenen Daten Zeitdaten sind, rückt der Programmablauf zu Schritt SC6 vor, wo die gelesenen Zeitdaten zum Register ZEIT addiert werden.
In Schritt SC8 wird geprüft, ob das Register ZEIT größer als „0" ist oder nicht. Wenn nicht, kehrt der Programmablauf zu Schritt SC4 zurück, um den obigen Prozess für die nächsten Daten zu wiederholen. Wenn entschieden wird, dass das Register ZEIT größer als „0" ist, wird der Unterbrechungsprozess beendet, um zum Prozess vor dem Unterbrechungsprozess zurückzukehren.
Eine weitere Ausführungsform wird beschrieben, bei der zusätzlich zu den Spieldaten und Textdaten Hilfsdaten verwendet werden. Die Hilfsdaten schließen das Datum der öffentlichen Vorführung von Musikdaten, den Namen des Herstellungslandes, Programmgenre, Programmtaktteil, Beat, Hauptmusikinstrumenttypen für eine Melodie, Sängergeschlecht, Programmkomponist, Programmtextautor, Programmarrangeur, Spieler-/Sängername oder Spielergruppen-/Sängergruppenname, Musikdatenhersteller und dergleichen ein.
Das Programmgenre zeigt die Art der Musik, wie z. B. Rock, Pop, Jazz oder Latin, an. Der Taktteil zeigt die Anzahl von Schlägen in jedem Takt an, typischerweise z. B. dreifach oder vierfach. Der Beat zeigt die Anzahl der Anschläge in jeden Takt an und im Falle eines Programms mit Viertaktmusik werden allgemein vier Schläge, acht Schläge und sechzehn Schläge verwendet. Shuffle und Swing sind Beatarten. Die Hauptmusikinstrumenttypen für die Melodie zeigen Klangfarben der Musikinstrumente an, die die Melodieteile spielen. Das Sängergeschlecht zeigt männliches Solo, weibliches Solo, männliches und weibliches Duett, männlich, weiblich oder gar kein Lied an.
Die Hilfsdaten werden der Anzeige 14 zugeführt und zum Versorgen eines Bedieners mit verschiedenen Informationen der Spieldaten oder dafür verwendet, dass ein Bediener Suchbedingungen zum Suchen von Spieldaten bestimmen kann, die mit den Suchbedingungen übereinstimmen. Drei Beispiele für das Format der Hilfsdaten sind in den 12A bis 14C gezeigt.
12A bis 12B zeigen ein erstes Datenformat.
Die 12A zeigt das Format eines Sequenzfiles FL1. Ein Satz von Musikdaten wird durch ein Sequenzfile FL1 dargestellt. Das Sequenzfile FL1 wird im Festplattenlaufwerk 22 oder dergleichen gespeichert. Das Sequenzfile FL1 weist einen Kopfabschnitt und einen Rumpfabschnitt TC auf. Der Kopfabschnitt HC enthält Informationen (Identifikationscode des ersten, zweiten oder dritten Datenformats) und Informationen über die Zeitauflösung der Daten. Die Struktur des Spurabschnitts TC wird nun beschrieben.
12B zeigt die Datenstruktur des Spurabschnitts TC. Der Spurabschnitt TC weist mehrere Datensätze (Hilfsdaten AA, Spieldaten SS1, Textdaten LL1, ... ) auf.
Die Hilfsdaten AA weisen Zeitdaten TA1 und Hilfsdaten AD1 auf. Die Zeitdaten TA1 zeigen eine Zeitdauer vom Beginn der Spieldaten bis zu den Hilfsdaten AD1 an und speichern allgemein eine Zeit „0". Mit anderen Worten, die Hilfsdaten AD1 werden zur selben Zeit erzeugt, zu der das Musikspiel beginnt. Die Hilfsdaten AD1 werden in einer Meta-Ereignisform gespeichert, die eine große Menge von oben beschriebenen Hilfsdaten enthält.
Die Spieldaten SS1, SS2, Textdaten LL1, LL2 weisen dieselbe Struktur auf, wie sie in 3B beschrieben ist, und deshalb wird ihre Beschreibung fortgelassen.
Die 13A bis 13C zeigen ein zweites Datenformat. Ein Satz von Musikdaten wird durch ein Sequenzfile FL1 dargestellt. Das Sequenzfile FL1 weist einen Kopfabschnitt HC, einen Rumpfabschnitt TC, einen Textabschnitt LC und einen Hilfsdatenabschnitt AC auf. Der Kopfabschnitt HC hat dieselbe Struktur wie der Kopfabschnitt des ersten Datenformats (12A). Die Strukturen des Spurabschnitts TC und des Textabschnitts LC, die in den 13B und 13C gezeigt sind, sind dieselben wie die in den 4A bis 4C beschriebenen, und daher wird ihre Beschreibung fortgelassen.
Der Hilfsdatenabschnitt AC weist dieselbe Struktur auf, wie die Hilfsdaten AA1, die in 12B gezeigt sind. Die Inhalte der Hilfsdaten AA1 werden, mit anderen Worten, unabhängig als ein Abschnitt gespeichert.
14A bis 14C zeigen ein drittes Datenformat.
14A zeigt die Format des Sequenzfiles FL1, Textfiles FL2 und Hilfsfiles FL3. Ein Satz von Musikdaten wird durch ein Sequenzfile FL1, ein Textfile FL2 und ein Hilfsfile FL3 dargestellt und in einem Festplattenlaufwerk 22 oder dergleichen gespeichert.
Die Struktur des Sequenzfiles FL1 und des Textfiles FL2 sind dieselben wie die anhand der 5A bis 5C beschriebenen. Das Hilfsdatenfile FL3 ist ein neu erzeugtes File, um Hilfsdaten zum Sequenzfile FL1 und Textfile FL2 hinzuzufügen. Das Hilfsdatenfile FL3 speichert dieselben Inhalte wie der Hilfsdatenabschnitt AC, der in Verbindung mit 13A beschrieben wurde.
15 ist ein Flussdiagramm, das den Fileauswahlprozess zeigt, der durch die CPU auszuführen ist.
In Schritt SD1 wird ein File bezeichnet. Sequenzfilenamen von Musikdaten, die im Festplattenlaufwerk 22 oder dergleichen gespeichert sind, werden auf der Anzeige 14 angezeigt. Ein Bediener wählt ein gewünschtes File unter Verwendung des Eingabegeräts 13, wie zum Beispiel einer Tastatur oder Maus, aus. Das Format des vom Bediener ausgewählten Files kann eines der ersten bis dritten Datenformate sein.
Im Schritt SD2 werden Daten des Spurabschnitts des ausgewählten Files ausgelesen. Ein Identifikationscode, der den Beginn des Spurabschnittes darstellt, ist in dem File enthalten. Die Position des Spurabschnittes kann durch diesen Identifikationscode identifiziert werden.
Bei den aus dem Spurabschnitt ausgelesenen Daten handelt es sich um Textereingisdaten, Spielereignisdaten oder Hilfsdaten. In Schritt SD3 wird geprüft, ob die gelesenen Daten Hilfsdaten sind. Im Falle von Hilfsdaten rückt der Programmablauf zu Schritt SD4 vor, wo ein Prozess abhängend von der Art der Hilfsdaten ausgeführt wird. Zum Beispiel werden Hilfsdaten der Anzeige 14 zugeführt, um verschiedene Informationen von Spieldaten anzuzeigen, oder die Hilfsdaten werden in ein vorbestimmtes Register geschrieben, um einen später auszuführenden Suchprozess vorzubereiten, wobei der Suchprozess nach Spieldaten sucht, die mit den Suchbedingungen übereinstimmen, wobei sie wenigstens einen Satz von Hilfsdaten enthalten.
Wenn die gelesenen Daten Spieldaten oder Textdaten sind, springt der Programmablauf zu Schritt SD5, wo geprüft wird, ob alle Daten aus dem Spurabschnitt ausgelesen sind oder nicht. Wenn nicht, kehrt das Programm zu Schritt SD2 zurück, um denselben Prozess wie oben für die nächsten Daten im Spurabschnitt zu wiederholen. Wenn alle Daten ausgelesen sind, rückt der Programmablauf zu Schritt SD6 vor.
In Schritt SD6 wird geprüft, ob die aus dem Spurabschnitt ausgelesenen Daten Hilfsdaten enthalten oder nicht. Falls sie enthalten sind, handelt es sich um das erste Datenformat (12A und 12B), und der Fileauswahlprozess wird beendet.
Wenn in Schritt SD6 entschieden wird, dass die aus dem Spurabschnitt ausgelesenen Daten keine Hilfsdaten enthalten, handelt es sich entweder um das zweite oder dritte Datenformat (13A bis 13C, 14A bis 14C), und der Programmablauf rückt zu Schritt SD7 vor, um einen anderen Prozess für Hilfsdaten auszuführen.
In Schritt SD7 wird ein Hilfsdatenabschnitt von dem ausgewählten Sequenzfile gesucht. Wenn es sich um das zweite Datenformat handelt, ist ein Identifikationscode, der einen Beginn des Hilfsdatenabschnitts darstellt, in, dem File enthalten. Die Position des Hilfsdatenabschnitts kann durch diesen Identifikationscode identifiziert werden.
In Schritt SD8 wird geprüft, ob der Hilfsdatenabschnitt gefunden ist oder nicht. Falls gefunden, handelt es sich um das zweite Datenformat und der Programmablauf rückt zu Schritt SD9 vor, wo ein Prozess für die Hilfsdaten ähnlich zum Schritt SD4 durchgeführt wird.
Wenn in Schritt SD8 entschieden wird, dass kein Hilfsdatenabschnitt gefunden wurde, handelt es sich um das dritte Datenformat (14A bis 14C), und der Programmablauf rückt zu Schritt SD10 vor.
In Schritt SD10 wird ein Hilfsdatenfile mit demselben Filenamen wie das ausgewählte Sequenzfile gesucht. Wie in den 14A bis 14C gezeigt, weist das dritte Datenformat ein Sequenzfile FL1 und ein separat gespeichertes Hilfsdatenfile FL3 auf.
Zum Beispiel weist ein Sequenzfile einen Filenamen „ABCD.MID" auf und ein Hilfsdatenfile hat den Filenamen „ABCD.ASS". Ein Filename weist einen Hauptteil auf wie z. B. ABCD und einen Erweiterungsteil wie z. B. MID oder ASS. Diese beiden Files haben denselben Hauptteil aus dem Filenamen „ABCD" und unterschiedliche Filenamenerweiterungsteile „MID" und „ASS". Die Erweiterung „MID" zeigt ein Sequenzfile an und „ASS" zeigt ein Hilfsdatenfile an.
Nimmt man an, dass das Sequenzfile „ABCD.MID" ausgewählt wurde, dann wird ein Hilfsdatenfile „ABCD.ASS" mit demselben Hauptteil des Filenamens gesucht.
In Schritt SD11 wird geprüft, ob ein Hilfsdatenfile gefunden wurde oder nicht. Falls gefunden, rückt der Programmablauf zu Schritt SD12 vor.
In Schritt SD12 wird der Prozess abhängig von der Art der Hilfsdaten in dem gefundenen Hilfsdatenfile ähnlich wie in Schritt SD4 ausgeführt.
Wenn in Schritt SD11 entschieden wird, dass kein Hilfsdatenfile gefunden wurde, rückt der Programmablauf zu Schritt SD13 vor. In Schritt SD13 wird eine Nachricht „keine Hilfsdaten" auf der Anzeige 14 angezeigt, um den Prozess zu beenden.
Mit dem obigen Prozess werden Hilfsdaten der ersten bis dritten Datenformate ausgelesen, und jeder Prozess wird abhängig von der Art der Hilfsdaten ausgeführt.
Bei den obigen Ausführungsformen wird die Prioritätsordnung in Reihenfolge von den ersten, zweiten und dritten Datenformaten höher eingestellt, um äußerst bevorzugt Textdaten oder Hilfsdaten des ersten Datenformats zu verwenden. Die Prioritätsreihenfolge kann geändert werden. Wenn z. B. die höchste Prioritätsordnung dem dritten Datenformat gegeben wird, können Textdaten oder Hilfsdaten durch Erstellen des neuen Textdatenfiles oder neuen Hilfsdatenfiles aktualisiert werden.
Die Hilfsdaten sind nicht auf nur die oben beschriebenen beschränkt, sondern jeder andere Datentyp kann verwendet werden, der Spieldaten enthält. Zum Beispiel können die Hilfsdaten dieser Ausführungsform Daten enthalten, die Stimmen, wie z. B. Lieder und Hintergrundchor, zu Spieldaten hinzufügen und Daten, die zusätzliche Begleitklänge (z. B. Begleitmusterdaten) zu den Spieldaten hinzufügen.
Sogar, wenn Musikdaten verschiedener Formate, wie sie beispielhaft gezeigt wurden, zugeführt werden, können sie wie oben zur Wiedergabe in Daten des Standardformats umgewandelt werden. Spieldaten, die durch Verwenden verschiedener Anwendungssoftware erzeugt werden, können daher wiedergegeben werden.
Spieldaten ohne Textdaten können auf einfache Weise mit Textdaten versehen werden. Zum Beispiel können automatische Spieldaten von elektronischen Musikinstrumenten mit einer Karaokemaschine zum Mitsingen durch Hinzufügen eines Textfiles wie im Falle des dritten Datenformats verwendet werden.
Sogar, wenn Musikdaten verschiedener Formate hinzugefügt werden, können Hilfsdaten verlässlich verwendet werden.
Spieldaten ohne Hilfsdaten können auf einfache Weise mit Hilfsdaten versehen werden. Durch Hinzufügen von Hilfsdaten zu Spieldaten können Spieldaten auf einfache Weise gesucht werden, und verschiedene Informationen der Spieldaten können dem Bediener angegeben werden.
Da Musikdaten in Spieldaten und Textdaten getrennt und in verschiedene Bereiche gespeichert werden, können die Prozesse für Spieldaten und Textdaten unabhängig gesteuert werden. Wenn dem Prozess für die Spieldaten eine höhere Prioritätsordnung gegeben wird, kann eine Verzögerung bei der Verarbeitung von Spieldaten vermieden werden, sogar, wenn die Belastung des Textdatenprozesses groß ist.
Ein Zeilenereignisdatum bis zum Zeilenumbruchsymbol wird im Textereignisbereich gespeichert und kollektiv angezeigt. Stattdessen können Zeilenereignisdaten in Einheiten von Zeichen oder Wörtern angezeigt werden.
Die Textdaten können vor-ausgelesen werden, um sie anzuzeigen, bevor die Spieldaten wiedergegeben werden. In diesem Fall, kann die Spielposition der entsprechenden Textdaten mit unterschiedlicher Farbe oder einer Unterstreichung angezeigt werden.
Beim Ändern des Wiedergabetempos kann die Periode des Tempotaktgebers verändert werden, der Wert der Zeitdaten kann ohne Veränderung des Tempotaktgebers modifiziert werden oder es kann ein Wert, der durch einen Prozess gezählt wird, verändert werden.
Nicht nur Spieldaten und Textdaten, sondern auch Videodaten können verarbeitet werden. In diesem Fall können Bilddaten unabhängig verarbeitet werden, oder sie können verarbeitet werden, wenn die Textdaten verarbeitet werden, falls Videodaten mit ruhenden Bildern verwendet werden.
Die Ausführungsformen können auf Kommunikationen mit Karaokemaschinen zum Mitsingen oder Personalcomputer angewendet werden, entweder empfangsseitig oder übertragungsseitig.
Die oben beschriebenen Datenformate, dienen nur der Veranschaulichung. Das Format der Spieldaten kann eine Kombination eines Ereignisses und einer relativen Zeit, eine Kombination eines Ereignisses und einer absoluten Zeit, eine Kombination einer Tonhöhe und einer Notenlänge oder ein direktes Aufzeichnungsschema (Vorliegen/Nichtvorliegen eines Ereignisses wird für jede Einheitszeitdauer aufgezeichnet) sein.
Das Datenformat kann jeden Kanal in einer getrennten Spur oder mehrere Kanäle in einer Spur enthalten.
Die vorliegende Erfindung wurde in Verbindung mit bevorzgten Ausführungsformen beschrieben. Die Erfindung ist nicht nur auf die obigen Ausführungsformen beschränkt. Es ist für Fachleute offensichtlich, dass verschiedene Modifikationen, Verbesserungen und dergleichen gemacht werden können, ohne vom Umfang der beigefügten Ansprüche abzuweichen.

Claims

Verarbeitungssystem für Musikdaten, das folgendes aufweist: Speichermittel (19) zum Speichern der Spieldaten mit einem die Spieldaten identifizierenden Dateinamen und zum Speichern von den Spieldaten entsprechenden Zusatzdaten mit einem Dateinamen, der mit dem Dateinamen der Spieldaten verwandt ist; Bezeichnungsmittel (12, 13) zum Bezeichnen eines Dateinamens der wiederzugebenden Spieldaten; Spieldaten-Wiedergabemittel (4) zum Lesen der Spieldaten mit dem durch die Bezeichnungsmittel (12, 13) bezeichneten Dateinamen und zum Wiedergeben der Spieldaten; Suchmittel zum Suchen von Zusatzdaten mit einem Dateinamen, der mit dem Dateinamen der durch die Bezeichnungsmittel (12, 13) bezeichneten Spieldaten verwandt ist; und Zusatzdaten-Verarbeitungsmittel zum Lesen der gesuchten Zusatzdaten mit dem Dateinamen, der mit dem durch die Bezeichnungsmittel bezeichneten Dateinamen verwandt ist.
Verarbeitungssystem für Musikdaten nach Anspruch 1, bei dem die Speichermittel (19) Spieldaten mit einem Dateinamen und Zusatzdaten mit einem Dateinamen speichern, der jeweilige Dateinamen einen Hauptteil und einen Erweiterungsteil aufweist, der die Spieldaten oder die Zusatzdaten identifiziert, die Bezeichnungsmittel (12, 13) einen Hauptteil eines Dateinamen bezeichnen, die Spieldaten-Wiedergabemittel (3) die Spieldaten mit einem Dateinamen lesen, von welchem der Hauptteil durch die Bezeichnungsmittel (12, 13) bezeichnet wurde und die Spieldaten wiedergibt, und die Suchmittel die Zusatzdaten mit einem Dateinamen suchen, von welchem der Hauptteil durch die Bezeichnungsmittel (12, 13) bezeichnet wurde und wobei der Erweiterungsteil die Zusatzdaten identifiziert.
Verarbeitungssystem für Musikdaten, das folgendes aufweist: Speichermittel (19) zum Speichern von Spieldaten und Zusatzdaten in einem ersten Speicherformat oder in einem zweiten Speicherformat; erste Zusatzdaten-Suchmittel zum Suchen der in dem ersten Speicherformat gespeicherten Zusatzdaten; zweite Zusatzdaten-Suchmittel zum Suchen der in dem zweiten Speicherformat gespeicherten Zusatzdaten; und Zusatzdaten-Verarbeitungsmittel zum Verarbeiten von Zusatzdaten, wenn die Zusatzdaten des ersten Speicherformats von den ersten Zusatzdaten-Suchmitteln gefunden werden können, und wenn die Zusatzdaten des ersten Speicherformats von den ersten Zusatzdaten-Suchmitteln nicht gefunden werden können, Verarbeiten von Zusatzdaten, wenn die Zusatzdaten des zweiten Speicherformats von den zweiten Zusatzdaten-Suchmitteln gefunden werden können.
Verarbeitungssystem für Musikdaten nach Anspruch 3, bei dem die ersten und zweiten Speicherformate jeweils eine Kombination von zwei Formaten sind, die aus einer Gruppe ausgewählt werden, welche aus einem Speicherformat besteht, das sowohl Spieldaten als auch Zusatzdaten in der gleichen Datei in einem gemischten Zustand speichert, einem Speicherformat, das Spieldaten und Zusatzdaten getrennt in der gleichen Datei speichert, und einem Speicherformat, das Spieldaten und Zusatzdaten in verschiedenen Dateien getrennt speichert.
Verarbeitungssystem für Musikdaten nach irgendeinem der Ansprüche 1–4, bei dem die Zusatzdaten Textdaten sind.
Verarbeitungssystem für Musikdaten nach Anspruch 1 oder 3, bei dem die Zusatzdaten wenigstens eines von nachgenannten Punkte aufweisen: Musikdaten, Name des Herstellungslandes, Programmart, Programmtaktart, Programmtaktschlag, Hauptmusikinstrumententypen für ein Lied, Sängergeschlecht, Programmverfasser, Programmtextauthor, Programmarrangeur, Spieler/Sängername oder Spielergruppe/Sängergruppenname und Musikdatengenerator.
Verfahren zum Verarbeiten von Musikdaten, das die folgenden Schritte aufweist: Bezeichnen eines Dateinamens von wiederzugebenden Spieldaten (SD1); Suchen einer Datei von Spieldaten und einer Datei von Zusatzdaten, die durch einen dem Dateinamen der Spieldaten verwandten Dateinamen identifiziert sind, unter Verwendung des bezeichneten Dateinames der Spieldaten als einen Suchschlüssel; und Lesen der Spieldaten und Zusatzdaten aus den gesuchten zwei Dateien, um die Spieldaten wiederzugeben und die Zusatzdaten zu verarbeiten (SD2).
Verfahren zum Verarbeiten von Musikdaten nach Anspruch 7, bei dem der Dateiname einen Hauptteil und einen Erweiterungsteil aufweist, der Spieldaten oder Zusatzdaten identifiziert, der Schritt des Bezeichnens eines Dateinamens (SD1) von Spieldaten den Schritt des Bezeichnens eines Hauptteils eines Dateinamens enthält und der Schritt des Suchens einer Datei von Spieldaten und einer Datei von Zusatzdaten den Schritt des Suchens einer Datei von Spieldaten und einer Datei von durch den bezeichneten Hauptteil identifizierten Zusatzdaten aufweist.
Verfahren zum Verarbeiten von Musikdaten, das folgendes aufweist: Suchen aus den Speichermitteln (19), die Spieldaten und Zusatzdaten in einem ersten Speicherformat oder in einem zweiten Speicherformat speichern, von Zusatzdaten des ersten Speicherformats; Verarbeiten der gefundenen Zusatzdaten des ersten Speicherformats; wenn die Zusatzdaten des ersten Speicherformats nicht gefunden werden können, Suchen von Zusatzdaten des zweiten Speicherformats aus den Speichermitteln (19), die Spieldaten und Zusatzdaten in dem ersten oder zweiten Speicherformat speichern; und Verarbeiten der gefundenen Zusatzdaten des zweiten Speicherformats.
Verfahren zum Verarbeiten von Musikdaten nach Anspruch 9, bei dem die ersten und zweiten Speicherformate jeweils eine Kombination von zwei Formaten sind, die aus einer Gruppe ausgewählt werden, welche aus einem Speicherformat besteht, das sowohl Spieldaten als auch Textdaten in der gleichen Datei in einem gemischten Zustand speichert, einem Speicherformat, das Spieldaten und Textdaten getrennt in der gleichen Datei speichert, und einem Speicherformat, das Spieldaten und Textdaten in verschiedenen Dateien getrennt speichert.
Verfahren zum Verarbeiten von Musikdaten nach einem der Ansprüche 7–10, bei dem die Zusatzdaten Textdaten sind.
Verfahren zum Verarbeiten von Musikdaten nach Anspruch 7 oder 9, bei dem die Zusatzdaten wenigstens eines von nachgenannten Punkten aufweisen: Musikdaten, Name des Herstellungslandes, Programmart, Programmtaktart, Programmtaktschlag, Hauptmusikinstrumententypen für ein Lied, Sängergeschlecht, Programmverfasser, Programmtextauthor, Programmarrangeur, Spieler/Sängername oder Spielergruppe/Sängergruppenname und Musikdatengenerator.
Maschinenlesbares Medium, das Befehle enthält, die Maschine zum Durchführen eines Verfahrens zum Verarbeiten von Musikdaten zu veranlassen, wobei das Verfahren die folgenden Schritte aufweist: Bezeichnen (SD1) eines Dateinamens von wiederzugebenden Spieldaten; Suchen einer Datei von Spieldaten und einer Datei von Zusatzdaten, die durch einen dem Dateinamen der Spieldaten verwandten Dateinamen identifiziert sind, unter Verwendung des bezeichneten Dateinames der Spieldaten als einen Suchschlüssel; und Lesen (SD2) der Spieldaten und Zusatzdaten aus den gesuchten zwei Dateien, um die Spieldaten wiederzugeben und die Zusatzdaten zu verarbeiten.
Maschinenlesbares Medium nach Anspruch 13, bei dem der Dateiname einen Hauptteil und einen Erweiterungsteil aufweist, der Spieldaten oder Zusatzdaten identifiziert, der Schritt des Bezeichnens eines Dateinamens (SD1) von Spieldaten den Schritt des Bezeichnens eines Hauptteils eines Dateinamens enthält und der Schritt des Suchens einer Datei von Spieldaten und einer Datei von Zusatzdaten den Schritt des Suchens einer Datei von Spieldaten und einer Datei von durch den bezeichneten Hauptteil identifizierten Zusatzdaten aufweist.
Maschinenlesbares Medium, das Befehle enthält, die Maschine zum Durchführen eines Verfahrens zum Verarbeiten von Musikdaten zu veranlassen, wobei das Verfahren die folgenden Schritte aufweist: Suchen aus den Speichermitteln (19), die Spieldaten und Zusatzdaten in einem ersten Speicherformat oder in einem zweiten Speicherformat speichern, von Zusatzdaten des ersten Speicherformats; Verarbeiten der gefundenen Zusatzdaten des ersten Speicherformats; wenn die Zusatzdaten des ersten Speicherformats nicht gefunden werden können, Suchen von Zusatzdaten des zweiten Speicherformats aus den Speichermitteln (19), die Spieldaten und Zusatzdaten in dem ersten oder zweiten Speicherformat speichern; und Verarbeiten der gefundenen Zusatzdaten des zweiten Speicherformats.
Maschinenlesbares Medium nach Anspruch 15, bei dem die ersten und zweiten Speicherformate jeweils eine Kombination von zwei Formaten sind, die aus einer Gruppe ausgewählt werden, welche aus einem Speicherformat besteht, das sowohl Spieldaten als auch Textdaten in der gleichen Datei in einem gemischten Zustand speichert, einem Speicherformat, das Spieldaten und Textdaten getrennt in der gleichen Datei speichert, und einem Speicherformat, das Spieldaten und Textdaten in verschiedenen Dateien getrennt speichert.
Maschinenlesbares Medium nach einem der Ansprüche 13–16, bei dem die Zusatzdaten Textdaten sind.
Maschinenlesbares Medium nach Anspruch 13 oder 15, bei dem die Zusatzdaten wenigstens eines von nachgenannten Punkten aufweisen: Musikdaten, Name des Herstellungslandes, Programmart, Programmtaktart, Programmtaktschlag, Hauptmusikinstrumententypen für ein Lied, Sängergeschlecht, Programmverfasser, Programmtextauthor, Programmarrangeur, Spieler/Sängername oder Spielergruppe/Sängergruppenname und Musikdatengenerator.