U-He unter Linux (Tyrell)

[stevie777]

Für Dich vielleicht, ich habe Abelton nach 3-4 Stunden Gebastel sein lassen.

Nun, wenn ich mich ernsthaft für eine Software interessiere, überfliege ich in den 3-4 Stunden "Gebastel" gerade mal das Handbuch. Es ist halt kein Standard-Sequenzer, sondern hat eine eigene Architektur. Ob man das mag steht auf einem anderen Blatt. Ein Computer- und Ton-technisch wirklich sehr versierter Freund bekam bei ersten Versuchen mit der Linux Audio-Architektur auch nach 30-40 Stunden "Gebastel" keinen einen gescheiten Ton aus seinem Rechner

[zettberlin]

Ein Computer- und Ton-technisch wirklich sehr versierter Freund bekam bei ersten Versuchen mit der Linux Audio-Architektur auch nach 30-40 Stunden "Gebastel" keinen einen gescheiten Ton aus seinem Rechner

Das ging mir genauso. Nachdem ich 3 Jahre lang täglich stundenlang mit Cubase, Samplitude und Co gearbeitet hatte, bin ich unter Linux wochenlang gerade mal mit Audacity klar gekommen.

Das war allerdings 2002.

[ungleichklang]

Dann sollen wir es alle "The Linux Way" tuen.
Thema: Selbstzweck

Ich lese mich bspw. gerade in C++, FLTK und DSSI ein um ein DSSI basierend auf minicomputer http://minicomputer.sourceforge.net/
irgendwann erstellen zu können (allerdings polyphon und monotimbral).
Wenn der Tyrell nativ unter Linux rauskommt, hole ich mir den trotzdem.

Q: Was ist daran jetzt der Selbstzweck??
A:
1) ich lerne endlich mal noch ne weitere Programmiersprache
2) ich habe einen DSSI Synth für mein Renoise
3) ich kann tiefer in die Synthlogik von Oscilatoren, Filtern, ADSR und so einsteigen, was ich immer schon wollte aber leider immer verpasst habe

Q: Was bringt das der Welt??
A: Was interessiert mich das? Halt ein weiteres OpenSource Projekt ....

[Drumfix]

Wenn du schon das entwickeln für Linux anfängst dann bitte richtig:

- nimm Qt statt FLTK wenn es C++ sein soll
- nimm GTK+ statt FLTK wenn es C sein soll
- nimm LV2 statt DSSI, wenn es den Hardcore Opensource Freaks gefallen soll
- nimm VST statt DSSI, wenn du es dir einfach (= vernünftige Doku) machen willst

[ungleichklang]

Wenn du schon das entwickeln für Linux anfängst dann bitte richtig:

- nimm Qt statt FLTK wenn es C++ sein soll
- nimm GTK+ statt FLTK wenn es C sein soll
- nimm LV2 statt DSSI, wenn es den Hardcore Opensource Freaks gefallen soll
- nimm VST statt DSSI, wenn du es dir einfach (= vernünftige Doku) machen willst

1) es soll C++ sein weil mir als Java/Python/Ruby Mensch das Ding mit den Pointern nicht in den Schädel gehen will.
Header Dateien finde ich ja schon unnütz.
2) FLTK ist leichter als GTK+ oder Qt, also weniger CPU-Last, also mehr Instanzen des DSSI
Ausserdem läuft gerade ne Disskusion auf der LAD-ML bezüglich ZynAdd/Yoshimi und FLTK vs. GTK+ und es sind sich alle einig, das FLTK zwar nicht toll aussieht aber halt eben viel leichter und schneller ist und daher eigentlich eher was für Soundapps ist die irgendwie live eingesetzt werden sollen.
3) mein Renoise will noch kein LV2 sondern nimmt DSSI oder VST und ich will niemandem gefallen "Selbstzweck"
4) ähmmm fällt mir nix zu ein ... ausser VST == Steinberg == böse keine Ahnung wenn es erstmal irgenwie läuft kann man es ja noch umschreiben

[zettberlin]

3) mein Renoise will noch kein LV2 sondern nimmt DSSI oder VST und ich will niemandem gefallen "Selbstzweck"

Dummerweise hat DSSI aber keine Zukunft. Mit LV2 kann man prinzipiell alles machen, de facto mehr als mit VST.

Die CALF-Leute entwickeln ihre Synths allerdings parallel als DSSI und LV2-Versionen - scheint nicht sooo kompliziert zu sein...

[sonicwarrior]

2) FLTK ist leichter als GTK+ oder Qt, also weniger CPU-Last, also mehr Instanzen des DSSI
Ausserdem läuft gerade ne Disskusion auf der LAD-ML bezüglich ZynAdd/Yoshimi und FLTK vs. GTK+ und es sind sich alle einig, das FLTK zwar nicht toll aussieht aber halt eben viel leichter und schneller ist und daher eigentlich eher was für Soundapps ist die irgendwie live eingesetzt werden sollen.

Dann wäre es doch mal interessant das Plugin einmal mit FLTK und einmal mit QT zu programmieren.

Es gibt auch noch andere Frameworks, z.B. Juce (http://www.rawmaterialsoftware.com/juce.php).

[metasymbol]

Für Dich vielleicht, ich habe Abelton nach 3-4 Stunden Gebastel sein lassen.

Nun, wenn ich mich ernsthaft für eine Software interessiere, überfliege ich in den 3-4 Stunden "Gebastel" gerade mal das Handbuch.

Ja, 3-4 Stunden reichen einfach nicht. Ich arbeite mit Live inzwischen ernsthaft 2 Jahre, kenne es schon 5 und lerne dauern was neues dazu. Schon allein jeder einzelne Synth (Operator, Analog etc) reicht schon um ein halbes Leben mit Klangschraubereien zu verbringen. Ich arbeite jeden Tag zum Teil 10 Stunden mit diesen Programm und bin noch weit davon entfernt mich "Experte" zu nennen. Allerdings erspart eine Stunde "Nachhilfeunterricht" bei mir (oder einen anderen erfahrenen Live Anwender) dem geneigten Anwender viele Stunden des Lesens und rumprobierens. Ist erstmal ein gewisser Punkt erreicht, findet man leicht Zugang und kann auch komplexe Aufgaben lösen. Hardware wie das "Launchpad" erleichtern den Workflow ungemein.

Warum ist Ableton Live so erfolgreich? Bestimmt nicht weil selbsternannte Free Software Guerillas mal 3-4 Stunden schlechtgelaunt mit der Prämisse "Das ist böse" drin rumgeklickt haben.

Es wäre toll, wenn das Live Konzept von freien Softwareautoren geklaut wird um es nachzubauen. Man könnte auf der Engine von Seq24 aufbauen...

[zettberlin]

Ich arbeite jeden Tag zum Teil 10 Stunden mit diesen Programm und bin noch weit davon entfernt mich "Experte" zu nennen.

Das ist beeindruckend!
Bedenket, oh ihr Nichtswürdigen, dass der Meister in den 14 übrigen Stunden des Tages auch noch ein enzyklopädisches Wissen über Linux-Audio Software zu erwerben vermag.

[brummer]

Wenn du schon das entwickeln für Linux anfängst dann bitte richtig:

- nimm Qt statt FLTK wenn es C++ sein soll
- nimm GTK+ statt FLTK wenn es C sein soll
- nimm LV2 statt DSSI, wenn es den Hardcore Opensource Freaks gefallen soll
- nimm VST statt DSSI, wenn du es dir einfach (= vernünftige Doku) machen willst

gtkmm ist für C++ auch eine sehr gute alternative, lässt sich sehr schon strukturieren, und wird dadurch unheimlich schnell und leicht

Fltk ist zwar noch leichter, aber das sieht man dem Interface auch an . . .

[metasymbol]

Ich arbeite jeden Tag zum Teil 10 Stunden mit diesen Programm und bin noch weit davon entfernt mich "Experte" zu nennen.

Das ist beeindruckend!
Bedenket, oh ihr Nichtswürdigen, dass der Meister in den 14 übrigen Stunden des Tages auch noch ein enzyklopädisches Wissen über Linux-Audio Software zu erwerben vermag.

Ja danke für die Blumen, bei Linux Audio Programmen, die ich seit 2005 zum Teil systematisch teste, reicht LEIDER manchmal "gesehen, gelacht, gelöscht" - da fehlt mir die Ehrfurcht vor der Schöpfungshöhe, wenn sich die Anwendung nicht erschließt. Ansonsten besitze ich eine Art MetaVerstehen für die Anwendung von produktiv-kreativen Anwendungen, das macht mich flexibel das ich zwischen Plattformen und Anwendungen hin und herspringnen kann.

Ich nehme mir für mein Linuxhobby zumindest regelmäßig Zeit und schaue gerne mal über meinen Sandkasten hinaus. Mal so aus Spaß erleben wie der Rechner freezt, man Probleme lösen muss... All das vermisse ich auf dieser langweiligen, ewig gleich gut funktionierenden Mac Plattform. Ehrlich.

Kann verstehen das ihr Nichtwürdigen vor meinen großen Verstehen in Ehrfurcht erstarrt und mich "Meister" nennt. Siehe, ich bin der Meister des digitalen Zeitalters, alles was ihr Nichtwürdigen erlebt sind nur meine gedanklichen Spiele.

[ungleichklang]

gtkmm ist für C++ auch eine sehr gute alternative, lässt sich sehr schon strukturieren, und wird dadurch unheimlich schnell und leicht

Fltk ist zwar noch leichter, aber das sieht man dem Interface auch an . . .

Werde ich mir angucken .... die GTKMM UI ist schon Klasse

Bei FLTK kann man aber über den GUI_Designer FLUID Dials oder Slider auch mit Images versehen, das tut nur keiner der Entwickler weil alle auf das knochige stehen. Ehenso kann man das ganze Widget mit nem BG Image versehen und ebenso Modular arbeiten.,
also bspw. ein UI-file für den ADSR, wobei der dann im Hauptfenster 4 mal eingebunden wird, etc. oder so.
generiert werden dann die entsprechenden C++ und Header Dateien udn das meist relativ easy und unkompliziert, ohne XML parsen durch --->> irgendwas

Ich werds sehen, muss mich ja in die ganze Logik noch einarbeiten und im Moment habe ich eher bei C oder C++ noch das Problem, das ich zwar sehe was da steht aber an den wichtigen Stellen nichtmehr durchblicke und daher bspw. die engine vom minicomputer nicht verstehe .
Auch blicke ich noch nciht ganz durch was nen Synth überhaupt polyphon macht und wie ich das in DSSI einbaue, etc...

[brummer]

Werde ich mir angucken .... die GTKMM UI ist schon Klasse

Richtig schön werden die Gui's mit Gtkmm + Cairo http://cairographics.org/documentation/

Einen Engine code zu verstehen, denn man nicht selber geschrieben hat, ist nicht so leicht wie es zunächst scheint, das geht nur Stück für stück, ja, da muß sich erstmal einarbeiten.

[ungleichklang]

Werde ich mir angucken .... die GTKMM UI ist schon Klasse

Richtig schön werden die Gui's mit Gtkmm + Cairo http://cairographics.org/documentation/

Einen Engine code zu verstehen, denn man nicht selber geschrieben hat, ist nicht so leicht wie es zunächst scheint, das geht nur Stück für stück, ja, da muß sich erstmal einarbeiten.

Hatte mich sogar noch vertippt, ich wollte eigentlich schreiben das die Guitarix GUI Klasse ist, Respekt.
UIs werde ich noch was verstärkt studieren, habe langsam das Gefühl, das gerade da ein Bedarf bei den Audiodefs ist.

Da die meisten AudioUser ja zumindest QJackCtl benutzen und daher diese UI-libs im Hintergrund ja dann schon laufen (und weil es einfacher sein soll), werde ich mir diese erstmal anschauen .... dann irgendwann Gtk und Cairo.
*Hui, wieder was im a4l-IRC gelernt*

[nowhiskey]

ick verstehe mich gar nicht im coden, aber wie ich gehört habe (aus sicherer quelle) ist etwa 1/4 die engine und der rest das gui.
hört sich böse an, soll aber so in etwa sein.

gruss,
doc