Apple wirklich sinnvoll?

  • Ersteller Maid-Majoran
  • Erstellt am
Status
Für weitere Antworten geschlossen.
Es ist ein erster Test.....

Mein Gott, Du brauchst Dir doch nicht beweisen, dass Du mit Deinem Mac zufrieden bist.
Ich bin mit meinem übrigens auch zufrieden, ohne dass ich mir Dein Testfile runterladen muss. (Das würde auf meiner Möhre vermutlich nicht laufen ...)

Aber was hätte ich davon, wenn ich wüsste dass mein Mac besser ist, als der PC von UserXY? Nix.

Und fehlt mir was, wenn irgendjemand sagt, dass sein PC besser ist als meine Möhre? Auch nicht. Mein System funktioniert deswegen keinen Deut schlechter.

Also seh' diese Diskussion etwas gelassener. ;)

Clemens
 
Ich beweise mir damit gar nichts - ich gebe lediglich einen Vergleich vor.
Das Einzige was mir manchmal etwas auf den Senkel geht, ist diese ewige (oft gar völlig unbegründete) Besserwisserei gegenüber Mac-Usern und deren Erfahrungen. Aber ich sehe das ebenfalls viel gelassener als von Dir mir gegenüber vermutet ;)
 
Ich beweise mir damit gar nichts - ich gebe lediglich einen Vergleich vor.

Einen, mit dem man auf anderen Macs dein Ergebnis verifizieren kann. Das ist NICHT der Start eines Vergleichstests, von dem du behauptet hast, du würdest ihn gerne machen ;)


Das Einzige was mir manchmal etwas auf den Senkel geht, ist diese ewige (oft gar völlig unbegründete) Besserwisserei gegenüber Mac-Usern und deren Erfahrungen

Du musst jetzt ganz stark sein:
Es gibt einen Haufen Leute, die beides verwenden - ich gehör dazu.
 
Aber ich sehe das ebenfalls viel gelassener als von Dir mir gegenüber vermutet

Wenn Du es jetzt noch schaffst, nach aussen so gelassen zu wirken, wie Du das siehst, .... ;)


Es gibt einen Haufen Leute, die beides verwenden - ich gehör dazu.

Du Sünder! Bete von nun an dreimal täglich zum Hl. Steve! :hammer:
 
Du Sünder! Bete von nun an dreimal täglich zum Hl. Steve!

Lieber nicht, sonst rutscht mir die Windows-Sache noch raus und er installiert mir remote Mountain Lion.
 
Ich beweise mir damit gar nichts - ich gebe lediglich einen Vergleich vor.

Einen, mit dem man auf anderen Macs dein Ergebnis verifizieren kann. Das ist NICHT der Start eines Vergleichstests, von dem du behauptet hast, du würdest ihn gerne machen ;)

Ich kann schlecht ein Windows-kompatibles File posten, wenn ich hier keinen Windows-Rechner mit DAW am Start habe. Jeder Windows-Benutzer kann sich aber mit Zebralette von U-He mein Setup nachbauen. Deshalb Zebralette - ist als AU/VST auf Mac, oder als VST für Windows basierte DAWs gleichermassen erhältlich und kostenlos. MeinFile ist in der Tat nur für Mac-Rechner gedacht und diente damit höchstens als Beweis für meinen durchgeführten kleinen Test......und einem weiteren MacUser zum Vergleich (sofern er mitmachen mag), schliesslich schluckt ein möglicher Quadcore Rechner einige Instanzen mehr als mein kleiner MacMini oder mein 2009er MBP

PS: Von einem Fanboy bin ich ganz ganz weit entfernt - dazu kannst Du mich gerne einmal "googeln"
 
@ Kickback: *schäm* stimmt - ich Vollidiot....
smil46e484310966a.gif


Nun ja, noch ist nicht aller Tage Abend.....

http://www.pacocasanovas.ch/test.mid
 
meine vermutung ist die shell ist nicht nur für die verwaltung, sondern eine art wrapper mit der sie relativ einfach plattformübergreifend coden können.

Jep, das meinte ich mit Verwaltung. Ich habe mal vor Urzeiten mal das SDK für Shell-Plugins gesehen, das Steinberg damals mehr oder weniger exklusiv für Waves aufgelegt hatte. Im Prinzip beschrieb das die I/O-Funktionen und die Parameterdefinitionen für Automation (wenn ich mich noch richtig erinnere, ist wirklich ziemlich lange her). Damit können sie für die wichtigsten Verbindungen zur Außenwelt quasi überall andocken, wenn sie mal eine Shell dafür haben.

Die GUI gehörte aber AFAIK schon nicht mehr dazu. Das war ein sehr schlankes Interface, was eigentlich nur Parameter- und Variablennamen übersetzte.

Performance kostet das wenig bis nichts, die wird dann doch wieder von der eigentlichen Plugin-API gefressen - ob nun AU, VST oder RTAS.
 
Warum macht denn nicht einer der Mac-User hier einfach mal den Vergleich Logic vs. anderer Sequencer?
Dann kann man doch sehen, ob Logic mit AU bei niedrigen Latenzen die selben Probleme wie andere Hosts unter OSX hat oder eben nicht.
 
sollte man sich nicht viel eher fragen, warum auch alle anderen crossplattformhosts sich ähnlich verhalten?

dont you see the pattern here? (wie der franzose sagt)

ich glaube schon ein Muster sehen zu können - weil Crossplattform-Hosts auf Grund Ihrer Architektur die von Apple bevorzugte API für Echtzeitaudio-Effekte alle nur mittels ihren Adaptern benutzen (nicht mit einem Umwandler, Danke nochmals an Rainer Hain für diese Korrektur).


sowie fast alle crossplattform-plugins, wie du schreibst. und das ist dann halt der springende punkt: am ende des tages interessiert es halt niemanden, ob dein rechner jetzt von einem einzelnen plugin dass du finden konntest 10000 stimmen polyphonie machen kann - was interessiert ist, wie die performance in einem typischen alltagssetup aussieht, und da hast du dann eben meistens den üblichen mix von bisschen waves hier, bisschen native instruments dort und so weiter und so fort. es hat schon seinen grund warum sowohl im nuendoforum als auch bei seiten wie dawbench (gibt noch einige mehr davon, google is your friend) meistens die benchmarks aufgeschlüsselt werden in "monothematische" aber eben zusätzlich auch "repräsentative" projekte. und es sind gerade auch diese benchmarks, in denen OSX halt durch die bank schlechter abschneidet, auch wenn dus so erkennbar nicht wahrhaben willst ;) ob das dann daran liegt dass OSX bisschen bloated ist dieser tage oder einfach die ganze welt nicht anständig für OSX programmieren kann oder will, ist ja letztlich für den user wurscht - was zählt ist, was hinten rauskommt, wie einst ein kanzler mal so schön sagte ;-)

ich arbeite auch im alltag mit beiden systemen und habe nach jahren des direkten vergleichs keinen grund warum ich sämtlichen nuendousern (mac wie pc usern) sowie allen professionellen benchmarkseiten eine synchron veranstaltete anti-apple-verschwörung unterstellen sollte ;) ziemlich alberner gedanke. du hingegen beginnst deinen test schon mit einer sehr klaren agenda sowie einem deutlich realitätsferneren testaufbau. kein guter tausch.

zuguterletzt: die abletonsessions mit denen wir live arbeiten kommen komplett ohne plugins aus - da geht es nur um streaming und caching, und auch da spielt das macbook pro sessions die auf dem pc mit 3-6ms laufen nur noch mit 20ms latenz ab. also nur an den plugins kanns offensichtlich auch nicht liegen.

wohlgemerkt ist das letztgenannte beispiel das einzige, bei dem das wirklich eine absolut reale konsequenz hat die die musikalische freiheit einengt. bis ca. 10ms würde nämlich unser drummer es noch hinbekommen, samples in echtzeit zu triggern und halt durch flam-spielweise die latenz "analog" zu kompensieren. aber 20ms wirft einen dann halt doch langsam böse aus der bahn, also lässt ers bleiben.

in nahezu allen anderen fällen ist das heutzutage eine eher theoretische diskussion, weil unterm strich einfach alle guten rechner für so ziemlich alle denkbaren anwendungen genügend leistung bringen. ich finde diese info geht hier grad ein bisschen unter vor lauter "neindasdarfnichseindassOSXnichganzsoperformantwiewindowsistdamusseseinenanderengrundgebenandemapplenichtschuldist" :)
 
@ Kuno: Siehe meine Beiträge.....

(Ich muss nun noch ne Runde arbeiten, bis später....)
 
Warum macht denn nicht einer der Mac-User hier einfach mal den Vergleich Logic vs. anderer Sequencer?
Dann kann man doch sehen, ob Logic mit AU bei niedrigen Latenzen die selben Probleme wie andere Hosts unter OSX hat oder eben nicht.


m.w. performt logic bei niedrigeren latenzen in der tat einiges besser, ist allerdings komplizierter zu vergleichen weil logic (zumindest in kombination mit mancher hardware) so nen dualpuffer-ebenen-ansatz zu fahren scheint, bei dem scharfgeschaltete spuren mit weniger latenz reagieren können als playbackspuren - habs selber nicht in aktion erlebt (gottseidank sind alle studios in denen ich arbeite entweder auf nuendo oder protools umgestiegen, ich bin nicht unbedingt ein fan von logic ;) aber so erzählt mans sich. also wohl vergleichbar mit samplitude. auch dort gibt es mehrere pufferebenen und du kannst in einem riesigen mix eine spur mit minimallatenz ansprechen, während alle anderen spuren die grad nur playback machen mit einer latenz bis annodazumal laufen können und so performance sparen.
in der praxis ne SEHR feine sache, und auch einer der wenigen verbleibenden punkte auf meiner persönlichen steinberg-wunschliste. führt aber natürlich wenn man nicht aufpasst schnell zu aussagen wie "ich kann bei 1ms latenz nen kompletten mix fahren der anderswo 20ms latenz braucht", wo potentiell aber tatsächlich alle spuren mit hoher latenz laufen ausser der einen. insofern, wenn man rausfinden will ob AU/CA tatsächlich performanter ist als VST/ASIO muss da für meinen geschmack schon ein kompetenter tester ran der alle rahmenparameter kennt und weiss wie man sauber die faktoren einzeln isoliert und analysiert - sonst testet man nur den alltagsvorteil des dualpuffer-features (den niemand bestreitet) an sich und weiss immer noch nix über die realen performanceverhältnisse.

gerade auf dawbench meine ich mal gelesen zu haben dass er irgendwann sich des themas auch mal annehmen möchte, und so differenziert wie der auch sonst rangeht wäre das für mich persönlich erste wahl.
 
Ich glaub Du verstehst hier etwas grundlegend falsch: Latenz setzt sich aus der Summe von fünf zeitlichen Portionen zusammen.

1. AD Konverter Latenz
2. Input Portion des I/O Buffers
3. Audio-Treiber Latenz
4. Output Portion des I/O Buffers
5. DA Konverter Latenz

Du redest davon die Input- und Output Portionen des I/O Buffers getrennt einstellen zu können. Bei einem Audio-Instrument oder beim reinen Playback nutze ich logischerweise nur die Output Portion......der CPU Verbrauch wird dadurch aber nicht verbessert. Wenn ich einen Performance-Gewinn möchte, kann ich die jeweiligen Spuren beim Playback selektiv "freezen" (sie spielen dann von einer temporär generierten Audio-Datei und belasten die CPU nicht). Das habe ich bei meinem Test allerdings nicht getan......
 
Ich glaub Du verstehst hier etwas grundlegend falsch: Latenz setzt sich aus der Summe von fünf zeitlichen Portionen zusammen.

1. AD Konverter Latenz
2. Input Portion des I/O Buffers
3. Audio-Treiber Latenz
4. Output Portion des I/O Buffers
5. DA Konverter Latenz

Du redest davon die Input- und Output Portionen des I/O Buffers getrennt einstellen zu können. Bei einem Audio-Instrument oder beim reinen Playback nutze ich logischerweise nur die Output Portion......der CPU Verbrauch wird dadurch aber nicht verbessert. Wenn ich einen Performance-Gewinn möchte, kann ich die jeweiligen Spuren beim Playback selektiv "freezen" (sie spielen dann von einer temporär generierten Audio-Datei und belasten die CPU nicht). Das habe ich bei meinem Test allerdings nicht getan......

Lass' es mich vorsichtig formulieren: Der Derek ist schon vom Fach, der braucht jetzt nicht wirklich Nachhilfe von Dir ;)

Was er meint und was Du offensichtlich nicht verstanden hast, ist das Logic die Playback-Buffer asynchron setzen kann. In dem Fall läuft dann ganzes Projekt sagen wir mal auf mixfreundlichen 512 Samples und alle Spuren (oder auch Aktionen am Mixer) haben dann eine Verzögerung von 512 Samples. Wenn Du nun ein Instrument live dazuspielen willst, würde das in jedem Host der Welt mit 12 ms Verzögerung (bei 44,1 kHz) laufen. Logic ist aber in der Lage, diese eine Spur mit einem extrem kleinen Puffer wiederzugeben (ich meine 32 Samples, aber da kann ich mich täuschen). Das kostet zwar extrem viel Rechenleistung, funktioniert aber ganz prima, wenn man die Leistung noch übrig hat. So kann man diese Spur eben live dazuspielen, wenn man das braucht.

Das ist ein exklusives Feature von Logic und das ist auch das Ding, von dem Synthpark die ganze Zeit redet. Das fällt aber in einer allgemeinen Diskussion über Low-Latency ein wenig aus dem Rahmen, weil es nichts darüber sagt, wie ein System beim Abspielen ALLER Spuren (und eben nicht nur der einen Scharfgeschalteten) auf kleine Latenzen reagiert.
 
ähm nein nicht ganz :)

also so gehts bei samplitude (das kenne ich zumindest ein bisschen weil ich paarmal mit gearbeitet habe, bei logic dass ich ewig nicht mehr benutzt habe nehme ich einfach mal positiv an, dass es ähnlich gemacht ist, und das ist was gutes, denn es ist ein ziemlich schlaues feature):

das, was bei niedrigen latenzen besonders viel systemlast erzeugt, ist ja der umstand, dass die CPU nur eine begrenzte zeit (nämlich den dann ziemlich winzigen puffer) hat, um den ganzen kladderadatsch zu berechnen. deswegen sinkt auch die CPU last massiv, wenn man in einem komplexen mix die latenz hochschraubt.

was nun samplitude macht ist, dass es zwei (wenn ich mich recht erinnere sogar drei) verschiedene technische ansätze gleichzeitig erlaubt. ein typisches setup sieht dann so aus:

1. playback spuren (ob nun audio oder instrument - spuren, die nicht "scharf geschaltet sind") laufen mit hoher latenz. sie sind nicht gefreezt, sie reagieren auf input, aber mit einer der höheren latenz entsprechenden höheren verzögerung. beim audiokanal kannst du noch an allen plugineinstellungen drehen, du hörst die veränderungen aber eben immer erst z.b. 20ms später - was im alltag, wenn man an einem eq o.ä. schraubt mehr oder weniger wurscht ist. auch beim instrumentenkanal kannst du an allen parametern schrauben, filter cutoff runter und rauf usw, selbes ding. es ist also kein freeze-trick irgendeiner art. würde man in diesem setup allerdings den synth SPIELEN wollen, hätte er eben auch auch eine entsprechend hohe reaktionszeit, und während 20ms beim drehen an parameterreglern eher wurscht sind, sind sie beim spielen schon ziemlich hinderlich und bestenfalls gerade noch so erträglich.

nun hast du also ein projekt, das - egal ob es nur aus audio oder nur aus virtuellen instrumenten besteht, bei niedrigen latenzen nicht mehr sauber spielen würde, bei hohen aber sehr wohl. und so läuft das jetzt also schön. blöd wäre dann jetzt (und ist dann auch blöd in allen hosts, die diese technik nicht beinhalten, also fast alle) wenn du was spielen willst - latenz! doof!

2. und hier kommt in samplitude dann eben die technik zum einsatz, dass parallel zum "luxuriös gepufferten" gesamtprojekt die spur, die du gerade scharf geschaltet hast, mit niedriger latenz (also kleinen puffern) läuft. so kann man auch in dicken mixen die die CPU niemals komplett mit niedriger latenz bewältigen könnte, noch schön latenzarm einspielen. tolle sache.

wie sie das machen, dass dann die kleinen pufferpäckchen mit den grossen "verheiratet" werden usw, keine ahnung, und es gibt wenn ich mich recht erinnere sogar noch eine dritte einstellung für direct monitoring, aber so gut kenne ich samplitude dann auch nicht. aber mir auch wurscht, solange es funktioniert. ich finde das als normalerweise-nicht-samplitude-user auf jeden fall ein beeindruckendes feature und hoffe dass sich das noch weiter verbreitet (=auch zu meinem host kommt ;) )

bei logic nun ist mein wissensstand deutlich magerer, da "sagen leute die ich kenne", dass das so oder mindestens so ähnlich sein soll. insofern: super! hey, ich sag mal was nettes über logic, das ist doch mal was :)

ganz interessant in diesem fall: ob logic dieses leckere feature genau wie samplitude hat könntest du bei dir auch testen: macht es einen unterschied, ob du die spuren nicht-scharfgeschaltet so wie in deinem test gerade laufen lässt, oder ob du sie ALLE scharfschaltest und dann mit zwei breiten armen auf der tastatur rumdöngelst? in cubase, welches einen "one buffer for it all" ansatz verfolgt, macht es KEINEN unterschied. kannst du ja mal ausprobieren, wie das in logic ist. damit ist natürlich noch nicht ausgeschlossen, dass das irgendein ominöses häkchen irgendwo in den preferences ist, aber zumindest im positiven sinne könnte mans nachweisen, denn wenn sich an der CPU last was ändert wenn du denselben test "von hand" (bzw arm ;) ) mit zwei dutzend scharfgeschalteten spuren machst, dann muss logic auf jedenfall in irgendeiner form eine vergleichbare technik wie samplitude nutzen - und das wär was gutes.

und so ganz überraschen würds mich auch nicht - ich meckere gerne über logic, aber einen vergleichbaren fall gabs auch schonmal beim pluginverhalten generell: logic war einer der ersten hosts, bei dem plugins nur dann CPU last erzeugten wenn auch wirklich überhaupt gerade audioinput vorliegt, was in der summe MASSIV performance spart. auch da sind die meisten hosts erst deutlich später nachgezogen.

jetzt hab ich schon zwei nette sachen über logic gesagt, jetzt muss ich mal besser aufhören ;-)
 
(mein ähm nein nicht ganz bezog sich auf die post über rainer - hab rainers nachtmenschentum unterschätzt)
(aber hey, jetzt fällts mir ein, du erwartest nachwuchs, richtig?? glückwunsch!!!)
 
...und natürlich hat er alles was ich gesagt habe wie immer viel kurzer und knapper auf den punkt gebracht. na toll ;-)
 
(mein ähm nein nicht ganz bezog sich auf die post über rainer - hab rainers nachtmenschentum unterschätzt)
(aber hey, jetzt fällts mir ein, du erwartest nachwuchs, richtig?? glückwunsch!!!)

Dankeschön! Ich denke aber, dass sich heute Nacht nichts mehr tun wird.

Zu alten Keyboards-Zeiten war ich aber auch öfter sehr spät auch im Forum unterwegs, wenn ich mal wieder eine Deadline bis ans absolute Limit gedehnt hatte (Ralf wird sich sicher noch leidvoll dran erinnern). Da sind wir uns auch immer um diese Zeiten über den Weg gelaufen ;)
 
oh ja, deadlines. im moment muss da bei mir irgendwo ein nest sein...
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

moonbooter
    • Danke
  • Artikel
Testberichte Test: Behringer Pro-1
Antworten
5
Aufrufe
25K
moonbooter
moonbooter
F
Antworten
7
Aufrufe
1K
FoggyDu
F
moonbooter
    • Danke
  • Artikel
Antworten
16
Aufrufe
83K
alex-reed
alex-reed
moonbooter
    • Danke
  • Artikel
Antworten
1
Aufrufe
28K
L0rdVetinari
L0rdVetinari

Neue Antworten


Oft gelesene Themen

Zurück
Oben