ich widerhole mich gerne aber ich habe in Java nicht wirklich den durchblick

eigendlich gehts immer noch um das: (aber nur am Rande)
http://www.tutorials.de/java/380952-...ound-midi.html

gut ich habe also eine Classe mit einem Interface Transmitter - da kommen daten her
dann gibts eine andre Classe da gibts das gegenstück auch ein Interface Receiver

nun gibts ja auch noch bei Java.IO
DataInputStream und DataOutputStream

kann ich ein bestehendes Interface erweitern um an den Datenstrom der da irgenwo fliesst ranzukommen ?
wenn ja dann könnte ich ja doch meine unerwüschten Daten rausfiltern

Zunächst mal wäre es wichtig zu klären was genau du mit Interface meinst.
Meinst du den Klassen-Typ Interface ?
Oder meinst du eine bestimmte Hardware *z.B. NIC = Network Interface Card* ?
Oder bezeichnest du mit Interface lediglich eine Software welche *analog zu einem Hardware-Interface* Daten von einem Medium in ein anderes Umsetzt ?

Wenn du so direkt fragst , ob es möglich ist ein Interface *im Sinne von Klassen-Typ* zu erweitern : JA
Ist es möglich damit die Implementierung zu verändern : JAIN ... du kannst zwar der Implementierung vorgeben welche Methoden zu implementieren sind ... wenn diese aber keinen Inhalt haben ändert es rein logisch nichts an der alten Implementierung.

Hier sind also noch weitere Infos nötig ... vor allem deine Definition des Wortes Interface ... und auch wenn möglich den Source der geannten Klassen.

Zitat von melmager

nun gibts ja auch noch bei Java.IO
DataInputStream und DataOutputStream

kann ich ein bestehendes Interface erweitern um an den Datenstrom der da irgenwo fliesst ranzukommen ?
wenn ja dann könnte ich ja doch meine unerwüschten Daten rausfiltern

Wenn Du das folgende Buch in der HTML-Version installierst Handbuch der Java Programmierung findest Du im Kapitel 19 ausführliche Erläuterungen zu Datenströmen und Filtern.

Mal davon abgesehen das dieses Werk veraltet ist *letzte Aktulisierung 2007* , nicht wirklich Informativ ist *dein Kapitel 19 ist wirklich sehr dürftig ... da findet man in der JavaInsel deutlich mehr* und auch nicht gerade ansprechend aussieht ... sollte man das Entpacken eines ZIP-Files nicht mit Installieren gleichsetzen.

Allgemein trägt dein Post hier eher weniger zur Lösung bei als du denkst ... denn TO wollte wissen wie er ein "Interface" *in welchem Sinne auch immer* durch Ableitung so verändern kann das dierekte Eingriffe in die Funktionsweise möglich werden. Ob das überhaupt möglich ist wird wenn dann nur aus dem Source des "Interfaces" ersichtlich. Wie man dann weiter mit den Streams arbeitet *es wurde hier deutlich erwähnt : Data*Stream ... welche meines erachtens NICHT zu den Low-Level Byte*Stream gehören* steht im Moment weder zur Debatta noch war das bis jetzt gefragt.

*Ich liebe es das jemanden an den Kopf zu werfen : dein Post hat das Thema VERFEHLT*

Zitat von SPiKEe

Mal davon abgesehen das dieses Werk veraltet ist *letzte Aktulisierung 2007* , nicht wirklich Informativ ist *dein Kapitel 19 ist wirklich sehr dürftig ... da findet man in der JavaInsel deutlich mehr* und auch nicht gerade ansprechend aussieht ... sollte man das Entpacken eines ZIP-Files nicht mit Installieren gleichsetzen.

Sei bitte genauer wenn Du etwas kritisierst: Was hat seit 2007 am JDK/SDK an den im Kapitel 19 behandelten Klassen konkret geändert?

Zitat von SPiKEe

Allgemein trägt dein Post hier eher weniger zur Lösung bei als du denkst

Woher willst Du wissen, was ich denke! Immerhin kann der TO im Kapitel 19 entnehmen, welche Klassen welches Interfaces implementieren. Im Übrigen gibt es eine aktualisierte 6. Auflage, siehe hier

Zitat von melmager

nun gibts ja auch noch bei Java.IO
DataInputStream und DataOutputStream

kann ich ein bestehendes Interface erweitern um an den Datenstrom der da irgenwo fliesst ranzukommen ?
wenn ja dann könnte ich ja doch meine unerwüschten Daten rausfiltern

Im Kapitel 19 meines Links wird folgendes gesagt:

Die Aufgabe der aus FilterInputStream abgeleiteten Klassen besteht darin, die Lesezugriffe abzufangen, in einer für sie charakteristischen Weise zu verarbeiten und die Daten erst dann an den Aufrufer weiterzugeben.

Du könntest nun eine eigene Klasse erzeugen, welches die Klasse FilterInputStream erweitert und im Konstruktor dein verwedetes DataInputStream als Argument bekommt. Im Konstuktor muss man das Argument mit super() der erweiterten Klasse übergeben. Je nachdem was Du filtern willst, kann der Konstruktor weitere Argumente annehmen. Innerhalb dieser Klasse musst Du die read() Methode gemäss Deinem Filter überschreiben.

Der Aufruf instantiiert diese Klasse und übergibt den DataInputStream an die Filterklasse. Nun werden alle reads() über den überschriebenen read() geleitet und wie gewünscht gefiltert.

Also ich meine ein interface in java.
und zwar das :
javax.sound.midi
Interface Transmitter
und nein es ist kein File - wenn ich mit java.io ein file öffne ist mir ja klar wo der stream ist -
ein filestrem gibts bei MIDI leider nicht

und da ich nicht weiss wo ich den Quellcode herbekommen soll fällt die analyse auch aus ...

also doch projekt beerdigen

Achso ... dann sag das doch gleich das du immer noch an deinem MIDI-Projekt sitzt und das du eine Interface-Klasse meinst ... dann hätte man dir viel schneller eine Antwort geben können :

Es bringt dir nichts wenn du ein eigenes Interface von javax.sound.midi.Transmitter ableitest ohne eine konkrete Implementierung. Du müsstest wenn also eine Klasse haben die eine konkrete Implementierung des Interfaces ist und von dieser ableiten. Und ob du es dann schaffst an die gewünschten Informationen zu kommen ist auch fraglich.

Um also auf deine Frage dierekt zu antworten : NEIN ! Du könntest allerhöchstens was mit der konkreten Implementierung anfangen.

Zitat von melmager

eigendlich gehts immer noch um das: (aber nur am Rande)
http://www.tutorials.de/java/380952-...ound-midi.html

Komm jetzt, lass den Kopf nicht hängen! Darf ich fragen, weshalb Du im obigen Strang die Idee mit dem Midi-File nicht weiterverfolgt hast?

@j2se
Weil es KEIN Midi-File gibt wenn du z.B. den Input von einem Midi-Keyboard lesen willst ... worum es ja im Endeffekt immer noch drum geht.

Das Problem war wohl soweit wie ich es mitbekommen habe das das Keyboard auch Daten sendet wenn man nichts macht ... also eine Art keep-alive Paket nach dem Motto : Hallo , ich bin noch da ...
Und was TO jetzt wollte war halt über das Sound-System an den InputStream kommen um eben diese keep-alive Pakete zu filtern ... was aber nur durch Erweiterung des Interfaces selbst nicht möglich ist ... sondern höchstens wenn man die Implementierung des Interface anzapft oder verändert.

Zitat von SPiKEe

@j2se

Das Problem war wohl soweit wie ich es mitbekommen habe das das Keyboard auch Daten sendet wenn man nichts macht ... also eine Art keep-alive Paket nach dem Motto : Hallo , ich bin noch da ...
Und was TO jetzt wollte war halt über das Sound-System an den InputStream kommen um eben diese keep-alive Pakete zu filtern ... was aber nur durch Erweiterung des Interfaces selbst nicht möglich ist ... sondern höchstens wenn man die Implementierung des Interface anzapft oder verändert.

genauso sieht es aus das Keyboard sendet immer Daten ob Taste gedrückt wurde oder nicht und leider vermurksen diese Daten die einfach nur sagen - ich bin noch da - meine gewollten Daten wie es wurde Taste C gedrückt

Also Java kann MIDI Daten rausgeben aber einlesen von externer Quelle geht einfach nicht

Doch .. sollte schon gehen ... man könnte ja selbst von InputStream oder FilterInputStream ableiten und das als Quelle nutzen *kenne leider deinen kompletten Source nicht daher weis ich nicht ob man irgendwo angreifen könnte*.

Wie wäre es wenn du uns mal deinen bisherigen *hoffentlich noch vorhandenen Source* postest mit dem du Daten vom Keyboard liest ... vielleicht kann man ja doch was machen ... so schnell gebe ich nicht auf ... mit Streams kenn ich mich dann doch sehr gut aus ...

Also Code ist in dem Posting:

http://www.tutorials.de/java/380952-...ound-midi.html

aber da ist weit und breit kein Inputstream was mich ja veranlasste diesen post zu machen ob man auf eine Java-Classe oder Java-Interface man ein Stream draufpacken kann.

ich bin ja schon drauf und dran mal bei oracel anzufragen

In deiner Klasse MidiPort schreibst du in Zeile 92 den Output in eine Datei. Also hast du DA deinen Stream. Denn es gibt neben javax.sound.midi.MidiSystem.write(javax.sound.midi.Sequenz, int, File) auch noch die Methode javax.sound.midi.MidiSystem.write(javax.sound.midi.Sequenz, int, OutputStream).
Was du jetzt machen musst ist die Daten die dort in irgend ein OutputStream geschrieben werden wieder zugänglich machen. Mir würden da spontan ByteArray*Stream oder ein work-around über eine Server-Client- bzw Pipe-Architektur einfallen *bei der genauen Umsetzung kann ich dir dann helfen*.

Diesen dann mitlerweile wieder InputStream kannst du dann als Input für deinen Filter verwenden ...

Wie genau das ganze dann mit Timing und Datenmenge abläuft müsste man dann testen. Aber den grundlegenden Ansatzpunkt wo du an die Daten rankommst haben wir jetzt.

Ich habe die Klasse MidiInDump.java etwas unter die Lupe genommen und diese Klasse kann ein Midi-Dump in die Konsole erzeugen. Somit ist auch ein Dump in einen Stream möglich.

Das ganze könnte man jetzt mit einem FIFO-Stack realisieren : http://de.wikipedia.org/wiki/FIFO
Ich weis jetzt gerade nich aus dem Kopf ob Java sowas von Haus aus mitbringt ... jedoch wie der Zufall will gibt es bei Wikipedia mal wieder ein Java-Beispiel. Wie man das jetzt mit Streams macht ... also einmal als OutputStream damit man daten reinschreiben kann und einmal als InputStream um Daten wieder auszulesen ... hmm ... da würde ich zwei weitere Klassen schreiben.
Der OutputStream füllt den Stack in dem er FIFO.enqueue(<T>) aufruft und der InputStream leert diesen wieder durch aufrufen von FIFO.dequeue().
Das ganze müsste man dann mal einem Test unterziehen ... aber so in etwa sollte es funktionieren.