|
Anzeige
|
Juce Audio Framework
Gast
#5936019
Hat schon mal jemand mit Juce gearbeitet? Damit kann man Echtzeit-Audioverarbeitung wie z.B. Synthesizer oder schnelle graphische Anzeigen für Win, Linux, Android, IOS basteln. Ich hab's für Linux compiliert und es funktioniert so weit. Aber ich frage mich, was für Lizensen das Ganze unterliegt und ob es sich lohnt, da Zeit zu investieren.
Gast
#5936020
Link vergessen: https://juce.com/
Beitrag #5936048 wurde von einem Moderator gelöscht.
Gast
#5936919
Das scheint noch ein KlickiBunti Framework zu sein der am Ende mehr einschränkt als hilft... Für Low Latency Audio empfehle ich das Bela Projekt: https://bela.io
Gast
#5936950
CM schrieb: > Aber ich frage mich, was für Lizensen das Ganze unterliegt Das steht nicht beim Source Code/ Installer/ Website dabei? Dann solltest du es schnell wieder löschen, denn wenn dir die Lizenz nicht explizit die Kompilation und Ausführung erlaubt, hast du dadurch eine Urheberrechtsverletzung begangen. Denn nach dem Urheberrecht ist alles, was nicht explizit erlaubt ist, verboten!
Gast
#5937143
Zum Thema Lizenz: Wenn Du es heruntergeladen hast, warst Du ja auf der "get JUCE" Seite und da sind unten mehrere Links, u.a. https://juce.com/juce-5-license
Gast
#5937324
BobbyX schrieb: > Das scheint noch ein KlickiBunti Framework zu sein der am Ende > mehr > einschränkt als hilft... > > Für Low Latency Audio empfehle ich das Bela Projekt: > > https://bela.io Das lässt sich doch gar nicht vergleichen. Mit Juce kann man schnell und einfach crossplattform Software erstellen (Win/Mac/Linux/Android/iOS) und eben auch Audio Plugins. Wirklich echtzeitfähig ist das natürlich nur bedingt. Einschränkung gibt es in so fern, dass im Falle von Audioplugins nicht alle Features von allen Schnittstellen (VST/AudioUnits/...) zur Verfügung stehen. Dafür kann man den Code schnell portieren. Ansonsten ist es normales C++ und man kann problemlos auch noch z.B. boost einbinden. Man ist ja nicht gezwungen, ausschliesslich juce zu verwenden. Z.B. für IO (UART/Sockets) benutze ich lieber boost-asio. Den Projucer benutze ich nur, um ein Projekt zu erstellen/verwalten, selten mal um eine GUI zu gestalten. Programmieren tu ich immer in Visual Studio. Was ich an Juce gar nicht mag, ist dass man fast überall mit rohen Pointern hantieren muss. Ich hab mir schon einige Male überlegt, ein Fork zu machen und das ganze auf Smartpointer umzuschreiben. Wie das mit der Lizenz für so ein Fork aussehen würde, weiss ich allerdings nicht, darum habe ich das noch nicht in Angriff genommen. Zombie schrieb: > Was ich an Juce gar nicht mag, ist dass man fast überall mit rohen > Pointern hantieren muss. die Kritik teile ich jetzt nicht. Wenn kein ownership transfer stattfindet, ist es absolut korrekt einen Raw-Pointer zu akzeptieren, wozu würde man da mit smart pointern rumfrickeln? Das sagen auch die R32 - R37 der C++ core guidelines so. Der allergrößte Teil des Juce-Api hat kein ownership transfer, also nimmst Du einfach den smart pointer in deinem Code, um die Ressource zu managen und übergibst an die Funktionen den Raw Pointer und fertig. Das ist doch absolut korrekt so. Ok, du benutzt den Projucer nicht um das GUI zu designen, korrekt? Da kommen dann schon ein paar Raw-Pointer mit ownership transfer vor, aber das ist auch sehr explizit und klar und auf ein einziges Standard-Pattern beschränkt. Finde ich jetzt auch keinen Beinbruch. vlg Timm
Gast
#5941118
Was mich ein wenig an Juce irritiert, ist dieses Modul https://github.com/WeAreROLI/JUCE/tree/master/modules/juce_cryptography von dem ich glaube, dass es immer eingebunden wird und Daten irgendwo hin überträgt. Antwort schreiben |
Anzeige
|
