Realtime Softwarekompressor, serverseitig

Status
Für weitere Antworten geschlossen.
seekwhencer

seekwhencer

Gesperrter Benutzer
Hallo liebe Technikgemeinde,

ich möchte mal etwas vorstellen. Vielleicht kennt der eine oder andere von euch Pure Data oder den großen Bruder Max MSP. Beides Werkzeuge um grafisch zu programmieren, ganz grob. Ersteres ist frei, letzteren ist kommerziell. Darum will ich mal nur auf Pure Data eingehen.

"PD (aka Pure Data) is a real-time graphical programming environment for audio, video, and graphical processing."

http://puredata.info/
http://de.wikipedia.org/wiki/Pure_data

Natürlich gibt es PD auch für Unix, was die ganze Sache für Serverbetreiber noch interessanter macht.

Ich habe damit im Rahmen des Studiums und darüber hinaus Audio-Processing gemacht. Man kann mit PD faktisch einen Synthi nachbauen. Aber nicht nur Töne erzeugen, sondern auch manipulieren. So kann man auch einen Konpressor bauen.

Nicht nur das, mit PD kann man einen Stream empfangen, manipulieren und senden. PD kann Signale jeder Art, sei es via Fifo, Http, UPD etc. empfangen.

Die "Anwendung" kann in der Shell laufen unter Unix :)

Nun. Ich will nicht sagen, dass man damit ein Online und Realtime Streaming Mischpult bauen kann, sondern auch noch einen Kompressor etc. realisieren. Gesteuert werden kann sowas wiederum via Webinterface.

Ich frage mal in die Runde: hat jemand Lust mit mir an sowas zu arbeiten?! Ich würds natürlich unter CC veröffentlichen wollen...

Hat ansonsten jemand Erfahrungen in diesem Bereich mit dieser Software gemacht?

Gruß
Seek
 
AW: Realtime Softwarekompressor, serverseitig

Hi,

Erstmal danke für die Links, ich hatte bisher nie Lust/Zeit mich mit PD ausseinanderzusetzen, dass man mit PD auch streamen kann wusste ich gar nicht, eventuell noch ein Grund mehr, mich mal damit zu beschäftigen.

Ob sich das jetzt lohnt auf Basis von PD einen "Streamingprozessor" zu entwickeln weiss ich nicht, ähnliche Funktionalität gibt es schon in Form von Liquidsoap:

http://savonet.sourceforge.net/

Allerdings ist dieses Projekt doch sehr auf Radioautomation/Streaming zugeschnitten und ist damit nicht annähernd so flexibel wie PD, allerdings daher auch einfacher zu verstehen.

Grundsätzlich wirst du mit solchen Projekten hier im Forum meist auf taube Ohren stoßen, es gibt viele interessante technische Möglichkeiten und trotzdem wird ewig nur diskutiert wie man dieses und jenes Problem mittels Shoutcast-Software und mal mehr meist aber weniger eleganten Taktiken und Scripten löst.

Gruss, Markus
 
AW: Realtime Softwarekompressor, serverseitig

Hi Markus,

nunja, du hast natürlich recht. Ob sich hier jemand wirklich mit der Materie im Kern beschäftigen will, mag ich zu bezweifeln. Weil "die anderen" nutzen schön ihr SAM etc. Nur wird den meisten nicht klar, dass sie Internetradio machen und ihnen damit deutlich mehr an Möglichkeiten zur Verfügung stehen.

Aber das soll ja nicht unser Problem sein.

Ich kann ja mal kurz beschreiben, was ich mit MAX MSP bzw. Pure Data gemacht habe: Wir waren zehn Leute, jeder an seinem Rechner. Wir bastelten uns eine wirklich geile Audio-Applikation und performten das auf einen Server. Dieser Server mixte diese 10 Streams zu einem Stream. Das Ergebnis: eine wirklich geile Soundperformance.

Was anderes war etwas "strange". Vielleicht kennst du sog. War-Driving. WLAN-Netze hacken. Nun. Das habe ich auch mal gemacht. Nur habe ich das in einer künstlerischen Interpretation gemacht. Ergo: Datenstrom in eine Pipe, Pipe mit PD angezapft, Datenstrom auditiv interpretiert. :) Mal vereinfacht ausgedrückt. Natürlich diese Interpretation ebenso wieder rausgestreamt. Kann man sich so vorstellen, dass man mit Kopfhörer auf dem Kopf und Laptop im Rücksack durch die Stadt läuft.

Also PD und Streaming: Top!

Nun zum "Teil". Ehrlich gesagt: kein Plan, was man machen kann und will. In erster Linie möchte ich einen Online-Kompressor haben. Das ist wohl das wichtigste. Wenn man aber das Basis-Setup geschaffen hat, ist es kein Problem, weitere Sachen mit dem Stream anzustellen.

Ich kann mir auch einen serverseitigen Talkover vorstellen. Nur dürften die Latenzzeiten schlecht sein, so dass man seinen talk nicht wirklich timen kann. Aber unkontrolliert über die Musik brabbeln, wie es letztendlich die ganzen Radios machen, sollte damit möglich sein.

Letztendlich will ich eine Online-Automation mit einem Kompressor und einem Talkover paaren.

Das ganze Teil bräuchte auch ein Webinterface, bzw. muss es auch steuerbar sein. Auch kein Problem, theoretisch.

Sag an
Seek
 
AW: Realtime Softwarekompressor, serverseitig

Die anderen, die einfach nur ihren "Sam" machen arbeiten aber bereits während andere noch frickeln. Da Softwarelösungen in dem bereich NIE die Performance hardwarebasierter Lösungen haben werden (zumindest nicht in naher Zukunft) stecken sich halt die anderen lieber ihre vorhandenen Geräte ans Pult. Dass du dich so für die serverbasierte Radioautomation einsetzt sei dir ungenommen und du möchtest natürlich auch dein Projekt weiter ausbauen - OK soweit, aber tu nicht so als würden die Anderen ihr Handwerk nicht verstehen.

Ach und nochwas für die Zukunft vielleicht :)
Man sollte nie so groß von Projekten sprechen, deren Erledigungsstand im unteren Prozenzbereich liegen... es gibt immer jemanden der schneller ist und dann guckt man in die Röhre. "Theoretisch" können hier schon zu viele in Deutschland.
 
AW: Realtime Softwarekompressor, serverseitig

Was für eine Diva.

Hier geht es um Pure Data / Max MSP und Streaming in einem technischen Lichte. Dein Beitrag ist (mal wieder) sehr deplaziert und trägt NICHTS zu einer konstruktiven Problemlösung bei.

Seek
 
AW: Realtime Softwarekompressor, serverseitig

Hi seek,
konstruktiven Problemlösung
Zum Vergrößern anklicken....
Koenntest du dann bitte fuer Leute wie mich noch mal klar das Problem schildern? Ich seh nur, dass du n Kompressor bauen willst. Ok, mach doch einfach, was hindert dich daran? Weiter sehe ich, du suchst fuer diese Idee Mitstreiter. Gut. Wenn dein neues Projekt auch wieder kommerziell werden soll, und das ist anzunehmen, dann sag das deinen Rekruten rechtzeitig, ideralerweise gleich jetzt.
Und bevor du auch mir vorwirfst, keine konstruktive Loesung fuer was auch immer zu haben, ich hatte von PD vor diesem Thread noch nie gehoert, beherrsche es mithin nicht. Die website sieht interessant aus, ja, kann sein, dass man damit wirklich tolle Sachen machen kann. Allerding werde ich mir nicht eine neue Entwicklungsumgebung installieren, ne neue Sprache lernen und ueberhaupt irgend welchen Aufwand betreiben fuer ein Projekt, das noch nicht mal eine ausgereifte Idee ist. Zudem ist mein Kopf grad voll mit C und Assembler, damit kann man auch tolle Sachen machen.
Am Besten, du setzt dich erst mal hin und schreibst dir ein genaues Konzept, technisch und finanziell. Von Kommerz hab ich keine Ahnung, aber technisch interessieren folgende Fragen (und Antworten):
* welche Zielplattform
* eigener webserver oder Anbindung an bestehenden
* Authentifizierung am System
* Multithreading, kann man mehrere streams mit unterschiedlichen Parametern komprimieren
Das sind nur einige Anregungen, sicher faellt dir noch mehr ein. Wenn du das alles hast, schreibst dir ein Pflichtenheft und erst dann suchst du die Mitstreiter, in Abhaengigkeit davon, wer was (beitragen) kann.
Also, ab an die Arbeit, hast viel vor.
Viel Spass, Peng
 
AW: Realtime Softwarekompressor, serverseitig

Hi Peng,

Solange kann ich sagen, dass ich nicht C und erst recht kein Assembler programmieren kann. Damit ist es natürlich erst recht möglich. Klar.

Und nein, siehe oben, ich würds der Menschheit zurückgeben und nicht als Produkt verkaufen wollen. Ich hoffe das ist angekommen.

Ich habe auch schon gesagt, dass ich keinen konkreten Plan auf dem Schrim habe und Leute suche, die an dieser Stelle mit mir beginnen wollen. Ok?



Aber auf die Fragen einzugehen: Unix / OSX als Plattform. Das mit der Authentifizierung kann ich so nicht verstehen. Wie meinst du das genau? Und ob man damit mit mehreren Streams jonglieren kann? Kann, ist das falsche Wort. Soll, treffe es besser.


Aber du hast Recht. Ich machs allein. Und ich muss meine Mitgliedschaft in diesem Forum überdenken.

Seek
 
AW: Realtime Softwarekompressor, serverseitig

hey seek.
was hat denn dieses Projekt mit der Mitgliedschaft in diesem Forum zu tun? OK, im PD-forum waerst du damit besser aufgehoben, das kann sein.

Zur Auth: Du willst ein webinterface zur Konfiguration. Das muss gegen unerlaubten Zugriff geschuetzt sein, heisst , man braucht ein gescheites login-verfahren. Genau das aber gestaltet sich, samt weitestgehend automatischer Registration usw. im Detail sehr schwierig. Evtl. brauchst du dafuer ne Datenbank. Kann PD mit Datenbanken umgehen? Eine Abwaelzung der aufgabe auf .htaccess faellt wegen mangelnder Flexibilitaet aus, blieben als externe Option evtl. perl oder php (dort koennte man auch schoen mit sessionID arbeiten), allerdings kenn ich auch da die Schnittstelle zu PD nicht.

Wenn dein Konzept etwas ausgereifter ist, kannst du mich ja gerne noch mal ansprechen, wahrscheinlich guenstigerweise per PN, die meisten hier interessieren sich sicher nicht fuer die techn. Einzelheiten.

lg, peng

PS, Tippfehler bitte ich zu entschuldigen ich liege grad sehr unergonomisch mitm Laptop im Bett.
 
AW: Realtime Softwarekompressor, serverseitig

Also wenn man immer gleich die Flinte ins Korn wirft nur weil man auf Gegenwind stößt wird sich kommerziell nicht blumig auswirken. :(
 
AW: Realtime Softwarekompressor, serverseitig

tach peng, keen,

ich bins, der gleiche wie oben. ;)

na ich würde den Austausch doch gern öffentlich führen, wenn es nichts ausmacht?

Zum Webinterface:

Klar. Natürlich muss das gegen Angriffe jeder Art gewapptnet sein. Ob das jetzt eine MySql-Injection, CSS und Co. ist. Und natürlich muss da eine Benutzerverwaltung her. Klar kann das auf PHP basieren. Und klar auch, dass damit nicht täglich hunderte von Leuten herumspielen, sondern eine Hand voll, die bestmöglich den Link dort hin unter Verschluss halten.

Davon aber mal abgesehen, bzw. danach weitergedeacht: wo kanns hingehen?! Bzw.wie bekommt man Pure Data dazu, Eingaben einer Website zu verarbeiten. Nun. Die ich glaube simpelste Lösung kann sein, bspw. PHP dazu zu bringen, Job-Files, Text-Files auf dem Server zu schreiben, die Pure Data in einem bestimmten Intervall liest. Klar ist, dass damit Schalter möglich sind, aber keine Slider, bei denen der Intervall so kurz wie möglich sein muss.

Pure Data kann aus Fifo lesen. Also einen puren Datenstrom schlucken und mit diesem etwas anfangen. Aber auch sind Signale direkt über Http oder Udp möglich. Letzteres ist interessant, um bspw. Midi über Lan zu realisieren. Aber das ist gar nicht die Frage, da ich denke, dass man Slides, bspw. Lautstärke, auch als Verhalten einfach programmiert und für den Auslöser wieder nur den "Schalter" benutzt. Darum glaube ich, ist ein schnelles Schreiben, ein kurzer Intervall, nicht nötig. Ein Sekunden-Intervall kann reichen - oder eben dann auf Interaktion des Users.

Pure Data kann gleich PHP "Job-Files" im Filesystem schreiben. Wenn PHP zugriff auf diese Files haben kann, erfährt es auch etwas über den Status von Pure Data.

So stelle ich mir eine doch recht einfach gestrickte Kommunikation zwischen Website und Pure Data vor.

Eine andere Möglichkeit kann sein, direkt auf Ebene vom php shell() exec() usw. zu arbeiten. Was ich aber nicht begrüße, da ich prinzipiell PHP sowas nicht erlaube, aber das ist Geschmackssache.

Prinzipiell würde ich auch nicht versuchen wollen, den Browser und etwaige davon abhängigen Prozessen schneller als 1 Sekunde Daten mit dem Server auszutauschen. Wenn ich das wollte, würde ich mir in Java und http://www.processing.org* ein Applet basteln. Aber nur, WENN ich das wollte / müsste. Ich würde das vertagen wollen :) Erstmal kleine Brötchen backen...

Ich sehe Handlungsbedarf beim Webinterface, der Kommunikation zwischen Website und PD, und dem eigentlichen PD-Setup. Ich hab von allem ein wenig Ahnung und würde das gerne mit jemanden zusammen, zusammenbringen.

Gruß

* Processing is an open source programming language and environment for people who want to program images, animation, and interactions. It is used by students, artists, designers, researchers, and hobbyists for learning, prototyping, and production. It is created to teach fundamentals of computer programming within a visual context and to serve as a software sketchbook and professional production tool. Processing is developed by artists and designers as an alternative to proprietary software tools in the same domain.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben