1. Home
  2. Chat
  3. Forum
  4. Kalender
    1. Termine
    2. Karte
  5. Lexikon
    1. Letzte Änderungen
  6. Marktplatz
    1. Bewertungen
  • Anmelden
  • Registrieren
  • Suche
Dieses Thema
  • Alles
  • Dieses Thema
  • Dieses Forum
  • Artikel
  • Forum
  • Termine
  • Lexikon
  • Marktplatz-Eintrag
  • Seiten
  • Erweiterte Suche
  1. PA-Forum
  2. Forum
  3. Professionelle Veranstaltungstechnik
  4. Veranstaltungstechnik AUDIO
  5. Signalquellen

"MuTe" Software Vorstellung

  • artemis
  • 11. November 2014 um 20:42
  • artemis
    Verifiziert
    Beiträge
    26
    • 11. November 2014 um 20:42
    • #1

    Hallo.

    Da angefragt wurde, hier ein paar Details zur "MuTe" Software:
    "MuTe" (für "Musik Technik" :) Ob der Name so bleibt, weiß ich noch nicht) ist eine Multiplayer Audio Software. Nach dem wir jahrelang mit CDs und MDs hantiert haben, wurde uns das irgendwann zu blöd. Bei jeder Änderung der Musik mussten neue CDs gebrannt werden, gebrannte CDs sind nicht gerade unempfindlich und die meisten CD-Player können Stöße während der Wiedergabe nicht so gut wegstecken. MDs wären für einen Teil der Probleme eine Lösung, aber die gibts bald auch nicht mehr... Die CD-Player hingen übrigens an einem separaten Mischpult für den Musiktechniker, welches dann an unser Roland M-400 gesteckt war.

    Nun sind wir ein Amateurtheater, wir brauchten also einen Ersatz, welcher die Haptik von den zwei bis drei verwendeten CD-Player gut ersetzte und auch das zusätzliche Mischpult überflüssig macht. Die erste Idee war ein von diesen DJ-Softwares zusammen mit passender Hardware. Da hätten wir zwei Player und für jeden einen Fader. Allerdings hatten wir auch schon mal die Situation, dass wir drei Player brauchten (Musik, Sprechereinspielungen und Effekte). Und wir wollten ein flexibles Routing der Audiosignale (quasi Surround Sound). Außerdem konnten wir uns mit den meisten Oberflächen nicht so recht anfreunden... Daher haben wir uns entschlossen, eine Eigenentwicklung zu starten. 2013 begonnen, Saison 2014 im produktiven Einsatz und jetzt in der Winterpause wieder in der Entwicklung...

    MuTe besteht aus mehreren Komponenten: Einmal die Server oder Hauptkomponente und dann die Kontroller Komponenten (wie die GUI oder die Faderports). Kommunikation läuft über ein Bussystem, welches theoretisch auch Netzwerkfähing ist (noch nicht getestet). Stürzt einer von den Kontroller ab, wirkt sich das normalerweise nicht auf den Server aus. Das ganze läuft auf Linux (zZ. auf einem minimalen Debian) im Kioskmodus. Das heißt, es gibt keine Taskleiste oder sowas. Wir haben hier einen gebrauchten Mittelklasse PC, Daten hab ich gerade nicht da. Zwei Monitore. Die GUI braucht noch recht viel Leistung, wegen den ganzen Pegelanzeigen, aber das wird noch verbessert. Als Soundkarte haben wir eine externe 8 Kanal Soundkarte. Dazu zwei Faderports von PreSonus.

    Projekt:
    - Projekte bestehen aus der Projektdatei (eine einfache .xml Datei) und den Flac Audio Dateien.
    - Es können Projekte als Favorit markiert werden, so dass diese beim Start zur Auswahl angeboten werden.
    Player und Tracks:
    - Variable Anzahl von Player mit jeweils eigener Playlist.
    - Bei jedem Player kann die Lautstärke separat geändert werden.
    - Pro Player variable Anzahl von Ausgängen, für jeden Ausgang kann die Lautstärke live separat geändert werden.
    - Jeder Track kann zwischen 1 und 8 Kanäle haben (Flac Format).
    - Diese können für jeden Track beliebig auf die Ausgänge vom Player geroutet werden, natürlich in der jeweils gewünschten Lautstärke. Dies kann auch live geändert werden.
    - Bei jeder Track kann die Lautstärke separat geändert werden.
    - Für jeden Ausgang bei jedem Player eine eigene Level Anzeige.
    - Alle Player können gleichzeitig laufen.
    - Pro Player gibts eine Countdownfunktion, welche nach Ablauf eine Aktion (s.u.) starten kann.
    Aktionen:
    - Im Projekt können Aktionen definiert werden. Aktionen werden aus Plugin-Dateien geladen und können so einfach erweitert werden.
    - Es gibt zum Beispiel Aktionen fürs Starten und Stoppen von Playern, Ändern der Playerlautstärke (wie 10 Sekunden einblenden), Ändern der Ausgangslautstärken und setzen der Countdowns usw...
    - Aktionen lassen sich verketten.
    - Zur Übersichtlichkeit können die "Startaktionen" einer Aktionskette in einem Slot "gesteckt" werden. Diese werden dann übersichtlich in der GUI angezeigt.
    Events:
    - Von den Playern und Tracks werden Events generiert, wenn sie gestartet, gestoppt oder aktiviert usw. werden. Dies kann Aktionen auslösen (Praktisch, wenn man nach dem Stoppen eines Players automatisch immer den nächsten Track aktivieren will).
    Tags:
    - Im Projekt können sogenannte Tags gesetzt werden. Player und Tracks machen dies automatisch (zB. "track_1_played").
    - Aktionen können darauf reagiere. (So lässt sich zum Beispiel verhindern, dass die Aktion "Boxentest" während der Aufführung gestartet wird)

    Ein paar Features sind noch geplant (zum Beispiel Solo auf Kopfhörer), auch fehlt noch recht viel in der GUI (Projekte anlegen geht nur über einen Text Editor :-)) und es sind auch noch einige Fehler drin... Oh, was MuTe nicht können wird: Audiobearbeitung und Effekte. Dafür gibts besserer Programme

    Zu den Faderports: Diese werden per MIDI angesteuert. Wir nutzen zur Zeit nur den Fader und die unteren Knöpfe. Funktioneren tun sie aber alle, auch die Beleuchtung lässt sich steuern.

    Im Anhang sind noch 3 Screenshots. Das Design ist noch nicht komplett fertig. Generell haben wir uns keine Gedanken darüber gemacht, ob und wie wir die Software veröffentlichen würden. Wenn Interesse daran besteht, überlegen wir uns was :)
    So, das reicht glaub ich erstmal. Fragen beantwortet ich dazu gerne.




    Bis dann,
    artemis

  • marcoboy
    Verifiziert
    Reaktionen
    190
    Beiträge
    6.814
    Marktplatz Einträge
    3
    • 14. November 2014 um 09:13
    • #2

    Grundsätzliches Problem unter linux stellt die Schnittstelle zur Audiohardware dar. Multichannel Audio ist immer noch ein Problem. Die performance bzw. die Latenz sind denkbar schlecht.

  • tufkamar
    Gast
    • 14. November 2014 um 10:04
    • #3

    Na, da wäre ich doch mal gespannt auf belastbare Fakten zu dieser pauschalen Aussagen.

    @TE: Kömntest Du ein paar Infos zu den verwendeten Softwarekomponenten posten?

  • mischpultschorsch
    Profi
    Reaktionen
    9
    Beiträge
    3.503
    • 14. November 2014 um 13:46
    • #4
    Zitat von "marcoboy"

    Grundsätzliches Problem unter linux stellt die Schnittstelle zur Audiohardware dar. Multichannel Audio ist immer noch ein Problem. Die performance bzw. die Latenz sind denkbar schlecht.

    Wow - sehr fundierte Aussage.
    Gibts dazu auch irgendwas verifiziertes, oder ist das einfach mal nur simples Linuxbashing aus Unwissenheit heraus?

  • audiobo
    Profi
    Reaktionen
    2.290
    Beiträge
    5.423
    Einträge
    7
    • 14. November 2014 um 16:34
    • #5

    Also eine der ersten Ubuntu-Studio-Versionen hat meine alte Terratec EWS88 PCI-Karte damals in einen ungeahnten Latenz-Himmel erhoben. Leider liefen viele andere Sachen nicht so wie ich es damals erhofft hatte und ich habe mir dann das System zerbastelt bzw. irgendwann auch keine Lust mehr darauf gehabt - viele Ubuntu-Updates mit zahlreichen neuen Inkompatibilitäten taten dann ihr übriges... :roll:

    Umso mehr: Respekt wenn es sauber läuft. :wink:

  • kob1
    Profi
    Reaktionen
    161
    Beiträge
    1.084
    • 14. November 2014 um 18:30
    • #6

    Frage ist halt, ob Latenz beim bloßen Playback wirklich eine Rolle spielt...

  • tufkamar
    Gast
    • 14. November 2014 um 18:49
    • #7

    ich frage mich immer noch nach der Qualität der Aussage - das genannte Ubuntu-Studio ist zwar nicht für den Liveeinsatz grundlegend vorgesehen (dafür gibt's andere Distributionen) aber aus div. Berichten weiß ich, daß es grundlegend auch funktioniert.

    Ja - es mag sein, daß nicht jedes Audiointerface mit Linux problemfrei spielt, aber das ändert nichts an der grundlegenden Eignung des Systems für den Audio-Einsatz. Btw - die iLive läuft mit Linux als OS.

    Deswegen würde ich bei dem Projekt des TE ein paar technische Details interessieren.

  • artemis
    Verifiziert
    Beiträge
    26
    • 14. November 2014 um 20:03
    • #8

    Hallo ihr...

    Also wie schon geschrieben wurde funktionieren Audiosachen mit Linux grundsätzlich. Klar, kommt immer mal wieder vor, dass Hardware nicht unterstützt wird, aber eigentlich selten. Meine 8 Kanal Soundkarte (USB) von ESI (Gigaport HD+) funktionierte direkt, schön als Surroundkarte. Über die Latenz kann ich nicht viel sagen. Man kann natürlich auch unter Linux hardwarenah programmieren, das wurde aber bei MuTe nicht gemacht. Es ist in der Hinsicht auch noch nix optimiert, die ganze Signalpipeline ist noch etwas, naja, gewagt :) (musste ein paar Bugs umgehen). Aber für uns hats eine Saison gereicht. Wenn ich schätzen müsste, hatten wir ne Latenz von ca. 100 - 200 ms. Wobei dies nur bei Lautstärkenänderungen vorkam. Play, Pause, Stop funktionierten ohne fühlbare Latenz. Sicher nicht optimal, aber bei unseren Theaterstücken kommt es selten vor, dass man innerhalb von 200 ms präzise die Lautstärke ändern muss. :) Jetzt in meiner Entwicklungs-VM ist das natürlich etwas höher, so um 500 ms.

    Zu der Software:
    - Debian GNU/Linux als OS, alles rausgeschmissen, was nicht benötigt wurde. So passt das System auf einen 4GB USB Stick (Falls der Rechner mal ausfällt boote ich damit einfach einen anderen und weiter gehts :) (Versuch das mal mit Windows :) )
    - Programmiersprache: Vala (http://de.wikipedia.org/wiki/Vala_(Programmiersprache)). Wollte mal was neues ausprobieren :)
    - Audioframework: GStreamer (Zur Zeit läuft auch noch PulseAudio als Systemdämon. Eigentlich wollte ich direkt auf ALSA, aber das ist was sturer :-), Aber da könnte man die Latenz sicher noch verringern)
    - UI-Toolkit: Gtk3
    - Faderports werden per PortMidi angesprochen, läuft super, nur dass ich noch keine Möglichkeit gefunden habe, die zwei Faderports beim Start zu unterscheiden. So ist mal der linke für PLAYER 1 zuständig und mal der rechte. Sehr nervig leider. Da gibts aber schon Ideen, wird gerade komplett umgebaut.
    - Im Prinzip lässt sich jedes Gerät zum steuern verwenden, solange man irgendwie per C-Programm an die Daten kommt. Lustig war ein erster Versuch mit Wiimotes. Wurde aber zu anstengend, ne ganze Show mit den Armen zu fuchteln :)

    So, das dazu erstmal. Vielleicht krieg ich das VM-Image (VirtualBox) ja auch unter 2GB, dann könnte ich Interessierten das über Dropbox zum anschauen zur Verfügung stellen.

    Bis dann,
    artemis

  • marcoboy
    Verifiziert
    Reaktionen
    190
    Beiträge
    6.814
    Marktplatz Einträge
    3
    • 15. November 2014 um 08:04
    • #9

    Die Soundkarte läuft weil sie als Standard Audiocore läuft. So läuft sie auch unter anderen System ohne Treiber. Wer mehr will braucht den Treiber dazu.

    Das Problem deine Latenz "Knopf" drücken hängt von der CPU Last ab. Deswegen sind es in der virtuellen Maschine mehr. Ineffektive Speicherzugriffe, fehlerhafte oder keine Prozessaufteilung und die Interprozesskommunikation über Pipes ist nicht gerade toll.

    http://download2.galileo-press.de/openbook/galil…grammierung.zip
    http://download2.galileo-press.de/openbook/galil…von_a_bis_z.zip

    Keine Angst sind openBooks :wink: so was gibt es auch noch. Das wird dir helfen nach und nach die Handbremse zu lösen. Das OpenSource nicht fehlerfrei ist hast du ja schon mitbekommen.

  • artemis
    Verifiziert
    Beiträge
    26
    • 15. November 2014 um 10:06
    • #10

    Hallo,
    danke für die beiden Links. Hatte bis jetzt nur das "Java ist auch eine Insel" von den Openbooks von Galileo gelesen. Optimierungen werde ich aber erstmal nicht durchführen. Also nicht in so fern, dass ich Teile von den Frameworks umschreibe oder ersetze. Dafür ist es doch mehr ein Hobby im Moment.
    Die Latenz kommt auch nicht nur durch CPU Auslastung, diese langweilt sich in der VM bei so 5-15% wenn ich die Lautstärke änder. Das größte Problem ist die lange Audiopipeline. Dadurch, dass ich von einer Audiodatei jeden Kanal auf jeden Ausgang routen möchte, live, und mit einer eigenen Lautstärke pro Ausgang, muss ich die Kanäle splitten, anpassen und wieder mixen. Bei zB. drei Kanälen und sechs Ausgängen werden es so 18 parallele Pipelines. Die müssen alle wieder zusammengefasst werden. Das ganze funktioniert im Moment nur durch ein paar Queues, die aber buffern und so... Die Lautstärkeelemente sind weit vorne in der Pipeline, daher dauert es etwas, bis sich Änderungen bemerkbar machen. Das PLAY, STOP, PAUSE usw. nahezu direkt reagieren liegt daran, dass die Pipeline schon vor dem Starten gefüllt wird und daher nur das letzte - das Outputelement - reagieren muss.
    Also werde ich erstmal da ansetzen und die Pipeline optimieren bzw. kürzen. Da geht noch was :)

    Zitat von "marcoboy"

    Die Soundkarte läuft weil sie als Standard Audiocore läuft. So läuft sie auch unter anderen System ohne Treiber. Wer mehr will braucht den Treiber dazu.


    Was meinst du denn mit "mehr"? Die Soundkarte läuft unter Linux mit den ALSA Treibern. Welcher genau, weiß ich gerade nicht. Extrafunktionen hat das Ding nicht. Ich kann alle Funktionen nutzen. ALSA ist auch nicht das Problem, kann man aber auch optimieren.

    Du hast natürlich schon recht. Wenn ich eine Latenz im zweistelligen oder einstelligen ms Bereich wollte, müsste ich auch an den von dir genannten Stellen ansetzen. Aber zur Zeit ist das für uns zum Glück nicht notwendig...

    Bis dann,
    artemis

  • hermste
    Profi
    Reaktionen
    9
    Beiträge
    925
    Marktplatz Einträge
    2
    • 15. November 2014 um 18:54
    • #11

    Also ich gratuliere zu der Software.
    Verstehe ich es richtig, dass du/ihr das selbst programmiert habt? Wenn ja, Respekto grande! Würde ich auch gerne selbst können. - Sieht toll aus.

    Im Internet wird sowieso alles sofort schlecht geredet - in diesem Fall, wenn ich deine Screenshots sehe, kaum zu fassen.
    Habe ich es richtig in diesem Diskussionfaden gesehen, dass sich noch keiner positiv geäußert hat?

  • tufkamar
    Gast
    • 15. November 2014 um 19:01
    • #12

    naja, die meisten waren erst mal damit beschäftigt, dem Standard-Stänkerer Paroli zu bieten :)

    Ich wäre an dem System zum mal testen durchaus auch gerne interessiert - und ich bin mir sicher, wenn das Ding als OpenSource irgendwo stehen würde und der Community zur Verfügung stehen würde finden sich sicherlich auch Leute, die da mitarbeiten und weiterentwickeln würden - wobei das natürlich im Falle eines solchen Spezialanforderungsproduktes durchaus immer ein wenig diskussionswürdig ist, in wie weit das denn konkret wünschenswert wäre...

  • marcoboy
    Verifiziert
    Reaktionen
    190
    Beiträge
    6.814
    Marktplatz Einträge
    3
    • 16. November 2014 um 10:15
    • #13

    Das dumme ist nur das ich auch wirklich Ahnung davon habe auf was er sich dort einlässt :wink:

    Vieles Scheitert eben was es sich nicht einfach anwenden lässt. Ein Projekt was nur mit einer speziellen Umgebung funktioniert ist so etwas.
    OpenSoure heißt ja nicht zwangsläufig Linux.

    Meine Erfahrung ist das die Entwickler mit großen Elan an das Projekt heran gehen und dann sich das mit der Zeit verliert. Man findet "OpenSource" genug Code Stücke nur wenig Projekte wo sich dann mehre finden um dies weiterzuentwickeln.

    Im Grunde ist es kein Problem unter Linux Hardware anzusprechen, nur hilft das wenig wenn man nicht weiß welche Register man ansprechen muss. Hersteller geben ihr wissen gar nicht oder nur unter bestimmten Bedingungen preis. Unter diesen Voraussetzungen Treiber zu schreiben die auch noch mit dem vom Hersteller auf Windows mithalten ist schon sehr schwierig. Selbst mit Unterlagen benötigt man schon Wochen Vollzeit um die Register zu erforschen. So aus Überzeugung heraus ? Wer zahlt das einen ? Hinterher gibt es dann noch kommerzielle Code Spechte die damit Geld verdienen. Alles schon persönlich erlebt, schon komisch wenn das Produkt einen ähnliche Bug besitzt :roll: Ich kenne die Ursache :D

    Ohne Knete läuft leider in unser Welt wenig. Das wirst du dir auch irrend wann fragen müssen wenn du die Zeit zusammenzählst. Auch in Theatern wird durch Eintritt Geld verdient. Wenn das Projekt so weit wäre das es für die breite Masse einen Nutzen hat und sich durchsetzt kommt der Punkt an dem du dir diese Frage stellen wirst. Für wem mach ich das eigentlich ?

  • artemis
    Verifiziert
    Beiträge
    26
    • 16. November 2014 um 11:57
    • #14

    Ich versteh ehrlich nicht, was du damit sagen möchtest :?:

    Bisher hab ich nur geschrieben, dass wir dieses Programm die letzte und die nächste Saison einsetzen werden. Es ist als "Übungsprojekt" gestartet. Damit hat sich das für mich schon gelohnt, hab eine neue Programmiersprache dabei gelernt und meine C Kenntnisse verbessert. Alles weitere wird man sehen.
    Das Projekte irgendwann verschwinden ist klar. Hat nix mit Opensource oder Linux zu tun, und auch nicht mit "Hobby" oder "kommerziell". Da braucht man nur nach Microsoft zu schauen oder Google. Und ich hab noch nicht mal eine Aussage darüber getroffen, ob und wie wir das Programm veröffentlichen würden. Und wenn ich jetzt mit .NET unter Windows programmiert hätte, hätte das nix daran geändert.

    Dann fängst du wieder mit Hardwarenaher Programmierung an. Das hat mit MuTe auch überhaupt nix zu tun und ist auch alles hinreichend bekannt und nix Neues. Sicher, das kann ohne Geld schwieriger werden, da man nicht alle Dokumente bekommt. Aber die einzige "besondere" Hardware, die MuTe braucht, ist eine Soundkarte. Und wie schon geschrieben, werden die meisten von ALSA unterstützt. Und zwar genauso wie unter Windows. Daher würde mich auch interessieren, was genau du mit dem "mehr" in den anderen Post meintest. Linux und die meisten größeren Projekte wie auch ALSA oder GStreamer werden übrigens nicht mehr nur von Hobby Entwicklern entwickelt, sondern über Firmen finanziert. Viele Produkthersteller achten mittlerweile darauf, Treiber für Linux zu ermöglichen. Übrigens ist eine nicht ausreichende Treiberversorgung kein reines Linux Problem. Hab hier einen Stapel Hardware, für welche es keinen Windowstreiber mehr gibt, welche aber unter Linux ohne Probleme funktioniert.

    Das hat aber alles nix mit dem Thema zu tun. MuTe funktioniert - mit Linux als OS. Latenz kann optimiert werden, das liegt aber nicht am Treiber. Dein Text beschreibt bekannte Probleme in der Softwareentwicklung, und dabei recht einseitig gegen Linux / Opensource...

    Bis dann,
    artemis

  • marcoboy
    Verifiziert
    Reaktionen
    190
    Beiträge
    6.814
    Marktplatz Einträge
    3
    • 16. November 2014 um 13:39
    • #15

    Ich will dich davor bewahren dich von Anfang an in eine Sackgasse zu programmieren. Die Dinge die du da versuchst werden im Userspace immer schlecht laufen nie so wie es der vermeintliche Anwender erwarten würde. Wenn das für dich ausreicht ist ja alles super. Mit der Vorstellung hier triffst du teilweise aber auch auf Leute die deine Idee vom Prinzip her interessant finden aber eigene Ideen haben.

    Tja Hersteller arbeiten mit :roll: Hierzu kann ich sagen das Hersteller ganz unterschiedliche Ziele haben wenn sie Linux Support anbieten. Die Treiber sind meist nicht mit sehr viel Elan programmiert. Sie arbeiten gegenüber anderen System er schlecht. Manchmal nicht einmal mit Absicht.

    Einen guten performanten USB Core zu entwickeln ist schon nicht einfach. Es gibt eine Hand voll Firmen die so etwas haben. Die Masse der Soundkarten greift auf Standard Chips zurück. Die Unterstützung dieser Soundkarten beruht meist nur in ihren einfachsten Funktionen. Nach dem Motto "kommt ein Ton raus fertig ist der Treiber" Ohne weitere Informationen ist auch niemand in der Lage das zu verbessern. Er in Gegenteil durch Lizenzmodelle dürfen diese Leute nicht einmal wenn sie wollten dies veröffentlichen.

    Ich will dich nicht entmutigen :wink: Mein Tip ist nur dich mehr mit der Hardware zu beschäftigen auch wie man Sachen im Kernel laufen lässt. Versuch das Projekt zu optimieren und das gleich beim Programmieren. Hinterher ist das schwieriger möglich als wenn man sich gleich Gedanken darüber macht. Sonst landet ein Haufen Code im Mülleimer. Das ist verschenkte Zeit :?

    Das wollte ich dir damit sagen :roll:

  • hermste
    Profi
    Reaktionen
    9
    Beiträge
    925
    Marktplatz Einträge
    2
    • 16. November 2014 um 14:20
    • #16

    marcoboy, du bist wirklich ein eigenartiger Vogel und solltest wirklich an deinen sozialen Fähigkeiten arbeiten.
    Artemis hat weder behauptet, mit seiner Software die Weltherrschaft der Zuspielprogramme zu erobern, weder behauptet, mit dieser Software Geld zu verdienen, noch behauptet, dass er sie als OpenSource-Projekt (oder wie das auch immer genau heißen mag, du wirst mich bestimmt korrigieren) für _irgendjemand anderen_ als sich selbst zur Verfügung zu stellen.
    Und ganz ehrlich: Bei diesem tollen Gegenwind hier im Forum - der - das sollte man nicht vergessen, fast ausschließlich von einem einzelnen Menschen kommt - also ignorieren - würde ich einen Teufel tun und die Software hier irgendjemanden zur Verfügung zu stellen.

    Es ist sein Programm und er kann damit tun, was er will. Auch z.B. nix. Oder den Code löschen. Oder den Code mit dir bestimmt nicht teilen. Oder ...
    Für ein Eigennutzen-Programm sieht das echt toll aus!

    Artemis hat sich vielleicht gedacht, hier ein paar 'Betatester' zu finden - unter diesen Voraussetzungen wird er den Code lieber löschen als das zu tun.

    Ich wäre froh, könnte ich auf so einem Level Audiosoftware programmieren. Und ich hoffe, marcoboy schafft es nicht, artemis' Motivation zu nehmen.
    Welche Programme hast du denn bisher geschrieben, marcoboy? Groß reden kannst du, das wissen wir. Zeig mal!

  • guma
    Moderator
    Reaktionen
    5.263
    Beiträge
    14.912
    Marktplatz Einträge
    6
    • 16. November 2014 um 14:46
    • #17
    Zitat von "hermste"

    Ich wäre froh, könnte ich auf so einem Level Audiosoftware programmieren. Und ich hoffe, marcoboy schafft es nicht, artemis' Motivation zu nehmen.

    DITO !!!

  • nojunk
    Profi
    Reaktionen
    160
    Beiträge
    1.804
    Marktplatz Einträge
    5
    • 16. November 2014 um 16:14
    • #18
    Zitat von "hermste"

    Ich wäre froh, könnte ich auf so einem Level Audiosoftware programmieren. Und ich hoffe, marcoboy schafft es nicht, artemis' Motivation zu nehmen.
    Welche Programme hast du denn bisher geschrieben, marcoboy? Groß reden kannst du, das wissen wir. Zeig mal!

    DANKE!!!

    No, it's not too loud. You're just too old!
    winners have parties - and loosers have meetings
    Technik haben viele - WIR können sie auch bedienen :)

    vu.gif

  • marcoboy
    Verifiziert
    Reaktionen
    190
    Beiträge
    6.814
    Marktplatz Einträge
    3
    • 16. November 2014 um 20:09
    • #19

    Als ich vor Jahren angefangen hab zu programmieren bin ich ähnlich ran gegangen. Man war schon stolz wenn überhaupt etwas funktionierte oder der Compiler ohne Fehlermeldung durchlief. Das Problem der heutigen Zeit ist das Ressourcen in den System massig vorhanden sind. Wo ich anfing waren 32k viel. Entwicklungsumgebungen in dem mal schnell etwas zusammen klickt gab es nicht oder waren extrem teuer. Jeder Pixel musste programmiert werden. Etwas von Grund auf Ressourcen sparend und schnell zu Programmieren kann nicht falsch sein oder ?

    Am Anfang denkt man über so etwas wenig nach. Das rächt sich aber später enorm, dann wenn man in seinen eigenen Code nicht mehr durch sieht bzw. Vorarbeit verwerfen muss weil er sich als nicht verwendbar erweist.

    Guma und andere ich glaube kaum das ihr in der Lage seit diese Anwendung zu installieren und zu starten. Das soll jetzt nicht abwertend zu verstehen sein. Die meisten kennen sich mit dem System gar nicht oder wenig aus. Wir sind ja kein linux Forum :roll: Es muss einfach sein auf fast jeder Hardware laufen, wenn er uns das Projekt schmackhaft machen will. Auch dir kann man nicht erklären das nach 300ms-500ms erst das Sample aus den Lautsprechern kommt. Das macht ein Hardware Sampler mit MIDI um einiges besser.

    Ehrlich würde ich dafür auch einen Hardware Sampler einsetzen. Oder mit e:cue kann man den per MIDI, TCP/IP etc. wunderbar Timecode genau steuern. Wenn es nur ein Stereo Signal ist geht das wunderbar mit den internen Mediaplayern. Auch die Lautstärke kann man in e:cue per macro beeinflussen. Mit Reaper etc. lässt sich bestimmt ähnliches erreichen.

    Ich habe aufgehört meine Arbeit zu veröffentlichen. Da diese auch in meinen Produkten vorhanden ist. Mehrere Vorfälle habe ich lernen müssen das sich nicht nur welche freuen wenn etwas funktioniert sondern das es in ihren Geldbeutel klingelt. Beim Geld hört der Spaß auf auch bei großen Firmen wo dessen Angestellte per copy & paste mal eben was verwenden. Mit dezenten Hinweisen erreicht man den Angestellten nicht sondern nur die Rechtsabteilung die gleich die Kanone mit Kaliber 2m auf dich richtet.

    Ich programmiere meist nur für Hardware, bzw. ich entwerfe die Hardware und dann auch die Software.

    Um mich geht es hier nicht sondern um sein Projekt :roll: Einige Hinweise von mir wurden ja schon aufgegriffen. Ich würde vorschlagen das ganze erst mal zu optimieren bevor neue Funktionen hinzu kommen. Wenn es dort Neuerungen gibt interessiert mich das natürlich auch ;)

  • hermste
    Profi
    Reaktionen
    9
    Beiträge
    925
    Marktplatz Einträge
    2
    • 16. November 2014 um 22:04
    • #20

    Diese Benutzer-Ignorieren-Funktion ist zu schwach. Oder ich bin zu schwach für die Funktion. Brauche da etwas Stärkeres.

    artemis, bitte mach weiter, aber um Himmels willen, schreib' davon hier nix rein. - Meine letzten Worte und mein letzter Blick in diesem Diskussionsfaden.

Anstehende Termine

  • Kombiseminar Sachkundiger für Anschlagmittel und Traversensysteme (AnschlägerPlus)

    Mittwoch, 23. September 2026 – Freitag, 25. September 2026
  • Kombiseminar Sachkundiger für Anschlagmittel und Traversensysteme (AnschlägerPlus)

    Dienstag, 29. September 2026 – Donnerstag, 1. Oktober 2026
  • Sachkunde für Fliegende Bauten

    Dienstag, 29. September 2026 – Donnerstag, 1. Oktober 2026
  • Virtueller Stammtisch im Chat

    Dienstag, 29. September 2026, 21:00 – 23:00
  • PA-Forum Stammtisch LeatCon

    Dienstag, 6. Oktober 2026, 13:00 – 14:00

Letzte Themen

  1. 17. - 18. November | PA Rigging & Truss Safety mit Tom Greber

    Soundchecker
    23. September 2026 um 10:33
  2. 13. - 14. Oktober | Live Mixing Workshop mit Jörn Müller in Köln

    Soundchecker
    23. September 2026 um 10:30
  3. können das hier (Foto) die original Weichen der KMT CS215 / CM215 sein ?

    phattomatic
    23. September 2026 um 09:12
  4. RCF: "Bass Motion Control" vs. "XBoost" => Ähnliche Funktionalität unter zwei verschiedenen Etiketten oder relevante Unterschiede?

    Hanseat
    21. September 2026 um 22:21
  5. Suche Lichteffekt

    Schreddl
    21. September 2026 um 12:22
  6. QLC+4 in MagicQ Visualsieren - wie richtig einstellen?

    metal-shot
    19. September 2026 um 17:44
  7. Verschiedene Verteiler mit Powercon Anschluss bzw. Ausgang kompatibel?

    tenderboy
    19. September 2026 um 12:22
  8. Suche Optocore Spezialisten - trouble shooting eines SANE Verbunds

    georg.h
    19. September 2026 um 10:21
  9. Quick & dirty reverse engineering - wie gehts weiter?

    phlownd
    19. September 2026 um 10:13
  10. DSP Preset für The Box Pro TP218 MKIII

    dxnny074
    18. September 2026 um 15:16
  1. Datenschutzerklärung
  2. Impressum
Community-Software: WoltLab Suite™