Synthesizer programmieren in Java

[Der Operator]

Bin mir jetzt nicht ganz sicher, ob das Thema nicht eher in den DIY Bereich gehört.
Würde gern mal wieder ein wenig zuhaus programmieren und da meine Java Kenntnisse deutlich frischer sind als meine C++ Kenntnisse, würde ich gern einen einfachen Softsynth in Java programmieren. Mach das Sinn in Java? Oder doch besser C++? Hat einer von Euch sowas schon mal gemacht? Kann mir jemand interessante Quellen im Netz nennen?

 

[elmex]

Nur was generelles zu Java:
Du willst ja vermutlich real-time Ausgabe des Sounds haben (also MIDI Keyboard spielen und hören), da würde ich behaupten, dass Java nicht unbedingt die beste Wahl ist.
Problematisch sehe ich da, dass der garbage collector ja jederzeit anlaufen kann, und wenn er das tut während du gerade deine samples für die nächste Ausgabe berechnest, dann bekommste Knackser und so. Da müsstest du ggf. gucken ob man den garbage collector auch einfach abschalten kann für die Zeit wo du Samples berechnest.

Auch weiß ich nicht, ob der Java overhead was Zugriff auf Felder und Objekte angeht, sowie Methoden aufrufe, nicht etwas zu hoch ist. Zwar sollten float-Berechnungen und mathematisches vermutlich vom Just-in-Time-Compiler beschleunigt werden, aber wenns ums Handling von Objekten und Methoden-Aufrufe geht, da kann der JIT nicht mehr viel machen.

Ich würde eher C++ nehmen, da hast du mehr Kontrolle darüber was wieviel CPU Zeit frisst. Aufpassen, dass die Rechenzeit reicht, musst du in jedem Jall, nur bei Java wirst du (definitiv) schneller an Grenzen stoßen. Zum herum experimentieren sollte Java evtl. sogar reichen, ich hab da keine Erfahrung mit was Synth-Programmierung angeht. Aber zum "number crunching", was ja ein Softsynth macht, ist Java eigentlich nicht direkt geeignet.

Diverse Berechnungen hin und wieder sind auch ganz hilfreich. z.B. wieviel Rechenzeit man pro Sample zur Verfügung hat usw. Wenn du z.B. mit 48kHz arbeitest, dann hast du 1 / 48000 Sekunden Zeit für ein Sample. Das sind 0.2083 Millisekunden, und 20.83 Mikrosekunden. Wenn du dann real-time fähige Puffergrößen nimmst, so im Bereich von 128-256 Samples,
dann hast du 2666 bis 5333 Mikrosekunden (also rund 2.6 bis 5.3 Millisekunden) Zeit diese zu berechnen. In der Zeit solltest du möglichst auch keine Systemaufrufe machen (also so Dinge wie Speicher reservieren oder freigeben, oder Ein/Ausgaben).

 

[Moogulator]

Java ist langsam und dafür Plattformübergreifend. Zu empfehlen ist es daher eher nicht. Es wird idR. bisher nur für einfache Klangerzeugung oder akademische Sachen und EDITOREN eingesetzt, da die Portierung da einfacher ist. Für komplexe Synthesesachen würde ich es aus Performancegründen nicht empfehlen.

 

[mnb]

also das rechnen koennte mit java noch gerade so effizient genung
klappen, haarig wirds dann das audio mit wenig latenz nach draussen zu
kriegen. meiner persoenlichen meinung nach muss man voellig
wahnsinnig sein sowas in java zu versuchen (macht deshalb auch
praktisch niemand).
also c.
einfach das vst-sdk installieren, und mit visualc kann man dann
gleich loslegen. wenn keine gui noetig ist, ist das auch wirklich nicht
sehr kompliziert, und ich denke jeder, der in irgendeiner sprache
programmieren kann, sollte damit klarkommen.
(nagut, jemand der bisher ausschliesslich lisp oder so programmiert
hat, muss ein 'wenig' umdenken... )

 

[changeling]

Java ist langsam und dafür Plattformübergreifend.

So pauschal ist das nicht richtig. Für Sachen mit GUI oder Realtime-Kram wie Soft-Synths aber definitiv nicht zu empfehlen. Bei Kommandozeilen-Kram und Server-Stuff sieht das schon anders aus (siehe JBoss, OpenDS und Co).
Für Soft-Synths ist C++ eigentlich die Sprache der Wahl. Gibt auch ein Framework für Audio/MIDI-Kram: http://www.rawmaterialsoftware.com/juce.php
Stammt ursprünglich aus dem Tracktion Projekt, was von Mackie aufgekauft wurde.

 

[Moogulator]

Wenn das so pauschal falsch ist, dann nenne mir doch mal eine Abweichung wo Java schnell ist und zB für einen Granularsynth die beste Wahl wäre? Weshalb schlägst du sonst C/C++ vor? Naja, soll mir recht sein. Ich würde jedenfalls genau deshalb nur unaufwendige Sachen mit Java bauen oder reine GUI Dinger und Editoren, Audiokram grade noch. Und zwar eben wegen der Performance und der Art was und wie Java funktioniert. Es kann und wird nie schneller sein, es sei denn man würde eine spezielle Engine bauen. Das scheint mir aber nicht mehr Ziel der Hersteller zu sein, war es auch nur teilweise mal.

 

[elmex]

Wenn das so pauschal falsch ist, dann nenne mir doch mal eine Abweichung wo Java schnell ist ...

Java hat einen recht flotten JIT, der besonders für mathematische Berechnungen gut Geschwindigkeit rausholen kann. Natürlich bleiben so Sachen wie Methodenaufrufe immer noch recht langsam.

Für viele Anwendungen ist aber CPU Zeit nicht unbedingt das wichtigste, da reicht die Geschwindigkeit von Java massig aus, um z.B. wie du beschrieben hast GUI/Editoren zu machen. Da würde aber evtl. die gesparte Entwicklungszeit dann "Java schnell machen"

Besonders Plattformübergreifend ist Java auch nicht unbedingt, es hat Jahre gedauert bis das Java VM Plugin für Firefox auf amd64 Linux verfügbar war. Andere Sprachen sind da teilweise viel portabler (beispielsweise Perl läuft auf mehr Hardwarearchitekturen als die Java VM). Aber das is eh OT.

Ich schließe mich an: Software Synthesizer auf jeden Fall in C oder C++, alles andere macht eigentlich keinen Sinn.

 

[changeling]

Wenn das so pauschal falsch ist, dann nenne mir doch mal eine Abweichung wo Java schnell ist und zB für einen Granularsynth die beste Wahl wäre?

1. Beitrag lesen
2. Beitrag verstehen
3. Auf Beitrag antworten

 

[Der Operator]

Danke für Eure schnellen Antworten - hab mir das mit der Latzenz aufgrund der Java Architektur schon "fast" gedacht. Also wieder in C/C++ reinhängen. Tut sich ja eh nicht viel bezüglich der Syntax.
Kann mir jemand ne "vernünftige" kostenlose Entwicklungsumgebung empfehlen? Hab bisher für Java Progr. in Netbeans gearbeitet.

 

[Der Operator]

Ach so - wenn möglich, würd ich gern auch ne GUI dafür programmieren. In Java hab ich dafür awt und swing benutzt. In C hab ich mit GUIs bisher keine Erfahrungen...

 

[Jens Groh]

Schau dir mal Gervill-Library (auch RasmusDSP genannt) an. Die haben die Implementation des Java Sound-API erheblich in Richtung Synthese ausgebaut. Kann man einzeln benutzen, ist aber auch schon in OpenJDK integriert. Die DAW Frinika basiert darauf.
Sicher lohnt es sich auch mit diesen Libraries trotzdem immer noch, bestimmte Sachen als hoch optimierten, nativen C-Code über JNI anzubinden, aber das müsstest du natürlich für jedes Betriebssystem einzeln bauen.

Kann mir jemand ne "vernünftige" kostenlose Entwicklungsumgebung empfehlen? Hab bisher für Java Progr. in Netbeans gearbeitet.

Eclipse natürlich!

 

[changeling]

Ach so - wenn möglich, würd ich gern auch ne GUI dafür programmieren.

Obiges Juce ist auch ein GUI-Framework.

 

[khz]

evt. http://faust.grame.fr/ ?

 

[Jens Groh]

Ach so - wenn möglich, würd ich gern auch ne GUI dafür programmieren. In Java hab ich dafür awt und swing benutzt. In C hab ich mit GUIs bisher keine Erfahrungen...

Dann machs doch einfach weiter in Java, und lagere nur das "Number Crunching" in ein in C geschriebenes Modul aus (s.o.).

Noch mal zu gratis Entwicklungsumgebungen, aber für C: (Ich hatte nur an Java gedacht, deswegen Eclipse genannt)
Microsoft Visual Studio Express (Windows).
Apple Xcode (MacOSX).
Es gibt sogar eine Eclipse-Erweiterung für C (alle Plattformen).

Übrigens, wenn du mal was besseres als Swing suchst, nimm SWT. Findest du ebenfalls beim Eclipse Project. Eclipse basiert selbst darauf, und man sieht daran: Pure Java kann sauschnell sein.

 

[haesslich]

ich würde auch juce empfehlen. ich benutze seit jahren kein anderes framework mehr. juce ist auch cross plattform und du kannst verschiedene plugin formate erzeugen.
die gui möglichkeiten sind völlig ausreichend. teilweise gibt kommerzielle software, die mit dem default look von juce ausgeliefert wird (z.b. der korg nanokontrol editor), und absolut okay aussieht.

das vorhin erwähnte faust ist ein cross compiler, der auch plugins exportiert. die idee ist zwar cool und es funktioniert, aber für einen ganzen synthesizer würde ich doch auf etwas anderes zurückgreifen.

 

[Der Operator]

Ganz vielen Dank für Eure Hinweise!
Hab mir heute mal nen paar C/C++ Bücher geholt und werd mich jetzt mal wieder reinfuchsen...