umstieg auf ubuntu ... selbsttötung oder erleuchtung
- Ersteller lilak
- Erstellt am
mink99
|
lilak schrieb:
Das geht so aus der Grafik hervor ....
Aber bevor wir hier in einer Diskussion über ein Detail das eigentliche Problem aus dem Auge verlieren. Sorry jetzt kommt Informatik , betriebssystemkonzepte ....
Ich halte das Konzept einer integrierten daw für das immer noch erfolgversprechendste für digitale Studios.
Wie müsste es denn sein, was sind die Anforderungen ?
1.) systemweite (Betriebssystem-) Dienste
Eine daw greift über standardisierte systemschnittstellen (API s) auf die Hardware Treiber zu. Diese systemschnittstellen beinhalten ebenfalls den Übergang vom usermode in den kernelmode, bei dem auf die Hardware zugegriffen wird. Hier bieten die kernelmode Komponenten der systembibliotheken ebenfalls eine standardisierte API an, die von den hardwaretreibern bedient wird.
Für Daws haben diese APIs zwei ausprägungen, midi und Audio . Systemseitig stehen ebenfalls infrastrukturdienste wie Timer und Notifikationen sowie peripheriedienste wie USB oder firewireservices zur Verfügung.
Das war's, mehr braucht es nicht, was systemseitig zur Verfügung gestellt werden muss. Dafür würde ein alsa oder oss reichen.
(3:1 für Borussia !)
2.) applikationsnahe Dienste , die nur auf Anforderung zur Verfügung stehen
2.1)
Hier braucht es eine Plugin Schnittstelle , die bestimmte audio und midi Komponenten dynamisch laden kann und über die eine daw bestimmte teile der Audio oder midiverarbeitung delegieren kann. Diese Komponenten werden im applikationskontext der daw ausgeführt . Das ladspa system könnte dies analog der Vst oder Au Schnittstelle erledigen.
2.2)
Eine kommunikationsschnittstelle , in der unabhängige Applikationen untereinander audio und midi Daten hin und herstreamen können . Dabei bleibt allerdings eine Anwendung Master, die die systemzugriffe implementiert und darüber auch das latenzmanagement durchführt. Nach dem rückstandsfreien entsorgen von 80% des Codes kann jack den Rest übernehmen .
.......
Bei der bestehenden audioarchitektur sind etliche Basics aus der Informatik ignoriert worden, u.a. Kiss, pfeif nicht wenn du pisst , Separation of concerns und so weiter, dafür aber etliche antipatterns umgesetzt worden. Das meiste kann weg.
(4:1 ...)
Zurück zur eigentlichen frage. Es besteht keine Notwendigkeit, dass Programme Daten so massiv pipen. Und natürlich kostet jeder datentransfer zwischen Applikationen massiv zeit . Wir sind hier im Bereich interprozesskommunikation , und da ist jeder Aufruf teuer. Und wenn die datenweitergabe noch per Push erfolgt, also vom Sender aktiv initiiert wird, dann Rauschen die Millisekunden nur so durch die CPU.
A
Anonymous
Guest
in der folterkammer sitzt?khz schrieb:
khz schrieb:
mink99
|
Zur Grafik
Ich sehe in der Grafik eine Zahl in rot, 2,6 Millisekunden genau unter einem mit jack bezeichneten Kästchen ...
Jack ist die personifizierte Verletzung des Kiss Prinzips .
Wofür ist jack denn da ? Ist es jetzt die systemschnittstelle zur Hardware , ein Interapplikations Audio und midi Streaming system, ist es der zentrale audio midi Hub als Master oder was ? Bereits das Konzept eines systemweiten audioservers ist notleidend. Die daw ist sinnvollerweise Master und muss es sogar sein. Deshalb ist die direkte Kommunikation daw <> alsa der bessere weg.
Gerade die unklaren Verantwortlichkeiten zwischen alsa und jack verletzen das Separation of concerns Prinzip.
Wenn jack sich ausschliesslich um die Interapplikations kommunikation kümmern würde, wären 80 % obsolet.
Die freie verschaltbarkeit setzt natürlich einen zentralen audio/midiserver voraus. Ob das jetzt nur deshalb so gemacht wurde, und die Applikationen deshalb nur teilfunktionalitäten implementieren, oder ob der Server implementiert wurde, weil es halt nur teilfunktionalitäten gab, weiss ich nicht.
Ob ein pluginkonzept als komponentenmodell weniger leistungsfähig ist als das pipen zwischen Applikationen sehe ich nicht.
Das ewige Argument, ein fehlerhaftes Plugin .... lasse ich nicht gelten. Wenn ein Plugin abraucht, benutzt Mans halt beim nächsten mal nicht mehr, es gibt ja genug .....
Wegen ipc , schau dir da nicht die jack API, sondern generell die ipc Dokumentation für Linux und auch die Intel Dokumente dazu an. Stichwort kontextwechsel.
Ich sehe in der Grafik eine Zahl in rot, 2,6 Millisekunden genau unter einem mit jack bezeichneten Kästchen ...
Jack ist die personifizierte Verletzung des Kiss Prinzips .
Wofür ist jack denn da ? Ist es jetzt die systemschnittstelle zur Hardware , ein Interapplikations Audio und midi Streaming system, ist es der zentrale audio midi Hub als Master oder was ? Bereits das Konzept eines systemweiten audioservers ist notleidend. Die daw ist sinnvollerweise Master und muss es sogar sein. Deshalb ist die direkte Kommunikation daw <> alsa der bessere weg.
Gerade die unklaren Verantwortlichkeiten zwischen alsa und jack verletzen das Separation of concerns Prinzip.
Wenn jack sich ausschliesslich um die Interapplikations kommunikation kümmern würde, wären 80 % obsolet.
Die freie verschaltbarkeit setzt natürlich einen zentralen audio/midiserver voraus. Ob das jetzt nur deshalb so gemacht wurde, und die Applikationen deshalb nur teilfunktionalitäten implementieren, oder ob der Server implementiert wurde, weil es halt nur teilfunktionalitäten gab, weiss ich nicht.
Ob ein pluginkonzept als komponentenmodell weniger leistungsfähig ist als das pipen zwischen Applikationen sehe ich nicht.
Das ewige Argument, ein fehlerhaftes Plugin .... lasse ich nicht gelten. Wenn ein Plugin abraucht, benutzt Mans halt beim nächsten mal nicht mehr, es gibt ja genug .....
Wegen ipc , schau dir da nicht die jack API, sondern generell die ipc Dokumentation für Linux und auch die Intel Dokumente dazu an. Stichwort kontextwechsel.
mink99
|
dbra schrieb:Noch eine kleine Ergänzung:
Welchen Vorteil soll es haben, wenn eine Anwendung einen Master bildet? Das behindert nur ein flexibeles Konzept. Man merkt wohl, das du bei IBM arbeitest...mink99 schrieb:
Ex IBM bitte ...
Es geht darum, kann ein systemweiter Server (jack) die Qualität bieten, die eine dedizierte Applikation bietet. Ich sehe eher jack als eine IBM like One size fits it all Lösung .
mink99
|
Bezüglich direktes aufsetzen auf der Hardware :
Hatte ich glaub ich erläutert . Das war das mit den systemschnittstellen ... Es geht nicht um das direkte aufsetzen auf der Hardware, sondern den Übergang von einer High Level API für midi und einer für Audio (userspace) in die systemaufrufe (kernelspace) . Also eine aufgebohrte alsa-lib .
Bezüglich audioserver und Applikationen als Client vs eine Applikation/daw als audioserver . Das Szenario was du beschreibst, ist nur eines von mehreren möglichen. Ich denke, dass der Studio "Pro Tools" Workflow eher durch einen externen audioserver behindert wird. Und auch das "ich jamme mit ableton" hat andere Anforderungen . Diese unterschiedlichen einsatzszenarien in einem audioserver zu ermöglichen , erscheint mir zu overengineered oder enterprisey. Deshalb mein Vorschlag des anderen komponentenschnitts, alsa für io und jack im reinen usermode optional ausschliesslich für die Kommunikation . Das sorgt dafür, dass die Funktionalität , die du brauchst, nur dann zur Verfügung steht, wenn sie auch gebraucht wird und die anderen Szenarien nicht behindert werden.
Zum Thema Komponenten / Plugins
Wiederverwendung von kleinen Funktionalitäten ist durchaus sinnvoll. Und eine komponentenschnittstelle absturzsicher zu gestalten, ist heute kein Problem mehr.
Für bestimmte Szenarien ist linux heute bereits gut einsetzbar, da bin ich nicht mehr so schwarz weiss wie eingangs noch, für andere sind meiner Meinung nach noch grosse Schritte notwendig. Ob aber die Developer diese anderen Szenarien auch sehen, und bereit sind, de dafür nötigen Umbauten vorzunehmen, werden wir sehen.
Hier wird Bitwig als erste komplett daw , die nach den auf den anderen Plattformen üblichen Konzepten konzipiert ist, hoffentlich ein Umdenken erzeugen.
Hatte ich glaub ich erläutert . Das war das mit den systemschnittstellen ... Es geht nicht um das direkte aufsetzen auf der Hardware, sondern den Übergang von einer High Level API für midi und einer für Audio (userspace) in die systemaufrufe (kernelspace) . Also eine aufgebohrte alsa-lib .
Bezüglich audioserver und Applikationen als Client vs eine Applikation/daw als audioserver . Das Szenario was du beschreibst, ist nur eines von mehreren möglichen. Ich denke, dass der Studio "Pro Tools" Workflow eher durch einen externen audioserver behindert wird. Und auch das "ich jamme mit ableton" hat andere Anforderungen . Diese unterschiedlichen einsatzszenarien in einem audioserver zu ermöglichen , erscheint mir zu overengineered oder enterprisey. Deshalb mein Vorschlag des anderen komponentenschnitts, alsa für io und jack im reinen usermode optional ausschliesslich für die Kommunikation . Das sorgt dafür, dass die Funktionalität , die du brauchst, nur dann zur Verfügung steht, wenn sie auch gebraucht wird und die anderen Szenarien nicht behindert werden.
Zum Thema Komponenten / Plugins
Wiederverwendung von kleinen Funktionalitäten ist durchaus sinnvoll. Und eine komponentenschnittstelle absturzsicher zu gestalten, ist heute kein Problem mehr.
Für bestimmte Szenarien ist linux heute bereits gut einsetzbar, da bin ich nicht mehr so schwarz weiss wie eingangs noch, für andere sind meiner Meinung nach noch grosse Schritte notwendig. Ob aber die Developer diese anderen Szenarien auch sehen, und bereit sind, de dafür nötigen Umbauten vorzunehmen, werden wir sehen.
Hier wird Bitwig als erste komplett daw , die nach den auf den anderen Plattformen üblichen Konzepten konzipiert ist, hoffentlich ein Umdenken erzeugen.
A
Anonymous
Guest
auch du scheiße,
was ne zusammengehackte bastelstube
versteh ich das richtig?
es gibt keinen basic i/o im kernel
und basic services gibts auch nicht
nur alles nur als so zusammengewürfelter kram? brrr
jack kenn ich, was aber macht pulse audio?
was ne zusammengehackte bastelstube
versteh ich das richtig?
es gibt keinen basic i/o im kernel
und basic services gibts auch nicht
nur alles nur als so zusammengewürfelter kram? brrr
jack kenn ich, was aber macht pulse audio?
A
Anonymous
Guest
liebelein, eine frage endet mit einem Fragezeichen, ne 
aber lieber rumkotzen als aufklären, so gewinnt man die herzen der user
aber lieber rumkotzen als aufklären, so gewinnt man die herzen der user
khz
||||||||||
Sobald eine ~Anwendung die Soundkarte belegt/nutzt steht sie anderen Anwendungem nicht mehr zur Verfügung.
(Z.B.: SC => ALSA => Phasex (SW-Synth).
Um nun mehrere Programme mit einer SC nutzen zu können gibt es jackd.
(Z.B.: SC => ALSA => qjackct(jachk) => Phasex & ams & qmidiarp & mx44 & seq24 & rakarrack & ardour & Bitwig & Renoise & wtf ... (Alles frei routbar (art modular)))
Kann man unter Mac/Win z.B. Nuendo audio/midi zu Cubase dann weiter zu (omg kenne ich Programme?) irgendwas quer routen und in RT wieder umpatchen?
ALSA also Kommunikation zwischen HW SC und einer SW Anwendung, jack(d) ist eine ~Patchbay.
Dadurch hat man einen flexiben digitalen modularen ~Synthesizer.
Man kann ja auch raus an externe HW routen und dann wieder zurück in ein Programm oder dank jacktrip über Internet zum Kumpel Rechner oder mit Netjack im lokalen Netzwerk oder ... .
Sry wegen den vielen Bildern, aber ich finde das für mich einfacher als 1k Worte. (Und t-kom freut sich! )
(Z.B.: SC => ALSA => Phasex (SW-Synth).
Um nun mehrere Programme mit einer SC nutzen zu können gibt es jackd.
(Z.B.: SC => ALSA => qjackct(jachk) => Phasex & ams & qmidiarp & mx44 & seq24 & rakarrack & ardour & Bitwig & Renoise & wtf ... (Alles frei routbar (art modular)))
Kann man unter Mac/Win z.B. Nuendo audio/midi zu Cubase dann weiter zu (omg kenne ich Programme?) irgendwas quer routen und in RT wieder umpatchen?
ALSA also Kommunikation zwischen HW SC und einer SW Anwendung, jack(d) ist eine ~Patchbay.
Dadurch hat man einen flexiben digitalen modularen ~Synthesizer.
Man kann ja auch raus an externe HW routen und dann wieder zurück in ein Programm oder dank jacktrip über Internet zum Kumpel Rechner oder mit Netjack im lokalen Netzwerk oder ... .
Sry wegen den vielen Bildern, aber ich finde das für mich einfacher als 1k Worte. (Und t-kom freut sich!
)
mink99
|
Hier in dem Beispiel sieht man sehr schön die unterschiedlichen Sichtweisen.
Aus einer bottom up Perspektive (Hardware ) ist jack ne Patchbay .
Aus einer Top Down Perspektive (daw) ist jack als zentraler audio/midiserver weitaus mehr.
Bei einer konsequenten Umsetzung des audioserver Konzepts gibt es keine zentrale DAW und keine Plugins, sondern alle am musizieren beteiligten Bausteine agieren als eigenständige Applikationen unter der Kontrolle des Servers . Dies bedeutet, dass diese Komponenten anders agieren als das das daw / pluginkonzept der anderen Betriebssysteme erwarten lässt.
Beispiel
Eine einfache Session mit 4 Tracks soll gebounced werden, Ergebnis sind 4 samplegenau positionierbare audiotracks.
Track 1 ist ein softsynth , gemäss dem Linux Konzept eine eigenständige Applikation
Track 2 ist ein weiterer softsynth , gemäss dem Linux Konzept eine eigenständige Applikation
Track 3 ist eine Audiospur , die von eine sampleplayer abgespielt wird
Track 4 ist eine externe drumbox via midi, (nicht Clock, sondern Noten)
Wir haben also folgende Applikationen gestartet
Einen midiplayer mit den mididaten von Track 1,2,4
Einen audioplayer mit den Audiodatei von Track 3
Einen audiorecorder , auf dem der mixdown schlussendlich landet
Softsynth 1
Softsynth 2
Und natürlich jack
Zum samplegenauen aufzeichnen braucht es jetzt beim drücken des recordbuttons folgende Schritte
Miditrack 1 muss um soviele Ticks vorgezogen werden, wie die verarbeitunglatenz von softsynth 1 beträgt
Miditrack 2 muss um soviele Ticks vorgezogen werden, wie die verarbeitunglatenz von softsynth 2 beträgt
Audiotrack 3 muss tickgenau gestartet werden
Miditrack 4 muss um soviele Ticks vorgezogen werden, wie die midi Outbound Latenz des midi Interfaces + die inboundlatenz des audiointerfaces beträgt
Die audiostreams als Ausgabe der softsynths zu verzögern , und dafür das midi clockgenau zu starten, kostet gesamtlatenz, die beim live einspielen von softsynths nicht akzeptabel ist.
Was bedeutet das für den audioserver ?
Er muss die verarbeitungslatenzen aller geladenen Applikationen kennen, und die Latenzen aller Peripheriegeräte. Er muss in der Lage sein, beim midiplayer z.b. Einzelne Tracks tickgenau unabhängig zu starten. Dies gilt auch fur audioplayer und recorder.
Dies gibt gibt einen immensen verwaltungsoverhead, denn der Server greift hierfür ja nicht auf eine einzelne , virher bekannte Applikation , sondern auf eine klasse von Applikationen zu. Nicht ein spezieller midiplayer muss fernsteuerbar sein, sondern alle. Eine systemweite latenzkompensation , die bei konsequenter Umsetzung des Linux Konzepts Voraussetzung ist, wäre mir zu enterprisey und zu riskant, das vollumfänglich ans laufen zu bringen, zumal einige der integrierten Schnittstellen ein konsequentes Layering vermissen lassen (was hat eine FireWire Schnittstelle in einer High Level API zu suchen ?)
Selbst Ardour hat dieses Konzept verlassen, und integriert inzwischen die midi Funktionalitäten selber, und verlässt sich nicht mehr auf die Kombination jack / externer midiplayer.
Kommen wir zum Layer 8 , dem Anwender . Der normale Musiker denkt nicht in Applikationen, sondern in Songs. Die ganzen in o.g. Beispiel erzeugten Daten, die audiofiles, die midifiles, das routing etc möchte er oder sie als einen Song zusammen speichern und Laden , total recall halt. Wo wäre es aus anwendersicht logisch das zu tun ?
Ich denke, da ist eine daw, die das wissen über die Umgebung hat, gerade aus Sicht latenzkompensation und total recall deutlich effizienter als ein systemweiter audioserver. Wenn man jetzt noch die Dinge mit einrechnet, die im Studiobetrieb sonst noch so anfallen können, wie DSPs, automatisierbare Peripherie , integrierte Hardware , so ist das Konzept eines zentralen audioservers das zweitbeste (von zweien)
Aus einer bottom up Perspektive (Hardware ) ist jack ne Patchbay .
Aus einer Top Down Perspektive (daw) ist jack als zentraler audio/midiserver weitaus mehr.
Bei einer konsequenten Umsetzung des audioserver Konzepts gibt es keine zentrale DAW und keine Plugins, sondern alle am musizieren beteiligten Bausteine agieren als eigenständige Applikationen unter der Kontrolle des Servers . Dies bedeutet, dass diese Komponenten anders agieren als das das daw / pluginkonzept der anderen Betriebssysteme erwarten lässt.
Beispiel
Eine einfache Session mit 4 Tracks soll gebounced werden, Ergebnis sind 4 samplegenau positionierbare audiotracks.
Track 1 ist ein softsynth , gemäss dem Linux Konzept eine eigenständige Applikation
Track 2 ist ein weiterer softsynth , gemäss dem Linux Konzept eine eigenständige Applikation
Track 3 ist eine Audiospur , die von eine sampleplayer abgespielt wird
Track 4 ist eine externe drumbox via midi, (nicht Clock, sondern Noten)
Wir haben also folgende Applikationen gestartet
Einen midiplayer mit den mididaten von Track 1,2,4
Einen audioplayer mit den Audiodatei von Track 3
Einen audiorecorder , auf dem der mixdown schlussendlich landet
Softsynth 1
Softsynth 2
Und natürlich jack
Zum samplegenauen aufzeichnen braucht es jetzt beim drücken des recordbuttons folgende Schritte
Miditrack 1 muss um soviele Ticks vorgezogen werden, wie die verarbeitunglatenz von softsynth 1 beträgt
Miditrack 2 muss um soviele Ticks vorgezogen werden, wie die verarbeitunglatenz von softsynth 2 beträgt
Audiotrack 3 muss tickgenau gestartet werden
Miditrack 4 muss um soviele Ticks vorgezogen werden, wie die midi Outbound Latenz des midi Interfaces + die inboundlatenz des audiointerfaces beträgt
Die audiostreams als Ausgabe der softsynths zu verzögern , und dafür das midi clockgenau zu starten, kostet gesamtlatenz, die beim live einspielen von softsynths nicht akzeptabel ist.
Was bedeutet das für den audioserver ?
Er muss die verarbeitungslatenzen aller geladenen Applikationen kennen, und die Latenzen aller Peripheriegeräte. Er muss in der Lage sein, beim midiplayer z.b. Einzelne Tracks tickgenau unabhängig zu starten. Dies gilt auch fur audioplayer und recorder.
Dies gibt gibt einen immensen verwaltungsoverhead, denn der Server greift hierfür ja nicht auf eine einzelne , virher bekannte Applikation , sondern auf eine klasse von Applikationen zu. Nicht ein spezieller midiplayer muss fernsteuerbar sein, sondern alle. Eine systemweite latenzkompensation , die bei konsequenter Umsetzung des Linux Konzepts Voraussetzung ist, wäre mir zu enterprisey und zu riskant, das vollumfänglich ans laufen zu bringen, zumal einige der integrierten Schnittstellen ein konsequentes Layering vermissen lassen (was hat eine FireWire Schnittstelle in einer High Level API zu suchen ?)
Selbst Ardour hat dieses Konzept verlassen, und integriert inzwischen die midi Funktionalitäten selber, und verlässt sich nicht mehr auf die Kombination jack / externer midiplayer.
Kommen wir zum Layer 8 , dem Anwender . Der normale Musiker denkt nicht in Applikationen, sondern in Songs. Die ganzen in o.g. Beispiel erzeugten Daten, die audiofiles, die midifiles, das routing etc möchte er oder sie als einen Song zusammen speichern und Laden , total recall halt. Wo wäre es aus anwendersicht logisch das zu tun ?
Ich denke, da ist eine daw, die das wissen über die Umgebung hat, gerade aus Sicht latenzkompensation und total recall deutlich effizienter als ein systemweiter audioserver. Wenn man jetzt noch die Dinge mit einrechnet, die im Studiobetrieb sonst noch so anfallen können, wie DSPs, automatisierbare Peripherie , integrierte Hardware , so ist das Konzept eines zentralen audioservers das zweitbeste (von zweien)
mink99
|
Sorry, stell es dir vor, ändert nichts an der Aussage der Grafik ....
Supervisor ist als Ausdruck gefährlich, da das bei virtualsierun eine andere Bedeutung hat ....
Das Konzept ist, dass die io Funktionalitäten aus jack extrahiert werden und in das was im Bild alsa heisst, verschoben werden. Das Ergebnis kann dann meinetwegen auch jack heissen, oder Norbert oder wie auch immer.
Der Rest, der ipc Teil , der im usermode läuft , verbleibt.
Der firewirekram wird entsorgt, der programmierer muss zur Strafe ein IBM websphere Redbook lesen.
Pulse audio wird ebenso entsorgt und auf Treiber bzw Kernel ebene abgehandelt.
Ach so, wie kann jack für die basisfunktionalitat leistungsfähiger sein als alsa, wo es doch nur eine Shell um alsa ist ?
Supervisor ist als Ausdruck gefährlich, da das bei virtualsierun eine andere Bedeutung hat ....
Das Konzept ist, dass die io Funktionalitäten aus jack extrahiert werden und in das was im Bild alsa heisst, verschoben werden. Das Ergebnis kann dann meinetwegen auch jack heissen, oder Norbert oder wie auch immer.
Der Rest, der ipc Teil , der im usermode läuft , verbleibt.
Der firewirekram wird entsorgt, der programmierer muss zur Strafe ein IBM websphere Redbook lesen.
Pulse audio wird ebenso entsorgt und auf Treiber bzw Kernel ebene abgehandelt.
Ach so, wie kann jack für die basisfunktionalitat leistungsfähiger sein als alsa, wo es doch nur eine Shell um alsa ist ?
mink99
|
dbra schrieb:Sieh's endlich ein, du hast verloren!
Sagt dir der Ausdruck Pyrrhussieg etwas ?
Du hast gewonnen, nur du hast immer noch keine treiberunterstützung unter Linux, und auch ein ableton, kein reaper, kein Massive usw. Vielleicht irgendwann mal Bitwig .
Ist doch Quatsch .....
Dass das vorgeschlagene Konzept funktioniert, zeigen die nischenbetriebssysteme wie osx und Windows , die im Bereich Professional audio gegenüber Linux natürlich nicht wirklich relevante Marktanteile haben ....
Und natürlich, bis protools als der studiostandard von Linux auf w indows und Mac portiert wird, da werden noch Jahre ins Land gehen......
Wieso beisst du dich an der Uniformen datenweitergabe so fest ? Habe ich irgendwo behauptet, dass die ipc und das physische io über unterschiedliche APIs gehen müssen, auch wenn die implementation eine andere ist ? Die datenformate , die sinnvollerweise identisch sein sollten, haben wir garnicht diskutiert.
Wie eine uniforme API für midi aussehen könnte, zeigt z.b rtmidi. Das konnte ich mir vorstellen, dass so die alsa API für midizugriffe aussehen könnte ... http://www.music.mcgill.ca/~gary/rtmidi/
Und da gibt es keinen Grund, warum ipc nicht die gleiche API anbieten könnte.
...... Das war's also nicht ......
Zum Thema Linux ausprobieren . Ardour, was einer daw so wie ich es kenne, am Nächsten kommt, bietet leider noch nicht die Features , die ich für meinen Workflow und mein Setup benötige. Ich verfolge das allerdings ständig und werde, sobald dort die entsprechenden Features zur Verfügung stehen, dem auf jedenfall eine Chance geben. Und sei sicher, ich werde deine angebotene Hilfe gerne wahrnehmen
Niedrige Latenzen sind kein Selbstzweck , sondern man muss auch Material erzeugen können, was dann Latenzen verursacht.
khz
||||||||||
Echt? Also hier (Gentoo && Debian) kann man Ardour zwar starten ohne das jackd läuft, Ardour startet aber automatisch dann jackd. Paul Davis hat ja extra jackd programmiert um das ~modulare zu realisieren.mink99 schrieb:
Sonst hätten wir so Kisten wo man nichts ~modulares ~patchen könnte.
Bei Linux gibt es nicht - wie evt. bei einigen anderen Systemen - eine Endlösung. Es ist eher eine ewige Schlacht/Streit Kultur die im ständigen Prozess ist.
Wohin was geht formen wir teilweise aktiv mit. Also Programmierer und Anwender verschmelzen im Idealfall oder stehen im direkten Kontakt zueinander.
Keine Nachfrage/Angebot Moneyback ding.
Und es ist langsam, da nicht jede bekiffte Idee grade auf ein "Juhu" und "Klar das wirds, kommt in Kernel!", ... ist sondern sehr lange besprochen und programmiert wird.
Nur sinnvoller (was auch immer das ist) Code setzt sich durch bzw wird genutzt.
Und: es gibt Alternativen: Wer das nicht gut findet kann/soll Windows oder noch besser Mac nehmen.
Keiner sagt "pls komm zu uns, verschwende deine Zeit" sondern eher "don´t waste my time".
Es prallen halt sehr viele Individualisten aufeinander die evt. nicht New Age / Friede, Freude, Eierkuchen anhänger sind sondern eher ~Extremisten.
A
Anonymous
Guest
new age? friede, freude, eierkuchen?
wohl eher charles manson als Teufel aus der kiste (jack in the box)
lets face it - linux und audio ist wie zurück in die steinzeit
im userland kann linux da nix reissen
für anspruchsvolle Nutzer - no fucking way
zu was soll das denn eine alternative sein?
die alternative die einem von der freiheit beraubt irgendeine wahl an vernünftiger software zu haben?
linux ist und bleibt ein backbone ding, da hat sich auch in den letzten 10 jahren nix daran geändert
wohl eher charles manson als Teufel aus der kiste (jack in the box)
lets face it - linux und audio ist wie zurück in die steinzeit
im userland kann linux da nix reissen
für anspruchsvolle Nutzer - no fucking way
zu was soll das denn eine alternative sein?
die alternative die einem von der freiheit beraubt irgendeine wahl an vernünftiger software zu haben?
linux ist und bleibt ein backbone ding, da hat sich auch in den letzten 10 jahren nix daran geändert
mink99
|
khz schrieb:
Nur weil ein demon gestartet wird, heisst das nicht , dass die Features auch genutzt werden. Ich bezog mich darauf, dass Ardour jetzt auch midi unterstützt und nicht gemäss dem Konzept midi Verarbeitung an ein zweites Programm delegiert....
khz schrieb:
Ihr linuxer vielleicht nicht, unter Windows und osx geht das schon lange , max , Reaktor oder so .....
khz schrieb:
Werbung...
Und ich will nicht mit jemandem verschmelzen, der sich so einen crap ausdenkt.....
khz schrieb:
Ich bedaure eher die verpasste Chance, dass Linux die Pro Audio Plattform hätte werden können, wenn nicht so viele Leute mit Paul Davis hätten verschmelzen wollen .
Und ich denke, dass es Sinn macht, an Linux hier die gleichen qualitatsmasstäbe anzusetzen wie an andere Systeme . Mir geht es nicht um ein kuschelgefühl zwischen einem Programmierer und mir(*), sondern um eine Umgebung, Musik zu machen.
(*) die Frauenquote unter Linux programmiern ist, so hört man, noch schlechter als unter Synthesizer Musikern. Aber zensursula hat ja versprochen, dass ab 2020 die Frauenquoten angepasst werden.
mink99
|
dbra schrieb:
Das hast du mir erklärt, dass das das Konzept ist. Wenn ich dann die Auswirkungen der konsequenten Umsetzung diese Konzepts analysiere, dann ist es nicht mehr das Konzept. Was soll das ?
dbra schrieb:
Ich habe glaube ich ein paar gute Argumente gebracht , warum jack konzeptionell notleidend ist. Wenn natürlich die Konzepte alle nur unverbindlich sind , ist klar, das eine Diskussion hier auseinanderläuft.
Und dass ich auf die wir haben uns alle lieb Argumente allergisch reagiere, sollte schon offensichtlich sein. Betriebsblindheit macht einsam, und ob es jetzt ein Kollege hier ist oder Helga tut nichts zur Sache.
IT ist nicht Moral, sondern Handwerk .
A
Anonymous
Guest
ja mit jack n bissl gitarrenschule st.anna aufnehmen geht, und dann nix mehr
lol, da geht ja auf iOS mehr
lol, da geht ja auf iOS mehr
A
Anonymous
Guest
klar polarisier ich,
im ernst, da geht auf iOS wirklich mehr
och nö, lass' ma, ich mag keine fremden männer in meinem bett
aber stell dir mal vor Richard Stallman sitzt an deinem Küchentisch und erzählt dir was von software freiheit, beta 0,3 und gpl
wie lange erträgt man das?
im ernst, da geht auf iOS wirklich mehr
och nö, lass' ma, ich mag keine fremden männer in meinem bett
aber stell dir mal vor Richard Stallman sitzt an deinem Küchentisch und erzählt dir was von software freiheit, beta 0,3 und gpl
wie lange erträgt man das?
khz
||||||||||
Will damit sagen das es u.U. sehr lange dauern kann bis sich was durchsetzt.
Es gibt relativ wenig Audio Entwickler die im Idealfall auch ein RL haben und evt. nicht bezahlt werden bzw. wenn evt. anders als bei einem Konzern.
Es sehr viele Meinungen gibt die über Forum, IRC, ... besprochen/diskutiert werden (/auch sehr ~hitzig teilweise).
Es momentan ca. drei Plattformen gibt (meines Wissens). Jedrer darf frei wählen, jedem das seine, was er mag bzw. was er gut findet, was für ein selbst gut funkt und ... .
Reaktor kann sein Audio frei an ein anderes Programm (z.B. Ableton) weiter geben und MIDI woanders hin (z.B. Nuendo)? Dann ja fein.
MAX ist PD ähnlich, Reaktor ams?
Ja wir (user) haben uns MIDI bei Ardour gewünscht. Die SW Synths sind aber denoch (teilweise) eigene (nicht wie VSTI die über jackd geroutet/patcht werden. Ardour braucht jackd!
Es ist vieles nicht perfekt und in den ~23 Jahren GNU/Linux ist was gewachsen, gestorben, versickert und geboren ...
Audio ist Randerscheinung nur mal so nebenbei ... .
Es eröffnen sich einige Möglichkeiten - kA wohin Linux geht bzg. Audio.
Es ist evt. - bei mir jedenfalls so - auch noch so ~Gegenkultur.
Wer Lust hat soll es testen und evt. sich über die Vorteile erfreuen. Hat aber auch Nachteile.
Das Ying/Yang ding bzw das druff und affe schieben Prinzip.
Es gibt relativ wenig Audio Entwickler die im Idealfall auch ein RL haben und evt. nicht bezahlt werden bzw. wenn evt. anders als bei einem Konzern.
Es sehr viele Meinungen gibt die über Forum, IRC, ... besprochen/diskutiert werden (/auch sehr ~hitzig teilweise).
Es momentan ca. drei Plattformen gibt (meines Wissens). Jedrer darf frei wählen, jedem das seine, was er mag bzw. was er gut findet, was für ein selbst gut funkt und ... .
Reaktor kann sein Audio frei an ein anderes Programm (z.B. Ableton) weiter geben und MIDI woanders hin (z.B. Nuendo)? Dann ja fein.
MAX ist PD ähnlich, Reaktor ams?
Ja wir (user) haben uns MIDI bei Ardour gewünscht. Die SW Synths sind aber denoch (teilweise) eigene (nicht wie VSTI die über jackd geroutet/patcht werden. Ardour braucht jackd!
Es ist vieles nicht perfekt und in den ~23 Jahren GNU/Linux ist was gewachsen, gestorben, versickert und geboren ...
Audio ist Randerscheinung nur mal so nebenbei ... .
Es eröffnen sich einige Möglichkeiten - kA wohin Linux geht bzg. Audio.
Es ist evt. - bei mir jedenfalls so - auch noch so ~Gegenkultur.
Wer Lust hat soll es testen und evt. sich über die Vorteile erfreuen. Hat aber auch Nachteile.
Das Ying/Yang ding bzw das druff und affe schieben Prinzip.
mink99
|
Sorry bin pissed
Da hat man endlich mal die Diskussion auf ein sachliches Niveau gebracht, ist dabei softwarearchitekturen in ihren Vorteilen und Nachteilen zu bewerten , unterschiedliche Konzepte miteinander zu vergleichen in ihren anwendungsszenarien und was kommt als Abschluss der Diskussion?
irgendwelcher emo kram über gute Gefühle
Irgendwelches kuschelnmüssen mit einem guten Programmierer und schlechtem Designer.
Und dann das totschlagargument du musst ja nicht, nimm doch Windows
IT Architekturen zu analysieren ist seit Jahren Teil meines Jobs . Da geht es nicht um Emotionen , sondern um Konzepte, Anwendbarkeit etc. Handwerkliche Qualität , messbar .
So wie ich drauf bin, müsste Richard stallmann erst mal bei mir den Geschirrspüler ausräumen. .....
Da hat man endlich mal die Diskussion auf ein sachliches Niveau gebracht, ist dabei softwarearchitekturen in ihren Vorteilen und Nachteilen zu bewerten , unterschiedliche Konzepte miteinander zu vergleichen in ihren anwendungsszenarien und was kommt als Abschluss der Diskussion?
irgendwelcher emo kram über gute Gefühle
Irgendwelches kuschelnmüssen mit einem guten Programmierer und schlechtem Designer.
Und dann das totschlagargument du musst ja nicht, nimm doch Windows
IT Architekturen zu analysieren ist seit Jahren Teil meines Jobs . Da geht es nicht um Emotionen , sondern um Konzepte, Anwendbarkeit etc. Handwerkliche Qualität , messbar .
So wie ich drauf bin, müsste Richard stallmann erst mal bei mir den Geschirrspüler ausräumen. .....
A
Anonymous
Guest
^^
News
-
Beetlecrab Tempera Granular Synthesizer Talk (English) at SequencerTalk Developer Talk #207- Gestartet von Moogulator
- Antworten: 1
-
Elektron Digitakt II - alles doppelt! 8 Takte, Viel Speicher, Kits etc.
- Gestartet von Moogulator
- Antworten: 3
-
KI stellt Depeche Mode nach - nach Umstellung wird das zu einer generischen Clone-Band-Kopie
- Gestartet von Moogulator
- Antworten: 0
-
-
-
-
19.4. Köln, Rewohlte, Roland Schappert mit Bob Humid & Hendrik Meyer
- Gestartet von Moogulator
- Antworten: 9