Beiträge von OrgelRm42

    Ich hab zwar noch eine interne Festplatte mit dem alten Betriebssystem (Mojave) wo auch das funktionierende HW 4.2 werkelt, allerdings geht das nur wenn die anderen Festplatten auf denen Monterey installiert ist ausgebaut sind, starte ich mit allen vier Festplatten und wähle Mojave als Starvolume aus, kommt das Verbotsschild

    und Ende ! Warum das so ist weiß der Himmel oder Apple.

    Das war zu erwarten. Apple istalliert beim Update des Betriebssystems auch gerne neue Firmware, damit kommt aber ein "altes" Betriebssystem nicht klar. Bei Apple gibt's keinen Weg zurück (und wer Apple kauft sollte das wissen ...). Einzige Möglichkeit: das alte OS in einer virtuellen Maschine laufen lassen, ein Mac Pro sollte damit keine Probleme haben.

    Zwei Anmerkungen hier:

    1. Mancher scheint Bittiefe (16 vs. 24) Bit mit Samplerate zu verwechseln. Letztere beschränkt die Bandbreite (also die höchste darstellbare Frequenz). Das ist bei 44.100 Hz aber immer noch 22.050 Hz, weit jenseits dessen was Menschen zu höhren vermögen (und, was gerne übersehen wird: selbst wenn wir sehr hohe Frequenzeb boch hören können (17KHz - 20KHz) so müssen diese extrem laut sein ...).
    2. Bittiefe bestimmt den maximal möglchen Dynamikumfang, also den Unterschied zwischen dem leisesten und dem lautesten möglichen Ton. Der ist bei 16Bit (CD-Qualität) schon exporbitante 96dB, das sollte für eine Orgelpfeife mehr als ausreichen. 24Bit nimmt man nur der "runden" Zahlen wegen, selbst die besten Digital->Analog Konverter schaffen nur 21 bis 22 Bit. Ab dann geht alles im thermischen Rauschen der analogen Komponenten unter. Was sich natürlich auch ändert ist die Lautstärke des digitalen Rauschen, also des Messfehlers/Unterschieds zw. realem Ton und Sample-Representation. Der ist immer ein halbes Bit, d.h. bei 16Bit lauter als bei 24Bit. Aber auch schon bei 16Bit dramatisch gering (oder hört hier jemand das Rauschen bei einer CD?).

    Hallo Haralder,
    danke für deine Rückmeldung. Ich habe Linux Mint 20.3. Also ich habe mal über den terminal gestartet und die Fehlermeldung hier angehängt.
    Das mit dem Livesystem werde ich mal probieren. Wobei ich nicht weiß, was das ist, aber ich lese mich mal ein.
    aeolus_terminal.png

    Wenn ich die erste Fehlermeldung ansehe dann hat es den Eindruck als ob Jackd und Aeolus als unterschiedliche Nutzer gestartet wurden. Der Jack-Server läuft immer nur für einen Benutzer.

    Jeiin (oder jaain?). Die mir bekannten RME Treiber für Linux wurden nicht von RME direkt entwickelt, die Firma hat allerdings den Entwickler unterstützt. Was unter Linux immer läuft sind eben Class-Compliant Geräte (also Hardware die sich an den USB Audio Standard hält). Die waren früher (vor langer Zeit) eher selten, dann hat aber Apple gesagt dass sie (spez. unter iOS) nur noch solche Geräte unterstützen werden. Apples Ruf "lebt" ja gerade davon dass man sich nicht mit Treibern herumärgern muss. Für die meiste Hardware löst Apple das indem man ausschliesslich mit Aple Hardware arbeiten darf, bei Midi und Audiodevices geht das aber nicht. Seit Apple das so ex catedra entschieden hat gibt's fast nur noch standardkonforme Geräte, was den Linuxer natürlich freut. Um so verwunderlicher ist es das das Digiface USB hier nicht dazugehört.

    Zitat

    Hälst du die audio ag für ein so "windiges" Unternehmen?

    Nein, keinesfalls. Aber leider ändert Apple gerne immer mal wieder grosse Teile ihres Audiostacks und plötzlich funktionieren dann Programme nach einem Update nicht mehr. Natürlich stellt Apple allen (zahlenden!) Entwicklern Vorversionen zur Verfügung, aber Audio/Midi/Notation ist ein verschwindend kleiner Markt mit relativ geringen Margen und vergleichsweise kleinen Entwicklerfirmen. Die können nicht jedes Jahr ein Entwicklerteam abstellen um Apple hinterherzuprogrammieren (3 x ein (Jahresgehalt + Sozialkosten) will erst einmal erwirtschaftet werden ...).

    Manche Firmen verlieren dann irgendwann die Lust and dann sitzt man mit einem nicht-supporteden Gerät oder Programm da. Das passiert in der Apple-Audio und Multimediawelt immer mal wieder. Macht Apple manchmal auch selbst: Logic gab's vor dem Besitzerwechsel zu Apple auch in einer Windowsversion ...

    Anyway, just my 0.2$

    Da bin ich als alter Pinguin natürlich "opinionated", muss aber ehrlciherweise eingestehen dass mit PowerShell und noch mehr mit dem Windos Subsystem fpr Linux eig. kein Unterschied zwischen den Systemen mehr besteht. Trauriger Looser: MacOS mit eine Schrott-Terminal und einem Wechsel der Shell (zsh) nur weil sie panische Angst vor GNU-Software haben. Aber die Leute lieben's ja ;-/

    Zitat

    Ich habe ein RME-Digiface. Gibt es eine Chance, das unter Linux zum Laufen zu bekommen? Auch mehrkanalig?

    Das ist sehr schade. Gerade das Digiface USB (von dem reden wir hier, oder?) ist (bescheuerterweise) nicht Class-Compliant (wird also auch unter MacOS nicht wirklich gut laufen). Soweit ich mich entsinne kann man den ALSA-Code patchen und ein Quirk einbauen (dazu gab's im Ardour-Forum mal einen Post), das ist dann aber wirklich Arbeit am Motor. Schade, bei uns waren die alten RMEs lange zeigt die Interfaces der Wahl für Linux. Ich habe hier gute Erfachrungen mit den Arturia AudioFuse Geräten (https://www.arturia.com/products/audio/audiofuse/overview), die kann man auch via Digitalanschluss erweitern. Da gibt's eine Steuersoftware die nur unter Wine läuft, die braucht man aber für den Betrieb nicht.

    Wie genau äussert sich den "tut sich nichts"? Erscheint ein Fenster? Erscheinen die Registerknöpfe? Taucht Aeolus überhaupt in QJackctl auf? BTW, ich bin fast ein wenig in Versuchung hier auch an Stelle von QJackCTL zum steuern von Jack eher Cadence zu empfehlen. Das macht die Einbindung von PulseAudio (wichtig wenn man gleichzeitig auch Videos oder Audio aus dem Browser haben will).

    Das ist der Standardfall, keine Erfahrung damit zu haben. Unter Linux bekommt man zwangsläufig etwas Erfahrung mit dem, was unter der Haube läuft- aber wer will das denn? Kein normaler Anwender.

    Unter Linux _kann_ man unter die Haube schauen, _muss_ es aber nicht. Eine DAW wie Bitwig oder Ardour installiert man einfach und nutzt sie dann (Ardour läuft hier bei uns im Studio für el. Musik seit mind. 16 Jahren). Das selbe gilt für Videobearbeitung mit DavinciRelove - Profiqualität, beeindruckender Funktionsumfang und "rock solid" (hat übrigens den Audio-Code von Faichild, falls das jemandem etwas sagt). Als (auch) Sysadmin kann ich aus unserer Erfahrung sagen dass über die Jahre Linux-Audiostations _deutlich_ pflegeleichter sind als MacOS-Systeme.

    Simples Beispiel ich möchte eine Audio Datei konvertieren von WAV in MP3.

    Windows: Geeignete Software suchen und installieren, bei kostenloser Software wird man sich sonst etwas mitinstallieren. Software die sauber ist kostet Geld. Die Bedienung ist dann etwas in das man sich einarbeiten muss.

    Linux: "ffmpeg -i Datei.wav Ausgabe.mp3" (funktioniert mit allen Formaten inkl. Videos).

    Sorry, aber das stimmt so nicht ganz. Man kann auch unter Linux "geeignete Software" installieren. Mit Audacity (läuft ja auch unter MacOS und Windows) sind das drei Mausklicks.

    Nur um das ein wenig klarzustellen: technisch ist ein "Soundfont" das selbe wie ein "Sampleset". Nur werden die Samples im "Soundfont" alle in einer Datei zusammengefasst (incl. Metainformation). Neben den Samplen selbst kann man auch div. Modulatoren und/oder Filter definieren. Gute Soundfonts haben übrigens auch (mindestens) ein Sample pro Ton. Ursprünglich (vor langer, langer Zeit) wurden Soundfonts direkt in die Soundkarte geladen (Soundblaster iitc.) und man hat daher gerne/gezwungenermassen die Soundfonts möglicht klein gehalten, das ist aber kein "Muss". Ich habe durchaus sehr schön klingende, kleine Continuo-Orgel mit Fluidsynth und Soundfonts gebaut. Das bauen von Soundfonts mit dem Programm 'Polyphone' (ehemals 'Smurf') ist ein Kinderspiel.

    Dem Konzept von Mikelectric was ein Betriebssystem darstellt muss aber schon entschieden wiedersprechen. DOS hat eben (wie auch MacOS < OSX) kein wirkliches System bereitgestellt das sich zwischen Anwendungsprogramm und Hardware gestellt hat. Sowohl das BIOS als auch DOS haben lediglich aufrufbare/anspringbare Funktionen bereit gestellt um sich mit der Hardware (einigermassen bequem) zu unterhalt. Das konnte, musste man aber nicht nutzen. Selbst in (damals atemberaubend hohen Hochsprachen wie) BASIC konnte man mittels peek/poke direkt Maschinencode in die CPU pumpen. "Richtige" Betriebsssteme (Windows ab NT, Unices und Linux) erlauben das nicht mehr weil alle Adressen durch die MMU (Memory Management Unit) umgewandelt werden - Programme "sehen" nur einen virtuellen Adressraum. Direkter Speicherzugriff ist also nicht. Das ist Funktionalität die die CPU zur Verfügung stellt. Betriebsystem (Kernel) und Anwendungen laufen in unterschiedlichen "Ringen", nur der Betriebssystem-Ring hat Zugriff auf die Harware (Nur zur Info: der Wechsel zwischen den Ringen ist relativ "teuer", wenn Daten über diese Grenze müssen dann kostet das Performance. Das ist gerade im Audiobereich sehr wichtig und (hier kommen wir wieder zum Thema) einer der Gründe für Jack. Dort werden die Audiodatenblöcke eben nicht von Programm A and den Kernel gegeben, nur damit der sie dann an Programm B ausliefert (zwei Grenzübergänge) sondern die Daten werden über "shared memory" (not time to explain ;) relativ performant durchgereicht). Bei "richtigem" ASIO werden die Audiodaten an der/den Abstraktionsschichten des OS vorbei direkt an die Soundkarte geliefert.

    Im Grunde ist ASIO ja von der Funktion vergleichbar mit Jack unter Linux, ein Server der die Signale entsprechend schnell und effizient routen kann. Inwieweit das bei GrandOrgue jetzt einen Vorteil bringt sei mal dahingestellt. Den eigentlichen Vorteil würde ich nur sehen, wenn man Eingaben und Ausgaben in und aus verschiedenen Quellen in und aus GO verteilen will. Nur um einen Ton zu hören bringt es eigentlich keinen Mehrwert.

    Nein, ASIO ist überhaupt nicht mit Jack vergleichbar, es ist eher das Gegenteil davon. Jack ist eine Anwendung mit der unterschiedliche Programme möglichst performant Auido/MIDI-Daten austauschen können. Diese Daten können (müssen aber nicht!) auch an eine Soundkarte gesendet werden, das macht Jack aber immer über eine Betriebssystem-Zwischenschicht (unter Linux ist das heutzutage meistens ALSA als Schnittstelle zum Kernel).

    Bei ASIO geht's genau um das Gegenteil: Audiodaten werden *direkt* an die Soundkarte gesendet, unter Umgehung des Betriebssystems, um Latenzen zu minimieren.

    Was die Updatefähigkeit von Android betriff: die ist grausig schlecht, aber das entschuldigt ja nicht Apple. Ausserdem mache ich dann doch einen Unterschied zwischen einem Telefon und einem teuren Rechner. Ich habe hier bei uns in der Hochschule gerade das Problem dass unser gesammter Medienraum gerade nicht mehr auf Big Sur updaten kann. Ein kanppes Dutzend ganz vernünftig funktionierender iMacs die ich dann bald in den Ruhestand schicken muss X( (eig. sollte hier eher das K**ckehaufen-Emoji hin). Sowas ist alles andere als nachhaltig ...

    Moment, irgendetwas stimmt hier nicht. Ich habe hier Version 3.4.2-1 auf einem alten MacBookBook Pro (2012) mit Catalina am Laufen, ohne irgend welche Probleme. Ein MacBook aus dem Jahr 2009 ist jetzt 12 Jahre alt. Für Computer eine Ewigkeit. Zumindest High Sierra sollte aber auch auf einem solchen Gerät noch laufen. Freundlich gesagt: wer langen Hardware Support will darf keine Produkte von Apple kaufen.

    Zitat

    Original geschrieben von martin

    Ich habe eine Organ-Datei im Download gefunden.

    Ah, jetzt sehe ich das: die Orgeldatei selbst ist nicht im Ordner 'Data - Azzio' und wird vom Entpacker unter macOS nicht ausgepackt, es sei den man entpackt sie einzeln. Unter Linux ist sie da (N.B.: eigntlich sollte man in Archiven
    immer so packen dass alles in einen Ordnerentpackt).

    Leider bricht GO beim Laden unter Linux ab. Sieht ganz so aus als ob ein paar der Graphiken korrupt sind.
    Die libpng die unter Linux zum laden der Graphiken benutzt wird meldet einen CRC-Fehler (am Anfang
    jeder Bildzeile enthält eine PNG-Datei eine Prüfsumme, den sog. Cyclic Redundancy Check, und diese Prüfsumme scheint an manchen Stellen nicht mit den Daten übereinzustimmen. Unter macOS laden die sselben Dateien ...).
    Da die MD5 Checksumme des Downloads korrekt ist (und die Bilder ja im Archiv gepackt waren) nehme ich an dass die schon so zerschossen erstellt wurden (was allerdings ein veritabler Bug der Graphiksoftware wäre).