Interessant - ich frage mich wieso aber keine der Reviews im Internet mit den Zusatz-Feature wirbt.
Das Clonen von der Monitor-Ausgabe sollte kein Problem sein.
Ferndiagnose des Bugs ist schwer. Ich würde daher den Bug an die Linux Distribution melden:
https://help.ubuntu.com/community/ReportingBugs
Die einzelnen Funktionen von USB Geräten sind in der Regel unabhängig - daher kann der USB-Audio Treiber einen Teil problemlos erkennen.
Die für mich interessante Info
Bus 002 Device 004: ID 1926:0086 NextWindow 1950 HID Touchscreen
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 1
bMaxPacketSize0 64
idVendor 0x1926 NextWindow
idProduct 0x0086 1950 HID Touchscreen
Die Treibersituation ist nicht besonders gut:
* Es gibt ein Kernel-Modul, das die USB-Nachrichten vom Touch-Screen an den User-Space weiterleitet. Als Rückgabe-Kanel kommen Touch-Events, die über die üblichen Kernel-Wege weitergeleitet werden.
* Es gibt einen X11-Treiber, der Events vom Kernel übersetzt.
* Dann gibt es noch einen propritären Dämon, der aus den USB Nachrichten die Events erzeugt.
So etwas kann nicht in Linux Distributionen integriert werden. Wahrscheinlich wird sich nichts ändern, bis die Firma. Nextwindow ihren Treiber offenlegt oder jemand einen offen Treiber schreibt.
Meine Vermutung ist, das die Firmware im Monitor "dumm" ist und die meiste Signalverarbeitung der PC im Dämon macht (was offensichtlich nicht offen gelegt werden soll).
=>
nwfermi-Treiber basierte TouchScreens von NextWindow (+ OEM Versionen wie deinen Samsung) sollte man nicht für Linux Rechner kaufen.
http://forums.opensuse.org/english/get-te…926-0093-a.html
PS: Beim Kompilieren des Moduls kann ich notfalls helfen.
Mein Touchscreen ist ein LG L1710S. Er reagiert auf Berührungen, aber der Verlauf des Mauszeigers ist entgegengesetzt zur Fingerbewegung.- Außerdem wird er in der Systemsteuerung (Verzeihung für das böse Wort, bin halt immer noch Windoofs) nicht erkannt.
Ist die Typenbezeichung wirklich richtig? Goggle ist der Meinung, das er kein Touchscreen ist: 
http://reviews.cnet.com/lcd-monitors/l…7-30524052.html
Noch etwas:
Ob eine GUI ein Gerät erkennt oder nicht muss unter Linux nicht mit dessen Funktion im Zusammenhang stehen. GUI und Treiber sind in der Regel unterschiedliche Projekte.
Hast du das Bild am Monitor gedreht? Ansonsten spricht es für einen BUg, das sich der Mauszeiger verkehrt bewegt.
https://help.ubuntu.com/community/ReportingBugs
So waren die Kanäle vertauscht - bei MIDI einstellungen konnte ich sie zwar korrekt zuweisen, aber es tat sich nichts im Ergebnis. Zum Glück habe ich ja auch Hauptwerk. Die Zuweisung der Manuale konnte ich dann in der bewährten Arbeitsweise durchführen.
Hast du die Einstellungen in der Initialen MIDI Konfiguration vertauscht (Die Betonung bei dieser Einstellungseite liegt auf dem Wort "INITIAL").
Ich empfehle das Ding nicht zu nutzen (eventuell sogar dort alles auf NONE zu stellen) und nur über Rechts-Click auf die Element zu arbeiten.
Ich erinnere mich schwach dass auch ich Probleme hatte das GrandOrgue Repository von Martin hinzuzufügen. Irgendwie wurde trotz sudo der Key nicht angenommen.
Es gibt schon seit ein paar Monaten einen Bugreport wegen der Hinweise für Ubuntu:
https://github.com/openSUSE/software-o-o/issues/27
Wenn jemand auf Michaels Frage mit dem Touchscreen eine Lösung hat, werde ich für das normale Üben eine GrandOrgue Installation durchführen, da kann ich dann zumind. die unverschlüsselten Sets spielen.
Du solltest nur abwarten, wenn du das gleiche Modell hast. Wenn du ein anderes Modell hast, ist das abwarten sinnlos. Hier geht es um ein "Treiberfrage", die man von Modell zu Modell neu beantworten muss.
Wie die MIDI Einbindung gelöst wird, wäre dann auch noch zu klären.
Was ist dein MIDI Interface?
USB-Midi Interfaces sollten Plug&Play sein (dh. alle Interfaces, die die USB MIDI Spezifikation umsetzen).
Firewire MIDI Interfaces gehen in der Regel nur mit Jack und Userspace Treiber - da sollte man die Treibersituation vorher noch einmal abchecken.
MIDI vom m-audio 2496 scheint auch Problemlos zu sein.
Kannst du ein
sudo lsusb -v
posten, wenn der Touch-Screen am USB hängt?
Zu den Ubuntu-Drucker-Install GUI muss jemand anderer helfen.
Wenn dein Drucker von schon installierten Gutenprint-Packet unterstützt wird, würde ich auf
http://localhost:631/ gehen und dort den Drucker hinzufügen.
Man wird wahrscheinlich die root-Kennung (root + Root-Passwort) brauchen. Falls dein Ubuntu keines hat, in einen Terminal:
sudo /bin/sh
passwdVom Umfang her wird es komplett sein, ein Ausbau von Funktionen macht den Entwicklern nur das Leben schwerer.
http://www.libreoffice.org/download/portable/
Musst es ausprobieren, ob es passt - ich habe so etwas noch nie gebraucht.
Bezüglich (ausgefallener) Schriften und Drittobjekten (dh. nicht Teile von Libreoffice) hilft das aber nur bedingt.
Auch wenn sich komisch anhört:
Exportiere das ganze als PDF (eventuell auch mit eingebetten Schriften) und lade es im Acrobat Reader im Vollbild-Modus.
Schrittweisen Aufblenden muss man eventuell in mehrere Folien auflösen.
Wenn man nicht Interaktiv/Multimedia-lastig ist, funktioniert das mit jeder Plattform.
Bei den Transfer von Präsentationen gibt es (auch bei MS-Office zu MS-Office) mehr zu beachten:
* Schriftarten - Jede Schriftart muss es nicht auf jeden PC geben
* Eingebettete Objekte brauchen das Trägerprogramm auch am Zielcomputer
PS: Ich glaube du fragst nach so etwas: http://portableapps.com/apps/office/libreoffice_portable
Ich würde einfach zuerst versuchen, das Packet gnome-alsamixer zu installieren.
Wenn es nicht anders geht, in einen Terminal
sudo apt-get install gnome-alsamixer
Im Terminal kannst du es dann auch als
gnome-alsamixer
starten.
Dort solltest du dann alle "Regler" deiner Soundkarte sehen. Das Zusatzprogramm wird es wahrscheinlich nur anders präsentieren.
Als Faustregel würde ich zuerst versuchen, bei allen Lautstärke zu erhöhen und "Mute" zu deaktivieren.
Da in den Post die Rede davon ist, das die Lautstärke für Analog erhöht werden soll, sollte das meiner Ansicht nach zum Ziel führen.
Es kann noch ein paar Optionen zum Aktivieren/Deaktivieren geben - diese würde ich erst als zweites probieren.
Zum Thema "Binary-Treiber": Bei Linux wird es nicht gerne gesehen, wenn der Hersteller nur vorkompilierte Treiber anbietet. Gute Hersteller bringen die in die Linux Sourcen ein (Bei Grafik-Karten machen das ATI, Intel) und so sind sie bei jeder Distribution dabei.
Bei Ubuntu wird er wahrscheinlich Unity haben - über den Packet-Manager ist das nachinstallieren von anderen Desktops in ein paar Minuten erledigt.
http://ubuntuforums.org/showthread.php?t=1866995
Es scheint also ein (erweiterter) Lautstärke-Regel auf 0 zu stehen.
Man kann die Binary-Only-Treiber von Nvidia nachinstalleren:
https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia
Da du kaum 3D brauchst, stellt sich für mich die Frage, ob das wirklich notwendig ist.
Was ist mit der Grafik? Ruckeln Effekte? Geringe Auflösung? Geringe Farbtiefe?
Desweiteren kamen mir persönlich die Hauptwerk XMLs die ich bisher gesehen habe gerade zu "obscured" vor.
Jede HW Version hat anscheinend ein leicht anderes XML Format (ein paar Tag +/-).
Das "Kurze" Format kann man anscheinend in HW ins "Lange" Format umspeichern - es wird anscheindend nur ein Mapping der XML-Tags gemacht. a steht für das erste Element im Lang-Format, b für das zweite Element usw. Irgendwann geht es mit aa weiter (Ein bis 2 Buchstaben (o?) werden ausgelassen).
Wenn man von einer HW-Version sowohl ein XML im langen wie auch im kurzen Format hat, ist das Mapping dazwischen technisch kein Problem.
Theoretisch könnte man aus dem XML Informationen herausholen und ein ODF daraus generieren.
Das Problem ist nur:
1) So ein ODF wäre ziemlich sicher ein abgeleitetes Werk => Weiterverbreitung nur mit Einverständnis das HW-XML Erstellers nach dessen Bedingungen.
2) HW hat (teilweise) andere, interne Strukturen als GO. Das zu Mappen ist nicht einfach.
http://packages.debian.org/wheezy/iceape
Ich habe versucht, mein Problem genauer herauszuarbeiten:
Beim Paste mit der mittleren Maustaste startet die Oberfläche automatisch eine Umwandlung. Danach kann man nichts mehr ändern.
Anscheinend waren dabei meine erweiterten Versuche so weit vom unterstützen Syntax entfernt, das ich nur meine Eingabe in einen nicht veränderbaren Textfeld gesehen habe.
PS: Ein Weiterbearbeiten der Eingabe wäre wünschenswert.
Interessanter Ansatz - ist vielleicht wirklich Anfängerfreundlicher. Die Webseite könnte man jetzt als Schreibhilfe beim ODF Erstellen nutzen.
Ich persönlich gehe mehr nach Arbeitsersparnis. Für Multi-Releases brauche ich mehrere Pfade pro Pfeife - und das für jeden Stop extra wiederholt. Die Angabe eines Pfad-Prefix + der Release-Zeitpunkt ist wesentlich arbeitssparender. Eine kompakte Beschreibung mit nur ein paar Werten ist ein guter Ausgangspunkt, um mehr zu generieren.
Ich frage mich, ob ein Preprozessor in GO wirklich eine so gute Idee ist. Damit verschwindet die Zwischenstufe ODF. Das ODF ist zwar langatmig zu schreiben - aber sehr einfach zu lesen. Man sieht auf den ersten Blick, welcher Ton zur Pfeife geladen wird. Selbst ich würde nicht nachvollziehen, was mein PHP Code macht, sondern einfach im ODF nachschauen.
PS: Die ganze Javascript basierte Oberfläche hat bei mir immer wieder Probleme gemacht.
Wenn es zu einfach wird, sehe ich die Gefahr, dass jeder an den Orgeln wahllos rummurkst und wir dann endlos viele Mutationen und Kombinationen aus mehreren verschiedenartigen Orgeln erhalten - das will ich dann nicht Gut heißen. Insofern muss ich überlegen, ob ich zumindest was die ODFs für Sets von Sonus Paradisi anbelangt, überhaupt Generator-Skripts veröffentlichen kann. Auch die Lizenz der ODFs speziell für diese Sets wäre dann möglicherweise nochmal zu überdenken. Auch Joseph Basquin hat ja schon angedeutet, dass er es nicht gerne sehen würde, wenn jeder an seinem Sampleset herumschraubt.
Ich sehe es nicht als Gefahr, wenn die GO User ODFs basteln. Ich sehe das als Freiheit für die User, das sie sich das schaffen (bzw. es zumindestens versuchen), was es sonst nicht gibt.
Meine persönliche Ansicht ist, das Mutationen und Kombinationen auf eine Anpassung der Intonation hinauslaufen (wenn es gut werden soll) - das passiert in der Regel nicht. Wer es nicht glaubt, soll die verschiedenen Zwischenstuffen vom GO Demo set ausprobieren.
Mit einer restriktiven Lizenz hälts du das kaum auf. Ein ODF für eine Kombiorgel ist generierbar. Ich habe mich bis jetzt nur auf die Pipe999 Liste konzentriert und das drum herum noch nicht etwas automatisiert. 
Der beste technische Schutz davor ist meiner Ansicht nach eine fotorealistische Konsole. Das Auszubauen erfordert einiges an Arbeit - ich glaube, mit der Nutzung einer erweiterten Generierungslogik wäre ein Anfang bei 0 für mich einfacher. Ein zusätzlicher Register-Schalter auf so einer Konsole sieht schrecklich aus.
Die Erstellung von ODFs klappt hier ganz gut. Um sich das Leben zu erleichtern, hat jeder seine nicht öffentlichen Skripte/Tools.
Ich würde hier gerne eingreifen und hier mit etwas OpenSource nachhelfen. Meine Arbeit am Prag ODF war mein Anstoss dazu.
Es wird darauf hinauslaufen, das ich so einen Umbau wie beim Prag ODF auch bei ein paar anderen, freien ODFs mache und die Generator-Skripts veröffentliche (unter BSD/MIT, GPL, CC BY-SA). Damit gibt es offene Vorlagen für andere und nicht jeder muss das Rad neu erfinden. Vielleicht wird sogar einmal ein Baukasten daraus.
Meine Idee wäre, die Skript-Sammlung ganze bei github zu hosten.
Jeder User kann dort im Browser eine Kopie ziehen und Änderungen zur Aufnahme zurückschicken. Man kann es sogar im Browser bearbeiten - ohne viel von der Versionskontrolle dahinter zu sehen.
Die Skripts einfach so zum Download anzubieten (kann man sicher auch zusätzlich machen), wird schief gehen, sobald ein paar Personen zusammenarbeiten.
Kommentare?
Graphische Tools fürs ODF stehen bei mir nicht auf dem Plan. (Persönlich stelle ich die Frage nach den wirklichen Nutzen: Kombi-Samplesets stehe ich kritisch gegenüber - die Samples von verschiedenen Orgeln zu etwas [b]guten[/b ]zu vereinigen, ist wesentlich mehr als Ranks in einen ODF zusammenzufügen. Für die Konversion von HW Samplesets wäre ein HW-XML to ODF Konverter wahrscheinlich sinnvoller). Jetzt aber wieder zurück zum Thema
Ich wäre daran interessiert, wie du das ODF erweitern würdest.
Meine Vermutung dazu ist:
Entweder schlägst du etwas einfaches vor - dann wird bei komplexeren Problemstellungen (wie zB: Prag ODF) weiterhin bei etwas wie meiner Lösung landen.
Oder du schlägst etwas vor, was defakto eine Programmiersprache darstellt.
@mh
Wenn du dich für php interessiert, installier das Packet php5 und suche bei Google nach php tutorial.
Unterschied zu den Webtutorials ist:
* Du schreibest ODF Zeilen statt HTML aus.
* Du startest es per CLI (in einen Terminal: php test.php) und leitest die Ausgabe in eine Datei um (php test.php > test.organ)
Wenn es Fragen gibt, wird sie sicher jemand beantworten.