Beiträge von Kyle

Wenn ich zeit habe mache ich vielleicht mal eine Grafik was ich mir persönlich unter einem solchen Editor vorstellen würde. Einfach den Begriff "node editor" hier reinzuwerfen ohne das genauer zu spezifizieren war vielleicht etwas ungeschickt von mir, so kann man natürlich keine sinnvollen Diskussionen führen.

insgesamt würde es etwa in diese richtung gehen.
http://code.blender.org/wp-con…node_group_interface4.png
Jetzt denkt man natürlich nach einem flüchtigen blick sofort "das wird doch direkt viel unübersichtlicher als der bisherige mixer, wenn man erstmal 100 solcher nodes braucht". Der entscheidende unterschied zum Patcher ist hier allerdings, dass sich viele Nodes nach belieben zu einer Node gruppieren lassen. Ein weiterer großer Vorteil ist, dass man Parameter auf die Außenansicht des Nodes legen kann, und sie somit direkt im Node-Editor verändern kann.
Man kann auch Inputs und Outputs von eigenen Node Gruppen (die am ende nurnoch Kompakt als einzelne Node angezeigt werden) selbst definieren und benennen. Außerdem kann man Node-Gruppen als Presets speichern etc etc...

Was alles davon für Audio Produktion sinnvoll ist muss man natürlich dann nochmal im detail anschauen. Am liebsten würde ich es selbst ausprobieren, jedoch kann man (bzw ich) das nicht mal eben runterprogrammieren.
Vielleicht kennt hier jemand auch eine DAW die das schon längst umgesetzt hat.

Ok also der Konsens ist: alle hassen parameter gewirr und kompliziertes Routing. Man will die parameter direkt da haben und nicht erst in 100 fenstern danach suchen. Man will kein Routing machen, das so unflexibel ist, dass kreative ideen dadurch blockiert werden. Man will nicht tausend Stunden mit der Projektstruktur verbringen, der Fokus sollte beim Musik machen liegen. Projektstruktur sollte nur ganz kurz ein Thema sein.
Kurz gesagt:
Alle wollen den Node-Editor ;D Denn sonst wäre es ja nur malen nach Zahlen.

Ich würde jetzt gerne mal technische Gegenargumente hören, oder konkrete use-cases in denen ein Node Editor tatsächlich einen hauch schlechter ist.

Also dass es auf massive Zweckentfremdung rausläuft dachte ich mir schon.
Dass FL uns da irgendwelche möglichkeiten bietet das routing der Tracks zu kontrollieren kann ich mir so garnicht vorstellen. Ist ja nicht so als wäre FL mit rücksicht auf Entwickler geschrieben worden.

Im Grunde bräuchte man ne eigene DAW, nur die zeit für das ganze drumherum mit bouncen, Hardware kommunikation und Piano Roll wäre halt verschwendet, weil wir da ja nichts ändern wollen.
Deine Gott VST idee wäre da auch so das erste gewesen was ich für realistisch hielt. Ist halt schade dass man so wenig kontrolle über die DAW hat dass man dann die ganze arbeit selbst machen muss, wenn man so eine kleine änderung einbauen will.
Die idee mit dem Node Editor in der DAW bleibt wohl eine Idee.

Um diese Diskussion in eine Konstruktivere Richtung zu lenken:

Welche der Angestrebten Funktionalitäten und Workflow-Veränderungen wären denn anhand eines VSTs möglich?
Was erlaubt uns die VST Schnittstelle, und wieviel können wir damit schon erreichen, wenn wir in kauf nehmen dass das FL Projekt speziell auf die Arbeitsweise mit diesem VST ausgerichtet wird?
Kann man ein solches Konzept VST so entwerfen, dass es auch in anderen DAWs Sinn macht?
Wie hoch wäre der Aufwand wenn man die Programmierung einer grafischen Benutzeroberfläche mal außen vor lässt?

Dieses "bis ins kleinste Detail planen", ist das was man momentan machen muss, und was ihr alle macht. Das kann man in tausenden von threads hier im forum nachlesen. DAWs sollten uns diese Arbeit abnehmen und uns ermöglichen kreative entscheidungen zu treffen, ohne erst 3 minuten lang neu zu routen.

Wenn man also dafür sorgen will, dass man kreativ arbeiten kann, ohne ständig von solchen technik hürden unterbrochen zu werden, dann muss man vorher sein Projekt planen. Ich glaube das ist es was x42 dazu getrieben hat solche routings zu erstellen.
Hätte man einen Node-editor, dann würde deise Planung on the fly stattfinden und alles wäre automatisch ordentlich, bzw man könnte viel leichter nachträglich Ordnung schaffen.

hervorragender post x42. Genau diese problematik hat bei mir dazu geführt dass ich irgendwann keine projekte mehr fertig bekommen habe und aufgehört hab musik zu machen.

In der informatik gibt es diese wundervollen Paradigmen die sich 1 zu 1 auf Audio Produktion übertragen ließen, wenn die DAW dazu im Stande wäre. Das würde dazu führen dass man viel mehr kontrolle über seinen Sound hat, und weniger auf gut glück erstmal alles zusammenschmeißt, und dann nur das fixt was so kaputt ist, dass man es hört. Es würde sonst nämlich einfach zu viel Zeit verloren gehen.

Wenn ich mir Videos von professionellen Leuten im orchestralen Bereich ansehe, dann versuchen die jedes mal diese Kapselungen irgendwie mit geschickter namensgebung oder sonstwas hinzubekommen. Das artet dann schnell aus. Manche Leute brüsten sich sogar mit der Anzahl der Mixer-Inserts die sie verwenden, was wie ich finde ein deutlicher Ausdruck dieses Problems ist.

Was man bräuchte wäre eine DAW auf basis eines Node-Editors der mächtiger ist als Patcher. Im Grafikbereich hat dieser Umbruch übrigens längst stattgefunden, seit Node-Editoren in fast jedem 3d programm vertreten sind ist es für hobby-Modellierer problemlos möglich 3d Bilder in Pixar-Qualität zu erzeugen. Man kann seitdem einfach Artist sein ohne großartig technisch versiert zu sein.
DAWs machen meiner Meinung nach die Audio Produktion komplizierter als sie ist, ich habe aufgehört mit FL studio zu arbeiten, weil es bei Image-Line nicht üblich ist dass große innovatve Änderungen stattfinden (korrigiert mich bitte wenn ich falsch liege).
Schon der wechsel zu 64 bit hat so lange gedauert, dass ich glaube dass Image-Line intern selbst nicht mal weiß wie man "wartbaren code" erstellt, und deshalb diese ganzen Programmier-Paradigmen garnicht kennt.

um zur Frage zurückzukommen:
Nein, du bringst nicht zu viel Berufsleben in die Audio-Welt. Die Audio-Welt ist einfach noch nicht so weit wie die Grafik/Film-Welt, aber das wird noch kommen, weil es einfach so offensichtlich die bessere Lösung ist. Früher oder später kommen alle Innovationen aus der Informatik bei den Künstlern an, das war schon immer so.

Zitat von Jedec

Wenn man normalerweise etwa 1m von seinen Boxen entfernt sitzt, kann man nochmal etwa 30ms weniger Latenz rausholen, wenn man einen Kopfhörer aufzieht :wink:

Rechne mir das bitte nochmal vor. Ich komme auf 2,914 ms, da würde deine Aussage stark an Gewicht verlieren.
wenn 1 meter 30 ms Verzögerung bewirken würde, dann hätte man bei 100 metern schon 3000 ms = 3 ganze sekunden Verzögerung. Da wäre Jodeln als Kommunikationsform doch unvorstellbar, oder?

Zitat von Don Marco

es gibt keine mac version von fl, für mac gibts logic ist aber auch nicht besser als fl

EDIT:
Image Line arbeitet zur Zeit an einer nativen OSX Version

Zitat von maniac01

, was so nah am Prozessor und Arbeitsspeicher arbeitet,

Kannst du das ein bisschen genauer erläutern was du damit meinst? Ist bei einem nicht-seperaten system keine prozessornähe gewährleistet? bzw was bedeutet "nah am Prozessor"?

Zitat von Tallahassee

http://melomics.com/@iamus/breaking

Das ist doch nur ein bisschen Geklimper/Gedudel. :wink: Und sogar das ist im Prinzip menschengemacht, weil die Algorithmen vom Menschen sind.

Ich glaube, es dauert noch etwas, bis sich das gut anhört. Und ob die Qualität/Kreativität der PC-Musik jemals an "echte" Musik heranreichen wird, kann man anzweifeln.

naja da muss man sich natürlich den midi-synthesizer wegdenken, und sich ne gute produktion/mix drüber vorstellen. Da muss ich dann zugeben dass ich von leuten hier im forum schon viel schlechteres gehört hab.
Wann ist denn deiner meinung nach die musik wirklich von der maschine? wenn der Algorithmus für den Algorithmus für den Algorithmus für den Algorithmus ... vom menschen ist? Nun ja dann ist es über ecken wieder vom Menschen gemacht. Das ist denk ich bei maschinen grundsätzlich so, da sollte man sich nicht künstlich eine hürde denken um die eigene moralvorstellung vom "Menschen als Krone der Schöpfung" krampfhaft beibehalten zu können. Wenn ihr (egal wer von euch) komponiert dann läuft in eurem kopf auch nur ein Algorithmus ab, aber wenn eben dieser Algorithmus von einer Maschine ausgeführt wird, dann zählt es nicht, oder was?

Ich finde das Thema sehr interessant, da ergeben sich dann eventuell interessante dinge für Videospiele, zb. in Echtzeit komponierte melodien, die dynamisch auf die situation im Spiel reagieren. Mal sehen was die Zukunft da so bringt.

Zitat von Master Exploder

Dachte eher so 'ne Seite, wo ich 'n Logo hochlade und jemand der 'n Logo braucht, geht dann halt auf die Seite und guckt die Logos durch. So ähnlich wie die schon geposteten Seiten bloß ohne Bindung zum Auftrag. Naja, ist ja auch erstmal egal.

Ich bezweifle dass du sowas findest. Logos sind so das Maßgeschneidertste was es überhaupt im Grafikbereich zu machen gibt, also wirst du da wohl immer direkt mit den leuten kommunizieren müssen.

Auf deviantart gibts doch die möglichkeit prints zu verkaufen? Vielleicht habe ich deine Frage auch falsch verstanden.

Das Koan Sound Wallpaper entspricht ja wirklich allen regeln der Kunst. Da ist Kantenglättung, konsequente Palette, definierte Vektorkanten, Seitenverhältnisse und Stil-echtheit alles Top.
Ist das Bild vollständig, mitsamt der Texturen die du da ausgeblurt hast, selbsterstellt?

Das Lana Del Ray bild ist zwar auch gut, allerdings nicht so perfekt wie das Koan Sound.
Die Kanten sind mir diesmal nicht klar genug... es erinnert an ein hochskaliertes Raster-dreieck, bei dem nochmal linear oder kubisch interpoliert wurde, wodurch eine leichte unschärfe entsteht. Diese ist zwar in nuancen auch im Koan Sound schriftzug zu erkennen (dort wohl eher Multisampling), hier ist sie allerdings etwas zu präsent. Vielleicht ist der effekt auch nur einbildung aufgrund des Schlagschattens von der oberen kante. Diese violette/rote plasma-feuer artige textur ist ein wenig over the top... du könntest sie verwenden wenn du ihr etwas weniger kontrast gibst, oder die textur als solches im äußersten dreieck in dem sie zu finden ist mit einem Blur versiehst.
Problematisch an der Dreiecksform finde ich, dass rechts und links die großen freiräume entstehen, wo oben keiner ist. Da würde ich einfach das bild verkleindern und nach unten ziehen damit oben drüber auch noch raum entsteht.
Insgesamt sehr gute arbeit.

EDIT: Omfg konnte ja nicht ahnen dass das so ausartet

-kann den post nicht löschen

schon in ordnung.
ne ich hab nie Visual Basic programmiert, hab auch noch nie nen visual basic game gesehen.

Zitat von FrE4K_

Nein oder ? Ich benutze MonoDevelop und ich hab gesagt ich könnte ihn so ein tip geben. Aber nur in java. Villeicht weis er dan wie er das in sein script umwandeln kann -.- naja is ja jetzt auch scheiß egal

Dass du MonoDevelop verwendest impliziert nicht dass die Klassen und vor allem Objektnamen die du gewählt hast so existieren.

Davon abgesehen: den code
if (a == b) {
c = "hi";
}
in VB umzuwandeln sollte hoffentlich jeder VB programmierer können, solange er den Java syntax halbwegs kennt. das gibt dem code auch noch keine bedeutung.
Du hast natürlich recht, dass das egal ist weil es nichts mit der Thread-Frage zu tun hat. Wir sollten die diskussion deswegen hier abbrechen.

Zitat von FrE4K_

Hast du schonmal was von verschiedenen programmier umgebungen gehört ?

ja, aber du scheinbar nicht.
Was du meinst ist keine Programmierumgebung sondern eine API oder Ähnliches.
Eine Programmierumgebung ist nämlich eine IDE wie MS Visual Studio oder Eclipse.

Zitat von FrE4K_

Ich wollte dammit sagen das....Die wand einen hit.collider braucht.

mmmh… das ist streng genommen quatsch.

Zitat von FrE4K_

Wie merkt das gameobject den collider ?

Ganz einfach if(hit.collider = tag) das gameobject kriegt es durch ein tag raus den man festlegen kann. Also : trifft das gameobject den tag "Wand" z.b dan printed er "Du hast die wand getroffen" Hoffe das wahr besser

nein. er printed "hi". Wenn man "hi" auf "Du hast die wand getroffen" ändert, dann printed er das. Und dass er überhaupt etwas printed ist reine Spekulation.

Du missverstehst die Situation komplett. Dein Code enthält keinerlei Aussage. Und was du erzählst ist keine Erklärung und ist sogar in sich verkehrt.
Zurück zu den Grundlagen:
hit, collider und tag sind wenn du wirklich in Java unterwegs bist in jedem Fall Objekte oder Standard-Datentypen. In diesen Begriffen steckt für uns keinerlei Information, weil sie ja nur Namen von Repräsentanten einer Klasse sind, auf deren Definition und Deklaration nur höchstens du Einblick hast. Und das auch nur solange du nicht eine vollständig unsichtbar weggekapselte API verwendest (wovon ich mittlerweile ausgehe, wenn ich sehe wie du hier deinen Code präsentierst). Selbst wenn du uns sogar die Deklarationen von jedem einzelnen deiner tollen Objekte zeigen würdest, dann könnten wir hier nur Mutmaßungen anstellen was es damit auf sich hat.
Dein Code ist kein "Tipp".
Um es nochmal deutlich zu machen:
Die eine Game Engine von den unzähligen Spiele Engines die es da draußen gibt, die du da zufällig erwischt hast (ich unterstelle dir jetzt einfach mal dass du sie nicht selbst geschrieben hast), enthält irgendwelche vollkommen willkürlichen Klassennamen und -definitionen. Davon heißt halt eine zufällig "GameObject" und hat zufällig ein sogenanntes "hit" attribut (und das nur, falls du dich überhaupt in der GameObject-Klasse befindest was wir ja auch nicht wissen können). Und dieses "hit" Attribut hat irgendein Attribut namens "collider", wer wahrscheinlich in irgendeinem update zyklus mit werten belegt wird oder irgendsowas. Die Funktionen von all diesen begriffen sind vollkommen spezifisch für deinen speziellen Anwendungsfall, und es grenzt an Wahrsagerei wenn wir hier versuchen in deinen Code irgendetwas hinein zu interpretieren.

es ist als würde ich sagen:
"Mhm ich kenn mich da nur mit Objective-C aus. Aber ich könnte euch so ein Tipp geben. du brauchst ein WorldThing Interface mit nem detectCrash wie diesem hier:

- (id) detectCrash:(CrashEvent*)event:(CrashFlag*)flag {
Crash* c = [[Crash alloc] initWithCE: event];
while([c incrementFlag] != flag)
if ([c currentFlag] == [c lastFlag]) {
[c release];
return NO
};
[c release];
return YES;
}"

In diesem code wirrwarr steckt nicht der hauch einer information über das was da wirklich passiert, obwohl er in meinem kontext durchaus funktionieren kann.
Ich hoffe das ist jetzt klar.

Zitat von FrE4K_

Mhm ich kenn mich da nur mit java aus. Aber ich könnte euch so ein tipp geben . Also bei meiner programmier umgebung machen wirs soo.

If (hit.collider == tag)
{

print = "hi";

}

Alles anzeigen

Dieser Post ist auf so viele arten unsinnig. Nicht böse gemeint (!), aber es erfordert schon viel Interpretierarbeit um überhaupt rauszubekommen was du vielleicht gedacht hast uns an information geben zu können.
Wenn man jetzt alle Fantasie benutzt die man zur Verfügung hat, dann liest man, dass du hier in einer Umgebung arbeitest, in welcher es scheinbar eine Klasse gibt die in jedem Simulationsschritt Instanzen ihrer selbst auf maximal eine kollision prüft (wegen dem collision attribut). Dieser werden dann irgendwo je nach kollisionpartner verschiedene tags zugewiesen. Der Schritt, der für chaos! jetzt eventuell interessant sein hätte können (er wäre es nicht) ist, wie diese Kollision überhaupt festgestellt wird. Dein Code ausschnitt beinhaltet keinerlei verwertbare Information.

@chaos!
Es ist ungewöhnlich ein Spiel in Basic zu schreiben. Wenn du in einem Programmierforum einen Thread eröffnest, dann gib auf jeden fall mehr information zu deinem Game und dessen Aufbau. Sonst sind die ersten antworten immer "zeig erstmal deinen Code". Dein Anfangspost gibt nämlich so gut wie garkeine Auskunft über das eigentliche Problem, wodurch ungenaue, schwammige, unkonkrete Antworten das einzige sind, was man dir überhaupt geben kann.

Wenn eure Programmierer sich da viel mühe geben wollen, können sie auch über die iOS Core Audio API/ OpenAL den Sound abhängig davon, ob Kopfhörer eingesteckt sind oder nicht, mit beliebigen AU Plugins noch live verformen. So könnte man die musik auch dynamisch aufs game anpassen (zB. wenn der spieler getroffen wird kurz einen highcut auf die Musik draufmachen etc...). Bei der WWDC 2012 war da glaub ich ein sehr gutes Video drüber dabei, wo sehr ausführlich beschrieben wird wie man die API benutzt, falls euch das interessiert.

Ich habe mal mit einem Kumpel ein Android Spiel gemacht wo man im weltraum so punkte einsammeln musste, und immer wenn man einen eingesammelt hat, kam ein Sound in ner Tonhöhe die immer zum aktuell in der Hintergrundmusik laufenden Akkord gepasst hat. Mit solchen spielereien kann man Sehr viel Atmosphäre rausholen und das game nochmal richtig pushen. Kann ich wirklich nur empfehlen sich da viel mühe zu geben!

Bei MacOSX ist die Ordnerhierarchie sogar sehr strikt vorgegeben. Leider gibt es zur Zeit immer mehr Entwickler die zuerst für Windows programmiert haben und dann einfach auf MacOSX portieren, ohne die regeln der Ordnerstruktur einzuhalten. Ich habe mir zB. neulich Ohm-Studio runtergeladen, um es mal kurz anzutesten und stelle fest, dass es einen Installer hat. Ein Installer ist bei MacOSX äußerst unüblich, weil da der User nicht weiß wohin überall Dateien reininstalliert werden. Und der Oberhammer war, dass sie nicht mal einen Deinstaller dazugetan haben. Stattdessen eine unvollständige liste von Dateipfaden wo man die Dateien dann schön selbst rauslöschen muss.
Gut.. Solche exoten gibt es bei Windows bestimmt auch, aber bei MacOSX ist es üblich, dass es weder installer noch deinstaller gibt und die programme portabel in einem .app archiv einfach auf die Platte kopiert werden (Man muss dazu sagen dass Ohm studio wahrscheinlich so tief ins system eingreifen muss für die Audio Performance, dass es sich zwingend tiefer ins System integrieren musste).
Als ich umgestiegen bin von Windows auf OSX hab ich die Handhabung von Dateien etc. erstmal nicht wirklich verstanden und schnell war alles ein riesen Durcheinander. Wenn man es dann endlich mal verstanden hat kann man auch richtig ordentlich damit arbeiten.
Der Dateiverwaltungsaufwand ist bei MacOSX dann deutlich geringer. Man öffnet nur sehr selten den Finder (Windows Explorer "äquivalent") und mir kam es so vor, dass man auch aufgrund anderer Faktoren einfach viel mehr Zeit zum produktiven Arbeiten hat.
Ich würde keinem Windows user momentan dazu raten auf MacOSX umzusteigen, weil sich erst rausstellen muss wie gut Windows 8 ist. Wenn Win8 aufholt und dann etwa gleichauf mit OSX 10.8 ist, dann sollte man sich eher Windows 8 holen, weil der umgewöhnungsaufwand sonst einfach zu groß ist.