MAX 8 (Cycling 74)

[Klinke]

die audio engine bleibt trotzdem fix.
interne samplingraten (als triviales bsp.) bleiben fix.
summieralgorithmen bleiben fix.

"Die" audio engine gibt es auf Core-Ebene genauso wenig wie in C. Core ist im Prinzip nichts anderes als eine Domain Specific Language, nur das man graphisch arbeitet und nicht mit Text. Dahinter steckt dann aber genauso ein Compiler, der das ganze in Maschinencode umsetzt. Und der sieht nunmal am Ende genauso aus wenn ich in Core das Plus-Modul benutze oder in C "+" hinschreibe.

Was die interne samplingrate angeht, so ist in Reaktor ein garnicht so triviales Beispiel, da es hier tatsaechlich moeglich ist, eine andere interne Samplingrate zu benutzen als extern vom Host oder von der Soundkarte vorgegeben. Falls das tatsaechlich benutzt wird, gibt es dann eine Konvertierung, auf die man keinen Einfluss hat, und die hat dann tatsaechlich dann sowie wie eine Reaktoreigene Faerbung. Ich denke aber, im Normalfall wird man auf die Konvertierung verzichten, und vor allem kann man auf die Konvertierung verzichten. Rein theoretisch kann man dann sogar in der Core-Ebene trotzem mit Oversampling arbeiten und sich sein eigenen Konverter dort zurechtbasteln, das waere aber zugegebnermassen sehr aufwendig.

sonst musst du wirklich mit C, assembler oder was auch immer musik machen. nicht mit reaktor, PD etc.
dann hast du wirklich fast alles selber unter kontrolle.

Schau dir nochmal Core an und am besten vielleicht mal das Core-Tutorial von Vadim, und dann sollte Dir vielleicht klarwerden, dass Du in Reaktor genausoviel unter Kontrolle hast, wie in C. Nur wenn du am Ende wissen willst, wie der Compiler eigentlich Dein Programm/Core Modul uebersetzt hat, bist Du bei C auf der besseren Seite, das geht halt mit Reaktor nicht.

 

[Fidgit]

hmmm, ja, wie auch immer, ich kann nicht alle deine statements kompetent beurteilen.
vielleicht sprechen wir auch leicht aneinander vorbei.

ich mache klänge lieber mit sachen, die in meinen ohren gut klingen, als merkwürdig (im negativen sinne) klingende systeme von grund auf neu zu programmieren versuchen - bloss weil es irgendwie geht.

in meinem ersten beitrag habe ich festgestellt, dass die features wesentlich intensiver besprochen werden als die qualität des resultats. und dieses phänomen dann auch ansatzweise auf andere bereiche der heutigen gesellschaft projiziert.

 

[haesslich]

in meinem ersten beitrag habe ich festgestellt, dass die features wesentlich intensiver besprochen werden als die qualität des resultats. und dieses phänomen dann auch ansatzweise auf andere bereiche der heutigen gesellschaft projiziert.

was klinkenstecker dir sagen wollte ist, dass die qualität des resultates bei core-programmierung in reaktor eben davon abhängt, was du programmierst. nicht mehr und nicht weniger.

 

[mnb]

achso, hauptsächlich will ich stepsequencerartige module basteln und kleinere sounderzeuger für drumsachen und klickerklacker zeugs

also ich kenn ja nur reaktor (core nur aus der beta), und puredata.

bei reaktor ist es unendlich einfacher gut klingende synthesizer
(fx, sampler,...) zu bauen, als bei den millerschen programmen.
pd (und wohl auch max) haben aber einige vorteile wenns
um den bau flexibler sequenzer geht, (ist natuerlich trotzdem
eher anspruchsvoll (oder umstaendlich)) weil eben alles offener
ist.

davon abgesehen kann man sowohl mit core, als auch mit pd
dsp-algorithmen von grund auf selbst entwickeln.
(falls du das wirklich willst)

core fand ich in dieser hinsicht damals so schlecht (unnoetig
umstaendlich, eingeschraenkt), dass ich auf c++ umgestiegen bin.
mit etwas anstrengung kann man aber auch mit core alles machen,
was man so will. naja, vielleicht nicht ganz alles, oder kriegt
man inzwischen tables von/nach core? waere ja nett.

pd (und sicher auch max) setzt einem da nicht so deutliche
grenzen, hat aber seine tuecken und eigenheiten.

fuer max geld ausgeben wuerde ich aber nicht, ist ja blos pd mit
zuckerguss.

also in kurzen worten: wenn du schnell zum ziel kommen willst,
und keine allzu extremen sequenzerkonzepte im kopf hast,
nimm reaktor. sonst pd.

bis denn!
martin

 

[Moogulator]

Monome und Max - cooles Tutorial
https://www.sequencer.de/blog/?p=5788

 

[b166er]

Jo hossa,

ich nerv ja grad ein bisi mit meinen Sequencerfragen deswegen gibt´s gleich noch eine

Kann man einen Hardwaresequenzer mit Max/MSP erstellen ? In dem Sinne, dass man, wenn das Patch erstmal fertig ist, die Bedienung komplett ohne PC macht, also so ala NordModular : Aufbau mit Monitor+Maus, spielen ohne ?

Mir schweb da sowas vor wie :

1 Reihe mit 16 Tastern, beleuchtet
2-4 Reihen mit 16 Potis, endlos mit Kranz
Ein paar Taster für sonstige Funktionen, start, stop, taktweise blättern, patternwechsel etc.

Die Werte gehen an den Host, auf dem Max läuft, man kann durch mehrere Takte steppen, dabei wird dann das jeweilige Werteset von MAX an die Hardware ausgegeben und man ist im Bilde ?`

Oder ist das dann eher Overkill für MAX und klappt mit dem Timing nicht mehr ?

Kann man einen Sequenzer in MAX realisieren ?

Das Programmieren macht mir weniger Angst, muss halt sein, wenn ich nicht kaufen kann was ich haben will und schneller als das auf uC Basis zu entwickeln isses wohl auf jeden Fall. Die Frage ist nur, ob das prinzipiell überhaupt klappen KANN.

 

[Max]

Das sollte schon gehen mit Max/Msp, ich bin allerdings kein grosser Freund davon... manche schwoeren ja drauf, ich bin aber nie warm geworden damit.

Wenn du programmieren kannst, wuerde ich dir - nicht erschrecken - C# empfehlen. Die Programmierung ist wesentlich entspannter als direkt auf der Hardware (C/C++ etc.) und trotzdem passts mit dem Timing.

Eine gute MIDI-Library fuer .NET ist die von Leslie Sanford: http://www.lesliesanford.com/Programmin ... lkit.shtml

 

[b166er]

Danke für den Tip, aber von Programmieren _können_ bin ich noch entfernt, hab halt mal irgendwann C und C++ und Krams gemacht, aber das ist alles schon wieder vergessen ^^. Ich könnte mir vorstellen, dass MAX mich da schneller zum Ergebnis bringt, aber ich kuck mir das mal an - hab grad die Demo runtergeladen und 30 Tage ist ja mal ein Wort.

Sollte es mit MAX nichts werden, wär wohl eher hardwarenah meine Vorstellung - wenn ich scohn "richtig" coden muss, dann lieber gleich auf einem uC. Dummerweise gibts bei MIDIbox keine Quelltexte IIRC, also das wäre dann insgesamt schon ein sehr steiniger Weg, denn wenn ich schon so einen Riesenaufwand betreiben mag, dann soll´s danach auch genau so funktionieren, wie ich´s mir vorstelle. Deswegen wär mir quelloffen schon wichtig und ich glaub da hat auch die MAX Community einiges zu bieten.

Ich kuck mich mal um, könnte mir aber auch vorstellen, z.B. die Rosegarden Quellen mal zu sichten, evtl. kann man das verwenden und was embedded bauen.

Andererseits bastel ich auch an LED-Steuerungen rum, nur: einen Sequenzer in Assembler ? Das wird dann 2011

 

[pyrolator]

Das ist mit Max möglich und überfordert die Engine keineswegs. Ich schreibe seit vielen Jahren an einem Sequenzer mit Max und er ist jetzt schon in seiner Version 4.1
Er spielt auf 8 Midi-Kanälen timingsicher 8-stimmig polyphon und verrichtet dabei noch viele andere Aufgaben, wie Tables zur Skalenkorrektur, Prohabilität, Randomisierung ect ect.
Allerdings war das zugegebenermassen ein ziemlich steiniger Weg und ich musste meine Engine dreimal grundsätzlich umschreiben, da Max einige Eigenarten hat, an die man sich gewöhnen muss: Die Objekte werden von rechts nach links abgearbeitet (wichtig für das timing!), bestimmte Objekte sind prozessorfressender , als andere, usw.
Als Hardware benutze ich das Monome, hat zwar keine Drehregler, aber die kann ich immer noch einbinden, wenn ich will......
Hier ein Bespiel eines Live eingespielten Stücks:



src: https://vimeo.com/4208817

 

[mnb]

klar sollte das mit max gehen (warum nicht mit pd?), aber ich finde es auch etwas
overkill sich dafuer einen dicken rechner und dann auch noch mit einer entsprechenden
runtime hinzustellen. direkt auf nem microcontroler waer das imho schon eleganter.
naja, ich wollt schon immer mal einen pd-sequencer-patch fuer meine nanokontrol bauen,
der wuerde sicher sowas aehnliches wie das geforderte koennen, bis auf die
lampen (und die encoder). mal gucken ob ich dazu mal komme...

bis denn!
martin

 

[b166er]

Monomo ? Das klingt ja hochinteressant, hab die Videos gesehen und find das Teil ganz schnuckelig, seh es aber weniger als Modulationssequenzer, sonder eher zum Komponieren und Arrangieren. Hab trotzdem ein Auge drauf geworfen und ne Menge Fragen dazu.

Aber erstmal zu Max :

Was ich mir vorstelle, ist ein Generator für MIDI CC, der es möglich macht, mehrere CCs gleichzeitig zu sehen und direkt zu verändern. So eine Art MAQ/3 auf Streoiden, wobei die Hardware variabel sein sollte, damit man erstmal mit einer vorhandenen Controllerbox arbeiten kann und sich mehr um das MAX Programm kümmern kann. Eigene Hardware, also sowas in der Art von 16 Steps mit Digitalpotis und Anzeige wäre dann v2. Ganz wichtiges Feature wäre das Arbeiten mit mehrtaktigen Sequenzen, wobei in Hardware aus Kosten- und Platzgründne halt immer nur ein Takt dargestellt wird.

Für die Ein und Ausgabe stell ich mir möglichst beliebige Controllerboxen vor, die über MIDI Daten senden und empfangen können. Der Anteil von MAX liegt also darin, eine Controllerbox mit vielen Drehreglern auszulesen und bei Patternwechsel diese mit den aktuellen Werten zu füttern. Für die Entwicklung könnte das z.B. eine Behringer BCR2000 sein, die hat viele Regler, Drehkranzanzeige und leider ein gar nicht passendes Layout, aber das ist für die Programmentwicklung ja erstmal wurscht. Soviel zum Interface.

Die gesetzten Werte sollen dann über einen zweiten MIDI Port ausgegeben werden.

Sync auf MIDI Clock und MMC sollte auch sein.

Wenn dann noch Zusatzfunktionen drin sind wie z.B. das Autogenerieren von Parameterkurven, wäre nett. Dann muss man für z.B. vier Takte Filter auf und Filter zu nicht tausend Regler anfassen, sondern hat ein Makro, bei dem man minimum, maximum und Dauer angibt, den Rest kann dann die Programmlogik machen.

Geht sowas mit Max ? Und : Ist das timingfest ?



Mikrocontroller ist natürlich der Königsweg, aber der ganze MIDI I/O Krams und die Sequenzerlogik sind dann weitere Baustellen, die bei MAX, wenn ich das recht verstanden habe, leichter zu lösen sind. Dann mal was umzubauen oder neue Ideen ausprobieren stell ich mir unter Max auch leichter vor, sozusagen Rapid Prototyping. Wenn dann mal die Bedienkonzepte gereift sind und das Teil kann, was ich mir vorstelle, dann könnt man´s natürlich übertragen und als standalone Box auf ner PIc laufen lassen oder sowas.

PD sagt mit erstmal nix, wird aber gleich ergoogelt

 

[pyrolator]

Ich sehe kein Problem das mit Max zu realisieren.
Allerdings ist es im Vorfeld wichtig sich ganz strukturiert klar zu machen, um was für Daten es geht, um bei eventuellen Erweiterungen nicht wieder vorne anfangen zu müssen.
Max ist gut, wenn es darum geht einzelne "Patches" wie modular miteinander zu verbinden. Es gibt dieses wunderbare Objekt "Bpatcher" - man schreibt eine bestimmte Funktion EINmal und kann sie dann immer wieder in den jeweiligen patchern einsetzen.
Dafür braucht man aber eine recht klare Vorstellung über die Struktur des zu schreibenden Programms.
Also z.b. ein patcher ist für MIDI-In zuständig, eines für die verschiedenen clocks, eines für das sequenzing usw.
Alles in einem Fenster unterzubringen ist unübersichtlich und führt zu aufgeblähten Codes.

Eine weitere Hürde ist das Format der Daten im Programm: Früher habe ich viel mit tables, bags und funbuffs gearbeitet - ist zwar sehr schnell und effektiv, führt aber dazu, dass Inhalte nur schlecht gespeichert und reproduziert werden können. Seit einiger Zeit arbeite ich fast ausschliesslich mit "colls" - ist zwar auf den ersten Blick umständlicher, führt aber zu erheblicher Vereinfachung, wenn Daten mal eben schnell übergeben werden sollen oder zum Abspeichern eines "Sequenzerzustands". Aber das geht vielleicht schon zu sehr in die Materie.....

Grundsätzlich: Wie timingsicher das Ganze ist, hängt von Dir ab. Man kann den einzelnen Funktionen Prioritäten einräumen - und alles was Bildschirmdarstellung oder Grafische Objekte sind, steht bei mir ganz hinten an. Solange es nur um Midi CC geht, dürfte das kein Problem sein - mit Max/Msp werden da noch ganz andere Sachen auf der Audio-Ebene abverlangt, da wird es dann schonmal eng, wenn plötzlich ein paar Filter gleichzeitig zugehen (Audio, nicht Midi!).
Ich kann Dich nur ermutigen Dir die 30 Tage Probeversion zu gönnen und in der Zeit die Tutorials durchzuarbeiten, dann bekommst Du ein Gefühl dafür, ob Dir Max liegt.
Grüsse
pyro

 

[Anonymous]

... z.B. eine Behringer BCR2000 sein, die hat viele Regler, Drehkranzanzeige und leider ein gar nicht passendes Layout...
...
Mikrocontroller ist natürlich der Königsweg ... sozusagen Rapid Prototyping. Wenn dann mal die Bedienkonzepte gereift sind und das Teil kann, was ich mir vorstelle, dann könnt man´s natürlich übertragen und als standalone Box auf ner PIc laufen lassen oder sowas.

Oder Du könntest auch Keykit von Tim Thompson ausprobieren. Da wäre man dann schon sehr sehr nahe an der evtl. späteren Umsetzung von Keykit nach Mikrocontroller, z.B. Arduino, falls Keykit nicht schnell, stabil und robust genug für die eigenen Anforderungen wäre.

Zum unpassenden Layout __eines__ BCR2000: Würden 2 bis 16 BCR2000 das Layout passender machen?

Alle Prototyping-Ideen können schnell mit Keykit ausprobiert, umgetauscht, weiterentwickelt werden, dank der sehr umfangreichen Library im Keykit-Paket selbst. Wenn man irgendwann der Auffassung ist, das System will man gar nicht mehr verändern, könnte man versuchen dieses System nach Arduino umzuprogrammieren. Hier kann man etwas Ähnliches sehen.

 

[b166er]

Ola TonE,


das mit den 2x BCR war mein erster Gedanke, aber dummerweise - ich hab das Ding mal aufgeschraubt - sind die 8er Reihen Encoder und die nebendran liegenden Taster alle auf einer großen Platine untergebracht, was irgendwie doof aussieht und auch eher nicht praktisch zu bedienen ist imho.

Ich überleg noch, evtl. einen BCR komplett zu zerlegen, weil die Drehkranzencoder schon fein sind, wenn auch mechanisch nicht die tollsten. Ein gebrauchter BCR würde immerhin 32 Encoder liefern, zu dem Preis kriegt man sie eher nicht bei Reichelt . Allerdings müsste ich dann doch wieder die Controllerlogik selbst machen, was bei der Behringer erstmal vermieden werden kann, wenn ich die von ihr generierten MIDI Messages auswerten kann.

Also für einen schnellen Prototypen würde das mit 2xBCR schon gehen, aber auf Dauer isses nix, da führt kein Weg an eigener Hardware vorbei. Weil WENN ich schon so einen Aufwand betreiben, dann hab ich kein Bock, mich im Anschluss über labberige Encoder aufzuregen .

Keykit ist ja irgendwie von anno dunnemals, wird das überhaupt noch weiterentwickelt bzw. ist das auf dem aktuellen Stand ?

Der Rest der Welt arbeitet doch eher mit Max oder PD. Ich kenn die Unterschiede zwischen den Plattformen noch nicht so genau, aber was wäre der Killervorteil, wenn man Keykit statt MAX oder PD einsetzt ?

 

[Anonymous]

Keykit ist ja irgendwie von anno dunnemals, wird das überhaupt noch weiterentwickelt bzw. ist das auf dem aktuellen Stand ?

Der Rest der Welt arbeitet doch eher mit Max oder PD. Ich kenn die Unterschiede zwischen den Plattformen noch nicht so genau, aber was wäre der Killervorteil, wenn man Keykit statt MAX oder PD einsetzt ?

Der MIDI-Standard ist ja auch schon älter, Keykit unterstützt den Midi-Standard, und ja das wird noch weiterentwickelt. Die GUI kannst Du einfach ignorieren. Wenn Du Dir die Programmiersprache Keykit genauer ansiehst solltest Du schnell merken wie genial alles ist, schaue einfach mal im Ordner "lib" die *.k Dateien in einem beliebigen Texteditor an. Du könntest mit typoh.k zum Beispiel anfangen, was über die PC-Tastatur Tastenbefehle in musikalische Ereignisse und Zustände umwandelt, das Ergebnis ist gleich hörbar.

Der Killervorteil von Keykit gegenüber Max oder Pd ist, dass man damit richtig programmieren kann. Jeder der etwas Programmiererfahrung schon hat, kann also sofort davon profitieren. Ich kenne keine Einschränkungen, was man damit nicht programmieren könnte. Ich würde es sowieso vorziehen meist nur Feedback in Form von Text zurückzuliefern, damit man in der Übungsphase sieht, was wie wo getriggert wird. Aber laufende Punkte könnte man auch damit auf den Bildschirm malen, wenn man das will. Text ist für mich mehr als genug, schliesslich geht es ja um Musik.

Was der Rest macht sollte nicht so wichtig sein oder doch?!

 

[elmex]

Ich bin gerade dabei mich in pure data einzulesen, mit dem Ziel, es musikalisch einsetzen zu können. Nebenher hab ich auch mal auf YouTube und Vimeo reingeschaut, was denn andere so mit Pd und Max/Msp so machen. Da scheint es mir, als würde es den meisten eher um das wie beim Musik erzeugen zu gehen als um das was. Ist pure data und/oder max/msp nur für technische Spielereien gut und wird nur von Bastelfreaks eingesetzt? Letztendlich drängt sich mir so ein Eindruck auf, wenn ich mich durch die ganzen pure data und max/msp videos clicke. Allerdings gibt es durchaus "Lichtblicke" wie diese:





Oder:

Auch nett:





Vergleicht man nun diese ganzen Stücke mit Videos von Musikern die mit anderer "Musik Software" (DAWs) arbeiten:



Oder sei es mal ganz primitiver Trance aus Live:



Da muss ich persönlich sagen, die letzteren Beispiele finde ich bei weitem "musikalischer" als die pure data und max/msp "Kompositionen". Die sind mir zum Teil zu "avantgardistisch", zu abstrakt (insbesondere die Vimeo Videos). Zuviel Zufall, zu wenig Detail und Feinschliff, vieleicht einfach zuviel "Schaut her, ich hab hier tolle Sachen gebastelt, hört sich an wie ne Katze mit Blechdosen im Karton, aber ich hab es komplett selbst gemacht!". Das mag aber einfach nur mein persönlicher Musikgeschmack sein, und ich erkenne die "Genialität" einfach nicht. Was ist euer Eindruck? Ist pure data und max/msp letztendlich nur was für abgedrehte Spielereien und abstrakte künstliche/künstlerische Musik? Benutzt ihr pure data oder max/msp, und wenn ja, wofür?

 

[snowcrash]

Da muss ich persönlich sagen, die letzteren Beispiele finde ich bei weitem "musikalischer" als die pure data und max/msp "Kompositionen". Die sind mir zum Teil zu "avantgardistisch", zu abstrakt (insbesondere die Vimeo Videos). Zuviel Zufall, zu wenig Detail und Feinschliff, vieleicht einfach zuviel "Schaut her, ich hab hier tolle Sachen gebastelt, hört sich an wie ne Katze mit Blechdosen im Karton, aber ich hab es komplett selbst gemacht!". Das mag aber einfach nur mein persönlicher Musikgeschmack sein, und ich erkenne die "Genialität" einfach nicht. Was ist euer Eindruck? Ist pure data und max/msp letztendlich nur was für abgedrehte Spielereien und abstrakte künstliche/künstlerische Musik? Benutzt ihr pure data oder max/msp, und wenn ja, wofür?

Ja, Pure Data und Max/Msp verwendet man natuerlich wenn man sich mit den Grundlagen elektronischer Klangerzeugung und elektronischer Musik auseinandersetzt und nicht fuer die Psytrance-Party in der Disco. Ob sich das fuer dich erschliesst oder nicht liegt schlussendlich an deinem Zugang zu solch generativer Musik. Dafuer wird eine beliebige Suche nach "Pure Data" auf Vimeo oder Youtube aber qualtiativ auch nicht ausreichen. Wenn du experimentelle Musik generell als "abgedrehte Spielereien" oder nicht erkennbare "Genialitaet" wahrnimmst fehlt dir vermutlich einfach das Grundlagenwissen oder sogar die Bereitschaft dich damit auseinandersetzen zu wollen. Das ist jetzt nicht negativ gemeint, diese Musik hat ja nicht den Anspruch populaere Musik zu sein und unbedingt zu "gefallen" ist einfach gesagt etwas fuer Spezialisten und solche die sich fuer die Grenzbereiche von Musik interessieren oder einfach mal auch ueber den eigenen Tellerrand blicken wollen.

 

[gringo]

Dein Vergleich ist ein Vergleich nach Geschmack. Finde die von dir als avantgardistisch beschriebenen Sachen weit interessanter. Max und Pure Data sind auch nicht für den Ballertrance. Jedes System hat seine Stile und somit auch Max und Pure Data für eher kompliziertere, unangepasste Musik und die ganzen Steuersysteme. Du solltest dich mal mit Koenig und den frühen Elektronikern des WDR aus den 50ern und 60ern beschäftigen, um zu sehen, was damals allein mit Sinusgeneratoren gemacht wurde.

 

[elmex]

Ja, Pure Data und Max/Msp verwendet man natuerlich wenn man sich mit den Grundlagen elektronischer Klangerzeugung und elektronischer Musik auseinandersetzt und nicht fuer die Psytrance-Party in der Disco. Ob sich das fuer dich erschliesst oder nicht liegt schlussendlich an deinem Zugang zu solch generativer Musik. Dafuer wird eine beliebige Suche nach "Pure Data" auf Vimeo oder Youtube aber qualtiativ auch nicht ausreichen. Wenn du experimentelle Musik generell als "abgedrehte Spielereien" oder nicht erkennbare "Genialitaet" wahrnimmst fehlt dir vermutlich einfach das Grundlagenwissen oder sogar die Bereitschaft dich damit auseinandersetzen zu wollen.

Ich gehe auch nicht davon aus, dass diese Videos repräsentativ für diese Musik-Richtung(en) sind. Insgesamt ist das natürlich von meinem Geschmack bestimmt. Letztendlich fehlt mir glaub ich einfach der Zugang zu den Stücken genauso wie mir der Zugang wie zu free jazz fehlt. Ich habe zwar grob eine Ahnung worum es geht, und warum die jeweiligen Musiker sich dort austoben, aber ich persönlich kann mit der Musik (noch?) nichts anfangen.

... diese Musik hat ja nicht den Anspruch populaere Musik zu sein und unbedingt zu "gefallen" ist einfach gesagt etwas fuer Spezialisten ...

Ja, ich denke daher kommt wohl die kognitive Dissonanz die ich verspürte. Den Reiz von zufallsgenerierter oder generativer Musik kenne ich durchaus auch, letztendlich arbeite ich sogar gerade selbst an sowas. Aber ich hoffe, dass ich letztendlich etwas wohlklingenderes raus bekomme. Etwas mit weniger Dissonanz, mehr Zusammenhang. Ich wundere mich nur, dass nicht mehr populär Musiker pd oder max einsetzen. Aber vermutlich haben die nicht das selbe Video gebundene Mitteilungsbedürfnis wie die "technik Bastler". Oder geht man mit pd / max zu weit zurück an die Grundlagen, als das man damit noch populäre Musik machen könnte?

Auf jeden Fall danke für euren Input! Ich denk, ich kann das jetzt etwas besser einordnen.

 

[snowcrash]

Oder geht man mit pd / max zu weit zurück an die Grundlagen, als das man damit noch populäre Musik machen könnte?

Man kann mit pd/max auch Pop machen, keine Frage, aber warum sollte man sich das antun? Das geht mit anderen Instrumenten und Mitteln einfach schneller und leichter. PD und Max/Msp machen dort Sinn wo die starren Strukturen herkoemmlicher Instrumente zu stoeren beginnen. Wenn man sich mit Klangsteuerung jenseits von Midi beschaeftig stoesst man zB sehr schnell an diese Grenzen. Man kann diesen Softwareansatz auch so verstehen: es ist wie ein Modularsystem nur noch eine Stufe darunter. Synthese und Steuerung sind praktisch in die mathematischen/elektronischen Bestandteile zerlegt. Das ist auch das wo sich diese Programme stark von so etwas wie Reaktor unterscheiden.

Ich habe PD zB gerne auch fuer Installationen verwendet, so Sachen wie zB aus einer Kamera ein Bild verarbeiten und in Klang und Controller-Werter umwandeln, aus diesem Klang wieder ein Bild erzeugen, das Ganze ueber Netz-Kollaborativ eingebunden und an verschiedenen Orten aufgefuehrt etc... etc... da sind lediglich der eigenen Vorstellungskraft die Grenzen gesetzt, das geht nicht mit dem Massive Plugin. Diese Sachen sind naturgemaess generischer, weil ein System wie Pop an sich schon wieder komplex ist und den experimentellen Ansatz stoeren wuerde, oftmals liegt ja der Reiz in so einem Aufbau, dass man nicht immer weiss was dabei herauskommen wird. Improvisation ist dazu auch so ein Schluesselbegriff, und damit ist nicht das Pentatonik-Gedudel ueber eine 7/8tel Sequenz aus dem Q960 gemeint...

 

[Tonerzeuger]

Seit einiger Zeit mache ich Versuche mit Pure Data. Ich finde es nicht zuletzt als Lernsystem interessant, weil Du hier bestimmte Syntheseverfahren wie additiv, substraktiv, FM oder Physical Modeling unmittelbar ausprobieren kannst. Auch durch das Analysieren von Beispiel-Patches kann man immer was dazulernen. Allerdings: Vieles verstehe ich erstmal garnicht, weil's z.T. schon recht abstrakt ist.

Und praktische, musikalisch sinnvolle Anwendungen hängen einfach von Deiner Kreativität ab. Ich habe z.B. mal Pure Data als einfachen MIDI-Prozessor benutzt. Damit konnte ich meinen Studio Electronics Monosynth mit dem Blaswandler, der an den DX7 abgeschlossen war, steuern. Technisch ganz einfach: Midi note on und off sowie Pitch Bend werden bloß durchgeleitet und das Breath-Controller-Signal wird auf eine andere Midi-Controller-Nr. geroutet, z.B. für Aftertouch oder die Filterferquenz. Das lässt sich mit nem Laptop auch live einsetzen.

Allerdings hab ich PD noch nie live genutzt. Ich spiele in ner Bluesband und meine Jungs sind nicht experimentell genug für sowas...


Gruß:
W.

 

[Stroheim]

Musikalisch machen kann man sich das auf jeden Fall. Meiner Meinung nach ist die größte Herausforderung bei Max/PD die Kontrollebene, die das Patch steuert. Die Kontrollebene kann sehr schnell komplex und unübersichtlich werden, obwohl das Patch noch gar nicht viel tut. Es kann locker ein halbes Jahr dauern, bis man sich da die Grundlagen erarbeitet hat, je nach Background. Es ist auf jeden Fall erstrebenswert, die Kontrollebene so einfach und elegant wie möglich zu halten, auch damit der Datenfluss in Grenzen gehalten wird und das System nicht unnötig belastet. Aber auch, um etwas Überblick zu behalten und Fehler schneller zu finden. Sehr wichtig dabei sind Abstraktionen und die Verwendung der Dollar-Signs als Variablen. Besonders der Unterschied zwischen $0 und $1. Wenn man das mal kapiert hat, ist das Schlimmste geschafft. Sehr zu empfehlen ist das Tutorial von Johannes Kreidler und das Forum puredata.hurleur.com... Ich würde auch sagen, am besten die vielen zusätzlichen Objekte von Pd-extended erstmal weglassen und sich auf die Vanilla-Objekte als Grundlage konzentrieren, denn damit kann man eigentlich schon alles machen. Trotzdem ist die Installation von extended besser, die Schrift ist einfach leichter zu lesen. Aber die ganzen Bibliotheken darin sind erstmal verwirrend.

Viel Glück!

 

[Hypnotoad]

So, ich habe mir jetzt mal alle Beispiele angehoert und ich muss sagen, dass ich die PD / MAX sachen um einiges "besser" fande als die beiden Gegenbeispiele.
Sie waren irgendwie interessanter, vorallem das Lied, dass aus einem Neuronalen Netzwerk bestand.

Ich denke, dass du PD / MAX nicht als Instrument oder DAW sehen solltest sondern wirklich als das was es ist: Eine Programmiersprache mit exzellenter Audiointegration.

 

[Stroheim]

Bei www.netpd.org kann man sich auch einiges anhören. Da gibts eher gewöhnlichere, rhythmische, musikalische Sachen zu hören. Nur so. Man muss ja keine algorithmische, generative, experimentelle, super-avantgardistische Musik damit machen.

Kannst auch Vsts verwenden. Aber keine Ahnung ob und wie das unter Linux läuft. Wahrscheinlich nicht. Das Objekt ist vst~, nicht im Pd-Standard-Paket mit drin, aber irgendwo im Netz zu finden, bei Max schon dabei. Sind die gleichen. Das ist sehr interessant mit Sequenzern, da kriegst du Sachen mit raus, die passieren in so einer Daw einfach nicht.

 

[elmex]

Kannst auch Vsts verwenden. Aber keine Ahnung ob und wie das unter Linux läuft. Wahrscheinlich nicht. Das Objekt ist vst~, nicht im Pd-Standard-Paket mit drin, aber irgendwo im Netz zu finden, bei Max schon dabei. Sind die gleichen. Das ist sehr interessant mit Sequenzern, da kriegst du Sachen mit raus, die passieren in so einer Daw einfach nicht.

Jo, das kenn ich. Arbeite aber halt meist unter Linux, da werden Windows-VSTs aber nicht funktionieren.

So, ich habe mir jetzt mal alle Beispiele angehoert und ich muss sagen, dass ich die PD / MAX sachen um einiges "besser" fande als die beiden Gegenbeispiele.
Sie waren irgendwie interessanter, vorallem das Lied, dass aus einem Neuronalen Netzwerk bestand.

Uff, genau das fand ich am uninteressantesten Sicher, ein toller theoretischer Ansatz, aber was am Ende bei raus kommt fand ich jetzt, bei allem Interesse, nicht besonders "schön". Oder anders gesagt: Würde ich persönlich mir nicht freiwillig nochmal anhören. Evtl. muss ich dafür noch "reifen"

Ich denke, dass du PD / MAX nicht als Instrument oder DAW sehen solltest sondern wirklich als das was es ist: Eine Programmiersprache mit exzellenter Audiointegration.

Hmm, ja ich sah es evtl. zu sehr als Instrument. Aber richtig, ich selbst plane es ja auch als toolbox für alle Fälle einzusetzen. Vorallem für die Fälle, in denen mir Renoise nicht (mehr) ausreicht. Sei es als Soundquelle oder als Kontroll-/Audio-Signal quelle/umformer.

 

[Duke64]

Für mich stellt sich die Frage: woarn sich probieren ?

PD, Faust, SuperCollider, Chuck, Csound, JesuSonic ?

Die Qual der Wahl ... die Zeit und Lust, alles mal anzutesten habe ich nicht.
Einfach wird keins sein, keine Frage. Gesucht wird aber die einfachste/übersichtlichste Lösung mit einer größeren Community (falls man Fragen hat).
Video wäre auch nicht schlecht, aber eher zweitranging.

An Faust reizt mich z.B., dass man auch VSTs erzeugen kann.

 

[elmex]

Grafisch sind halt nur PD und Max/Msp, soweit ich weiss. PD ist halt nicht nur freie software, sondern auch noch für lau zu haben. Läuft auch auf allen gängigen Plattformen. Max/Msp kostet halt, aber hat dafür ja diese Ableton-Integration mit Max4Live - von der ich aber nicht mehr weiss.

Csound und SuperCollider sind halt rein text basiert, und nicht so real-time wie PD oder Max. Der vorteil an PD und Max ist halt, dass man live sehr einfach rumbasteln kann, und dass die Signal-Flüsse grafisch in 2D dargestellt sind. Die Verbindungen sind in text-form halt nicht ganz so einfach zu überschauen.

PD und Max haben beide recht grosse Communities. Und wenn man eines kann, dann ist der Umstieg auf das andere eigentlich recht problemlos, da sie eigentlich das selbe Paradigma haben. Wenn man einen Synthesizer und Sequencer mit PD bauen kann, dann glaub ich sollte es keinen Nachmittag dauern bis man das auch mit Max kann - wenn man sich das Handbuch mal durchliest. Umgekehrt gehts auch.

Ich würde jedem raten, einfach mal mit PD anzufangen. Es gibt mindestens 3 Bücher darüber im Netz zu finden für lau:

http://www.pd-tutorial.com/ - sogar in Deutsch!
http://en.flossmanuals.net/pure-data/ - ca. die selbe Information, in Englisch
http://crca.ucsd.edu/~msp/techniques.htm - Frei verfügbares Buch vom PD Author, was richtig schön technisch in die Tiefe geht und alles anhand von PD Patches erklärt. In Englisch. Gibts auch in Papier-Form bei Amazon.

Dazu kommen ein paar Video-Tutorials auf YouTube, da kann ich dieses hier empfehlen:

http://www.youtube.com/playlist?list=PL12DC9A161D8DC5DC - Von einem "Dr.Hdez", deckt erstmal alle Grundlagen ganz gut ab.

Und für alles weitere hat PD auch eine Hilfe gleich dabei, in der man bei jedem Objekt/Element gleich mit rechtsclick auf die entsprechende Referenzdokumentation kommt.

Solltest du dich für PD entscheiden, würde ich raten gleich bei pd-extended anzufangen. Wie schon vorher von jemandem im Thread erwähnt, für den Anfang evtl. die ganzen speziellen extensions erstmal weg lassen, bis man weiss warum man sie haben will, oder warum nicht. Der Hauptpunkt ist, dass das Interface von pd-extended ein wenig hübscher und übersichtlicher ist. Bekommt man hier: http://puredata.info/downloads/pd-extended

Bei Max/Msp kenne ich mich nicht so aus, was die frei verfügbare Information angeht. Da gibts glaub ich auch ein Buch was helfen soll. Aber hier musst du gleich Geld in die Hand nehmen, und ob es das Wert ist muss jeder selbst wissen.

 

[snowcrash]

Ja, das Buch von Johannes Kreidler kann ich auch nur sehr empfehlen, auch als Nachschlagewerk fuer Fortgeschrittene.

 

[Stroheim]

An Faust reizt mich z.B., dass man auch VSTs erzeugen kann.

Geht auch mit Pd, ist bloß ein bisschen knifflig
Hab die andern leider nie probiert, Supercollider fänd ich aber auch spannend
Supercollider und Csound sollen jedenfalls klanglich etwas besser sein, keine Ahnung, wie sehr das stimmt
Dafür sind Pd und Max für live ideal, Csound geht da wohl gar nicht
Auf jeden Fall haben alle vier sehr gute Communities
Schneller zu überblicken sind wahrscheinlich Pd/Max
Faust, auch keine Ahnung, aber ich glaube, es kann Pd-Patches erzeugen...

 

[elmex]

Supercollider und Csound sollen jedenfalls klanglich etwas besser sein, keine Ahnung, wie sehr das stimmt

Ja, davon hab ich auch gehört. Aber letztendlich hängt es glaub ich ganz davon ab wie man seine Oszillatoren und Filter nun aufbaut. Wenn man in PD den phasor~ nimmt (hartes digitales sägezahn signal) und auf dac~ (audio output) rausknallt, bekommt man natürlich aliasing wies tier. Wenn man hier aber mit low-pass filtern + oversampling oder einfach von anfang an mit bandlimiting arbeitet, bekommt man auch schönere Spektren hin.
Csound hat hier natürlich den Vorteil, dass man nicht unbedingt alles in real-zeit machen muss. Da kann man dann ohne
größere Sorgen um CPU oversampling betreiben. Letztendlich schenke ich persönlich dem Qualitäts ge-unke erstmal wenig Aufmerksamkeit. Hängt doch die Soundqualität in aller erster Linie vom Programmierer (also mir) ab.