erfahrungen mit pure data?

[toxonic]

hat einer von euch schon erfahrungen mit pure data gesammelt? ich habe darüber gelesen und muss sagen, das hat sich recht interessant angehört... und freeware ist es ja auch noch! und man kann die fertigen patches in vst's umwandeln! könnte mir zwar vorstellen, daß man da schnell den überblick über die modul-landschaft verliert (objekte heissen die glaub ich in pd), wenn jeder mit programmiererfahrung solcher erstellen und veröffentlichen kann.... aber im allgemeinen hört sich das doch nach einer vielversprechenden, offenen programmstruktur an!?

[KlangRaum]

meinst du http://www.puredata.org/ ?

das kenn ich noch nicht genauer. ich hab mich in der letzten zeit mal mit einigen *dingern* auseinandergesetzt, aber noch nix für meine speziellen zwecke gefunden

ich werd mich mal da einlesen, danke für den tip

edit:
thema midi aufm mac:

....MIDI. Requires Mark Williamson's MJLib external (currently no OSX support).

schonmal sehr schlecht

[toxonic]

genau das meine ich, es gibt da auch pure data extended, ist ne version mit einer menge zusätzlicher libraries und dokumentationen!
und midi funzt net auf mac? kann ich ja fast net glauben.... geht auf linux platformen auch ohne weiters! strange.....

[herw]

meinst du http://www.puredata.org/ ?

...

das tue ich mir nicht mehr an! Wenn ich mir überlege, ich müsste mich um jedes Detail mit Hilfe dieser unanschaulichen halb graphischen Befehle kümmern, würde ich wohl nie etwas zustande bringen.
Allein das erste Beispiel für einen Oszillator schreckt ab:

Zitat von: Pd-Dokumentation 2.1.2.

Da finde ich dies besser:

Midi-Oszillator.gif

[nq]

ist doch halb so wild – das pd-beispiel von dir herw. im grunde ist das gar nicht so viel anders als reaktor
noten-eingang
was stripnote macht weiß ich nicht mehr
midi to frequency
oszillator
output mal 0.1 wegen der laustärke
audio out

mal ehrlich. so schlecht ist pure data nicht. es funktioniert aber alles etwas anders als in reaktor und sieht BEI WEITEM nicht so schön aus.

man kann aber schon sehr gut darin arbeiten. und das handbuch dazu ist auch gar nicht mal so Mist

[herw]

ist doch halb so wild – das pd-beispiel von dir herw. im grunde ist das gar nicht so viel anders als reaktor
noten-eingang
was stripnote macht weiß ich nicht mehr
midi to frequency
oszillator
output mal 0.1 wegen der laustärke
audio out

mal ehrlich. so schlecht ist pure data nicht. es funktioniert aber alles etwas anders als in reaktor und sieht BEI WEITEM nicht so schön aus.

man kann aber schon sehr gut darin arbeiten. und das handbuch dazu ist auch gar nicht mal so Mist

ja die Funktionsweise ist mir schon klar, aber mal ehrlich, sähe REAKTOR-Programmierung so aus, würden alle protestieren, schau alleine mal auf die unbezeichneten Parametereingänge, abgesehen davon, dass man sie kaum sieht. Warum sollte ich einen Rückschritt machen.
Was ist also der große Vorteil von Pd gegenüber REAKTOR; und sagt jetzt nicht, dass das nur die VST-Abspeichermöglichkeit ist.

[toxonic]

erstens: es ist freeware, da erwarte ich nicht ne schicke gui wie bei reaktor und zweitens: die unbeschrifteten parametereingänge haben mich anfangs auch irritiert, wenn man aber auf so ein "modul" doppelklickt, geht in einem neuen fenster automatisch eine doku zu entsprechendem "modul" auf, die i.d.r. recht verständlich gehalten ist.
das man die patches als vst's abspeichern kann, find ich schon ganz gut. ich finde grundsätzlich die offene programmstruktur (weil open source) gut. damit meine ich, daß man - prinzipiell - in der lage ist, sich seine eigenen extensions zu programmieren, - natürlich vorausgesetzt man kann in c (glaube ich) programmieren.... ich kann's net, aber da kann man ja ohne weiteres auf das know-how (sprich: auf extensions) anderer zurückgreifen!
wie gesagt, bin da noch nicht wirklich eingestiegen, aber ich find's interessant - es gibt unmengen an zusätzlichen extensions. das hat zwar eben auch den nachteil, daß man schnell die übersicht verlieren kann, aber ich könnte mir vorstellen, das dadurch schon das ein oder andere problemchen elegant gelöst wurde, das in reaktor noch gelöst werden muss!?
max/msp hört man ja auch ständig, wenn's um modulare lösungen geht, pd scheint ja da artverwandt zu sein, oder?

[nq]

a die Funktionsweise ist mir schon klar, aber mal ehrlich, sähe REAKTOR-Programmierung so aus, würden alle protestieren, schau alleine mal auf die unbezeichneten Parametereingänge, abgesehen davon, dass man sie kaum sieht. Warum sollte ich einen Rückschritt machen.
Was ist also der große Vorteil von Pd gegenüber REAKTOR; und sagt jetzt nicht, dass das nur die VST-Abspeichermöglichkeit ist.

Sexy ist was anderes.
Ich weiß jetzt nicht, ob es bei pd auch so ist, zumindest in max/msp ist es so, dass wenn man mit der Maus über einen Port fährt, unten in der Bildlaufleiste die Bezeichnung des Ports steht.
Und der Umstand, dass man zu jedem Modul eine Hilfeseite aufrufen kann, in der das Modul in verschiedenen lauffähigen Anwendungsbeispielen vorgestellt wird, ist schon ganz komfortabel.

pd ist sicherlich nicht jedermanns Sache. Und auch auf keinen Fall schon so ausgereift. Aber man kann nee unglaublich Menge damit machen.

Und ja toxonic. max/msp und pd sind verwandt. der Entwickler von pd ist auch der, der damals max/msp mitentwickelt hat.
http://crca.ucsd.edu/~msp/techniques.htm
der link ist das buch, das er inm zusammenhang mit pd geschreiben hat und ein unglaublicher Schatz in Sachen DSP und Musik ist.

für alle, die eine andere kostenlose Audiosprache suchen und denen pd nicht passt
http://chuck.cs.princeton.edu/
für mac, windows und linux

[magneton]

(...)
der link ist das buch, das er inm zusammenhang mit pd geschreiben hat und ein unglaublicher Schatz in Sachen DSP und Musik ist.

das möchte ich hier nochmals ausdrücklich bestätigen. über 300 seiten, wird regelmäßig erweitert. auch für andere DSP software interessant.

[helmsklamm]

für alle, die eine andere kostenlose Audiosprache suchen und denen pd nicht passt
http://chuck.cs.princeton.edu/
für mac, windows und linux

ehrlich gesagt, weiß ich hier nicht mehr, wo der sinn liegen sollte. die lernkurve für chuck dürfte vielleicht ETWAS leichter sein, als für ne "richtige"sprache, aber dafür hast du dort den voreteil das das schlussendlich nich in ner VM abgewickelt wird sondern direkt nach binärcode compiliert wird, was nen signifikanten performance-sprung bedeutet. ausserdem kannst du dann tatsächlich ALLES machen. nun gut, vielleicht sind die bibliotheken besonders zielgruppengenau zugeschnitten, aber wenn du dich woanders umschaust, findest du sicher das gleiche auch für C oder D. also bevor ich 2jahre chuck lerne, häng ich lieber noch eines ran und lerne gleich was gescheites;) nene, wenn das sowieso in ner virtullen maschine bleibt kann man auch gleich bei reaktor bleiben.

bei ner richtigen sprache hast du auch den vorteil das sich jede menge leutz damit beschäftigen, als bei dergleichen insellösungen. slebts wenn sie noch extrem jung ist, gibts bereits nativ sprechende kompetente foren - was wiederum den vorteil hat, das du da mehr geholfen wirst und somit sogar schneller zu nem ergebniss kommst.
http://softchecker.net/upload/

[nq]

der vorteil lieber helmsklamm liegt darin, dass man in einer programmiersprache wie chuck oder auch supercollider auch live programmieren kann, ohne sachen nochmal groß neu kompilieren zu müssen.

[helmsklamm]

jup, da is in der tat was dran - ABER, warum kann man dann später, wenn test bestanden, das gesamtteil nich nochmal "offline" nach machinencode "compilieren" und sich so endproduktig die VM sparen?

die echtzeitumgebung core oder lego-reaktor oder eben chuck is zwar ne totale erleichterung, aber warum hier halt machen? so, ich bin mit dem teil zufriden, die VM hat ihren dienst geleistet, also jetz ans eingemachte und dem teil richtig beine gemacht?

ich glaube das sollte der ansatz bei dergleichen lösungen sein - die verbindung aus komfortablen echtzeit try/error "compilaten" und ne schlussendliche wirkliche endproduktsübersetzung nach machinensprech.

das würde ein hochperformtes endergebniss , ohne den umweg völlig abstrakt-sprachen-lernens und ständigen offline versuchs-compilierens bringen. so sollte der nächste schritt userfreundlicher programmierumgebungen aussehen.

[herw]

...für alle, die eine andere kostenlose Audiosprache suchen und denen pd nicht passt
http://chuck.cs.princeton.edu/
für mac, windows und linux

die Beispiele schrecken mich eher ab; ich will nicht das Rad nochmals erfinden.
Ich bin froh, dass mir NI diese Arbeit abnimmt.

[nq]

ich hab ja auch nie behauptet, dass es nicht arg komfortabel ist, dass es so eine software wie reaktor gibt.
aber ich kann mir auch anwendungsgebiete vorstellen, in denen solche programme sinn machen oder einfach nur eine schöne zusätzliche sache sind.