News: M4 mac minis, 2024 (gerne auch für Mac studio). Erste Leaks

[siebenachtel]

dir ist schon klar, dass das rechnerisch in etwa einer viertelmillion stereospuren in 32 bit entspricht?

hmm, irrelevant ! weil: anderes Thema (sprich: man muss zwischen verschiedenen usecases differenzieren)

oder dass man damit in 0,3 sekunden eine bluray kopieren kann.

wieder: irrelevant ! weil: anderes Thema (sprich: man muss zwischen verschiedenen usecases differentieren)

Du sprichst von irgendwelchen usecases und schonglierst mit Zahlen die in Bezug zu meinem usecase nur theoretischer Natur sind. Meine Erfahrungen waren real live. Ich deale nicht mit files abspielen, sondern damit, audio das grad frisch berechnet wurde in echtzeit zu manipulieren.

Deine Zahlen mögen stimmen. Das stelle ich nicht in abrede.
Aber die haben wie erwähnt nichts mit meinen real-live Erfahrungen zu tun, die auf ner ganz anderen Ebene abliefen.
Der Punkt bei mir ist echtzeit manipulation von seriell gestaffelten Daten. Die manipulation geschieht an zig punkten gleichzeitig. Müsste eigentlich PC-intern ein ganz normaler Vorgang sein. Aber: hier dealen wir mit verketteten plugins in meinem Falle. Und das audio soll halt nicht crackeln ! k.A. wieso das so ist. Aber der hohe Datendurchsatz ändert da was bzgl. gewisser ganz spezifischer usecase szenarien.

ich habe den M1mac in Bezug zum Datendurchsatz in die knie gefahren ! Das ist real. (und: reproduzierbar)
Der M1 hat 100GB/sek Datendurchsatz.
Am M2 ist es mir nie passiert.
Der hat 200GB/sek Datendurchsatz.


Aber ok, ums komplett zu machen:
Dass dabei der Datendurchsatz das Nadelöhr war ist eine reine Vermutung von mir.
Sehe aber nichts anderes was es hätte sein können.
An der CPU lags nicht. Die war teils nur mittlemässig ( 1 Kern) teils sogar weniger, belastet.
Das mit dem Datendurchsatz hat in Bezug zu meinem Szenario auch ne gewisse Logik. Am M2 hatte ich selbige Probleme wie gesagt nie.


mittlerweile gibts btw. viel mehr Benchs zum M4.

Mein M2pro schaut im Vergleich zu anderen M2pro Werten nicht sehr gut aus. Hab den gestren mal gemessen.
M4er haben teils effektiv umd die 50% mehr Leistung als wie ein M2. Auch single Core.
Das ist dann 10core vs. 8core. aber bei beiden M2 udn M4 4x P-Kerne. (bzgl. der Daten die ich direkt Vergleiche)

Was ich mitbekommen habe ist dass man so tests nicht zu früh machen soll. Das System muss da was indizieren, oder wie auch immer. Jedenfalls laufen da anscheinend gewisse routinen im Hinterhrund ab am Anfang. Gewisse M4 benchs sind auch komisch tief. Einer komisch hoch. ( was ich gestern gesehen hatte). die tiefen werte basieren anscheinend oft darauf dass Leute das zu früh testen.


Ist auch die Frage woher die M4 Tests kommen. Anscheinend gabs ein Meeting in L.A..
Möglicherweise kommt das aber auch von Beta maschienen die jetzt vielleicht "dürfen".

Eins ist jedenfalls sicher:
Diese M4er sind sauschnell !
Der sprung vom M3 zum M2 war grösser als wie vom M2 zum M1.
Jetzt ist der sprung nochmals etwas grösser.
Wer vom M2 kommt hat das surplus von 2 generations jumps.

 

[einseinsnull]

hmm, irrelevant ! weil: anderes Thema (sprich: man muss zwischen verschiedenen usecases differenzieren)

was an deinem usecase (soweit mir bekannt) bedarf denn eine speicherbandbreite höher als 120gb/s?

ja, ich weiß, bei single core prozessen ist die speicherbandbreite natürlich entsprehend kleiner. aber doch immer noch viel mehr als du brauchst.

Ich deale nicht mit files abspielen, sondern damit, audio das grad frisch berechnet wurde in echtzeit zu manipulieren.

die anforderungen an den maximalen speicherdurchsatz sind für lesen/schreiben/bearbeiten identisch mit dem für lesen/schreiben ohne bearbeitung. das gilt um so mehr für audio oder video, was in blöcken verarbeitet wird. es ist ja jetzt nicht so, dass wenn einhall plug-in aus 1000 filtern besteht, dass die einzeln prozessed und zwischendurch wieder wo hingeschrieben werden würden.

hast du da schon mal erlebt, dass etwas nicht berechnet werden konnte weil das RAM zu langsam war? während der prozessor noch luft gehabt hätte?

 

[siebenachtel]

ja, ich weiß, bei single core prozessen ist die speicherbandbreite natürlich entsprehend kleiner.

eben

aber doch immer noch viel mehr als du brauchst.

das weiss ich nicht.

Für mich siehts anders aus.
Ne Bestätigung dass das was ich denke auch richtig ist habe ich aber nicht. (Wie bereits erwähnt)
Aber es ist -für mich- die einzig mögliche logische Erklärung.

es ist ja jetzt nicht so, .............., dass die einzeln prozessed und zwischendurch wieder wo hingeschrieben werden würden.

"ich denke" das ist bei meinem Prozess haargenau der Fall.
Deins ist da btw. auch wieder nur ne Vermutung


Delay -> audio wird in den Buffer geschrieben -> der buffer (gespeichertes audio)wird ausgelesen -> der Zeit parameter des delays wird manipuliert ( das delay steht dabei im kleinen ms bereich, inkl. aufgedrehtem FB)
-> dieses manipulierte audio geht ins nächste delay ( ähnliche Einstellungen). Wird also erneut in nen buffer geschrieben,....und wird erneut ausgelesen -> dieses Delay wird auch im Zeit parameter manipuliert, -ZEITGLEICH-,
-> dieses audio geht in noch ein delay, selbe Geschichte ! wird auch -ZEITGLEICH- manipuliert.
Weiss nicht bis wie weit ich das jeweils getrieben habe. 4 stück delays hintereinander ganz sicher. Hab aber ein delay verwendet gehabt das in sich selbst delays stacken kann........


also mehrfach seriell hintereinander, audio in buffer schreiben, dieser Inhalt des buffers wird manipuliert während es ausgelesen wird.
alles mehrfach hintereinander.
ALLE Delays werden zum gleichen zeitpunkt manipuliert !
D.h. es ist immer der inhalt des buffers der jetzt -als audio- manipuliert wird, und damit den sound ändert.
Das ist echtzeit sounddesign, FXing in serieller abfolge, während die manipulation auf allen verarbeitungsstufen nicht seriell, sondern parallel erfolgt.

Die delays stehen dabei nicht nur im kleinen ms bereich was den Zeitfaktor angeht. Die manipulation geschieht mit nem fader den man sehr schnell bewegt. ( Das sind alles Faktoren die hier mit rein spielen in Bezug zu, was geht und was nicht)


und jetzt sag du mir ob das Sinn macht zu denken dass ich "so" das ganze Ding am Datendurchsatz an die Grenze bringen kann ?






Dass das alles kein Problem wäre, wenn alles innerhalb eines einzigen plugins abliefe, das ist mir klar. Ich sehe es jedenfalls so.
Aber der ganze ablauf auf mehrere plugins verteilen ?
Scheint was zu ändern

Dann fängt das irgendwann an zu zicken.
Und ich behaupte jetzt, dass ein schnellerer Datendurchsatz da bei dem ganzen hilft.
Da ist ne Relation zu sehen.
Das behaupte ich so.
hab da ausführliche tests gemacht gehabt (auf dem M1)



Daraus leite ich im weiteren ab, das wenn du in ner DAW sehr viel automatisierst, dann zwar anders aufgebaut, aber allenfalls auf vielen Tracks gleichzeitg, dass du dort -wenn alles blöd geht- allenfalls auch ans limit des datendurchsatzes kommen kannst.

Der springende Punkt ist aus meiner Sicht definitv das Ding mit "audio in nen Buffer schreiben", ...wieder auslesen, wieder in nen buffer schreiben.
also delays + Reverbs sind hier die ersten kandidaten.

Weiss nicht. Ich würde bei nem "teureren" PC auf Nummer Sicher gehen wollen.


Der DAW hilfts aber dass die auf vielen Kernen arbeiten kann.
Drum hilfts umgekehrt auch mehr Kerne zu nehmen als man von der reinen CPU gesammtpower vielleicht brauchen würde.
Die DAW kann dann die Lasten einfacher verteilen.

 

[einseinsnull]

Delay -> audio wird in den Buffer geschrieben -> der buffer (gespeichertes audio)wird ausgelesen

ja ja, das ist schon klar, bei verzögerungen oder bei transferfunktionen schreibt man auch mal ausnahmsweise was in den hauptspeicher. das merkt ein M4 aber überhaupt nicht. da kannste nebenher noch 3 videos schauen.

-ZEITGLEICH-,
-> dieses audio geht in noch ein delay, selbe Geschichte ! wird auch -ZEITGLEICH- manipuliert.

ist auch richtig, letztlich kommt es nur auf die potentiellen spitzen an.

Weiss nicht bis wie weit ich das jeweils getrieben habe. 4 stück delays hintereinander ganz sicher.

4 feedback delay effekte hintereinander mache ich dir auf einem 604e prozessor von 1993.

dass der datendurchsatz des speichers dabei eher an seine grenzen kommt als die CPU, die dieses auslesen und bearbeiten ja auch erledigen könenn muss, können wir gestrost ausschließen, ohne es evident beweisen zu müssen. selbst bei einem delay. (wobei man auch nicht unterschätzen sollte, was ein richtig gutes delay macht: komplexe interpolation bei hochsampeln, antialiasing filter nach dem upsamplen usw.)

ALLE Delays werden zum gleichen zeitpunkt manipuliert !
D.h. es ist immer der inhalt des buffers der jetzt -als audio- manipuliert wird, und damit den sound ändert.

das passiert alles in blöcken. erst wenn die queue voll ist feierabend.

und jetzt sag du mir ob das Sinn macht zu denken dass ich "so" das ganze Ding am Datendurchsatz an die Grenze bringen kann ?

man kann alles an seine grenze bringen wenn man nur genug #irgendwas aufmacht. aber sicherlich nicht mit 4 plug-ins.

nehmen wir noch mal meine naive "berechnung" von oben.

wenn 10 kerne 120 gb/s haben, dann hat 1 kern immerhin noch 12 gb/s.

jetzt nehmen wir mal großzügg an, dass nur 25% des unified RAM in schnitt für GP zur verfügung stehen, weil du gerade auch viel mit video macht und noch 3 andere programme auch offen sind.

aus der "viertelmillion streams" die ich oben behauptete, die sich auf 32bit/44khz/mono bezogen, würden selbst bei 64bit/4-fach oversampling und in stereo immer noch 1500 solcher streams übrig bleiben.

1500x32 samples passen noch auf den cache eines G4 server prozessors aus dem jahr 2002. das RAM bekommt von dem vorgang erst nach dem VST slot etwas mit. die CPU hingegen macht lange vorher schlapp.

ich würde mal behaupten, dass hauptspeicher immer schnell genug angebunden sind um die CPU voll auszulasten. vermutlich selbst bein bloßen auslesen von daten.

hab da ausführliche tests gemacht gehabt (auf dem M1)

es gibt doch analyse tools dafür, dir dir zeigen, was so passiert. ist nur in bezug auf die CPU als vergleichsgröße manchmal nicht ganz einfach.

Daraus leite ich im weiteren ab, das wenn du in ner DAW sehr viel automatisierst, dann zwar anders aufgebaut, aber allenfalls auf vielen Tracks gleichzeitg, dass du dort -wenn alles blöd geht- allenfalls auch ans limit des datendurchsatzes kommen kannst.

wenn die steuerdaten eine höhere priorität haben wie das audio, dann stören sie die bearbeitung von audio streams. ob sich im DPS irgendwas live ändernt oder nicht, sollte allerdgins egal sein. dadurch werden nicht mehr daten geschrieben, falls denn überhaupt.

was sagt denn dein CPU meter in sochen fällen? hyperthreading macht da je mehr probleme, bei einer ein-kern oder ein-prozessor anwendung sollte manin einem audioprogramm durchaus bis zu 90% auslastunganzeige kommen können.

Der springende Punkt ist aus meiner Sicht definitv das Ding mit "audio in nen Buffer schreiben", ...wieder auslesen, wieder in nen buffer schreiben.
also delays + Reverbs sind hier die ersten kandidaten.

reverbs sollen sowas nicht machen. über welches delay reden wir? ein bestimmtes produkt?

 

[siebenachtel]

reverbs sollen sowas nicht machen.

haha, bei mir schon !

über welches delay reden wir? ein bestimmtes produkt?

teils verschiedene. Das damals war hauptsächlich, evtl. auch ausschliesslich das Matrix Delay von chow DSP

was sagt denn dein CPU meter in sochen fällen?

solche patches bewegten sich bei 30-60% maximal.
35-45% mehrheitlich, würde ich mal sagen

ich würde mal behaupten, dass hauptspeicher immer schnell genug angebunden sind um die CPU voll auszulasten.

gut, ich nehme deine Ausführungen dankend zur Kenntnis !


Vielleicht veränderts ja sogar noch meinen Entscheid was ich nehmen soll.
Erstmal mit nem kleinen M4 starten ? hätte auch was.
Und wer weiss, vielleicht wird der Studio ein richtig grosser Wurf, mit anderer CPU ? ausgeschlossen ist es nicht.

 

[kybernaut_01]

@siebenachtel Was man auch bedenken sollte: ein und dasselbe Nutzungsszenario /Logic-Projekt etc. kann mit dem einem Audiointerface cracklen und mit dem anderen nicht. Es muss also nicht zwingend das Ende der Speicherbrandbreite oder Rechenleistung erreicht sein.

 

[siebenachtel]

@siebenachtel Was man auch bedenken sollte: ein und dasselbe Nutzungsszenario /Logic-Projekt etc. kann mit dem einem Audiointerface cracklen und mit dem anderen nicht. Es muss also nicht zwingend das Ende der Speicherbrandbreite oder Rechenleistung erreicht sein.

Ja, das ist en guter Punkt. Das hatte ich auch so erlebt.
Ich hab/hatte aber immer mehrere Audio interfaces angeschlossen und konnte jederzeit umstellen und testen.
Dasjenige mit der höheren Latenz hat teils weit weniger gecrackelt.
Auch das hatte sich am M2 dann aber verändert


Danke für feedback.
Ich selbst will aber glaube ich trotzdem weiterhin nen gewissen Datendurchsatz haben wenns irgend geht.
Falls ich doch nen kleinen M4 nehme werde ich halt mal schauen müssen.
Eigentlich wärs sogar ein interessantes experiment.
...aber ehrlich gesagt, ist schon was bestellt. Und das ist nicht der kleine

 

[einseinsnull]

mir ist schon nicht klar woher deine vermutung kommt, dass es mit dem RAM zusammenhängt, wenn das doch niemals in irgendeiner form gemessen werden konnte.

mir ist aber auch selbst nicht so ganz klar, warum manche programme so einen SoC als einen chip sehen - und andere nicht.

eine einfache lösung für hyperthreading in GP wird es wohl niemals geben, weil der weg durch die flexiblen routing optionen verbaut ist.

und SMT gibt es bei ARM SoCs nur theoretisch (einige meinen auch der begriff sei dafür falsch, weil es einfach komplett anders funktioniert wie bei 86k, alleine schon weil ja unterschiedliche kerne mitspielen.)

das einzige was du tun kannst ist die effekte in einer zweiten kopie des programms laufen zu lassen, das läuft dann auf dem übernächsten kern. das geht beliebig oft. also jedenfalls auf intel.

 

[siebenachtel]

eine einfache lösung für hyperthreading in GP wird es wohl niemals geben, weil der weg durch die flexiblen routing optionen verbaut ist.

das sagen die Devs von GP auch.
Aber: kennst du den Nord Modular ?
der hatte 4 DSPs.
Da ging ein patch je DSP.
Dann gabs mal ein update, und man konnte die sounds von patch zu patch / DSP zu DSP leiten.
Genau sowas könnte man bei GP auch einführen !

das einzige was du tun kannst ist die effekte in einer zweiten kopie des programms laufen zu lassen, das läuft dann auf dem übernächsten kern.

eben, das meine ich.
aber die Datenverwaltung ?
ich mache ständig neue patches. erweitere alte, erzeuge neue iterationen.........es wäre Hölle

aber zurück zum M4 !

 

[siebenachtel]

die benchmarks zum M4 kommen ins laufen

Geekbench Search - Geekbench

 

[einseinsnull]

Dann gabs mal ein update, und man konnte die sounds von patch zu patch / DSP zu DSP leiten.
Genau sowas könnte man bei GP auch einführen !

inter-application streaming braucht immer eine systemkomponente. dann kannst du auch eine third party sytemkomponente dafür nutzen, einen spezifischen virtuellen GP instanzen audiotreiber sehe ich dafür nicht.

eher könnte ich mir eine spezielle version von GP vorstellen, bei der das freie routing auf einem graphen ("mixer und submixer, kein feedback") beschränkt ist, dann kann das alle kerne nutzen.

eben, das meine ich.
aber die Datenverwaltung ?

für eine bühnenshow mit 8 titeln, die man monatelang benutzt ist das okay. zum täglichen "patches machen" ist es definitv zu umständlich.

 

[random]

Anhang anzeigen 233349

Auf Heise dazu ein Artikel und eine weitere Lösung für den 3D Druck - 3Druck Profil

 

[kybernaut_01]

…sieht scheiße aus

 

[rauschwerk]

Der neue Mini verhält sich (wie bereits seine Vorgänger @ Apple-Silicon SoC) bez. Stromaufnahme im Sleep-Mode vergleichbar so, wie iPhones oder iPads.
Nun die Frage: Wer von euch fährt das eigene iPhone oder iPad nach "der Benutzung" vollständig runder, um das Gerät auszuschalten? Denkt mal drüber nach.

Der ein/aus-Knopf ist genau richtig bei dem neuen Mini positioniert und kaum einer wird diesen täglich bedienen, weil man sowas bei den neuen schlicht nicht mehr machen muss. Das ist heute absolut unnötig.

 

[random]

…sieht scheiße aus

Etwas schöner, die Ersten haben es "gedruckt".



Ein anderer Vorschlag eines Users ist, indem man an der Stelle des Powerknopfs einen Gummipuffer darunter macht und zum Ein-/Ausschalten einfach auf den Mac Mini drückt.
Da der Computer bei mir nicht alle Tage und jenachdem nur ca. 2-3 Stunden pro Tag nutze, werde ich, wenn ich mir je einen solchen Mac Mini anschaffe, es probieren.

 

[Cello]

Mein Mini i7 ist im Musikzimmer und daher kommt der Schalter mindestens zweimal täglich zum Einsatz. Das wäre/ist beim kommenden Mac Studio gleich. Die Bauform machte den neuen Standort des Schalters vermutlich unumgänglich…

 

[random]

Der neue Mini verhält sich (wie bereits seine Vorgänger @ Apple-Silicon SoC) bez. Stromaufnahme im Sleep-Mode vergleichbar so, wie iPhones oder iPads.
Nun die Frage: Wer von euch fährt das eigene iPhone oder iPad nach "der Benutzung" vollständig runder, um das Gerät auszuschalten? Denkt mal drüber nach.

Der ein/aus-Knopf ist genau richtig bei dem neuen Mini positioniert und kaum einer wird diesen täglich bedienen, weil man sowas bei den neuen schlicht nicht mehr machen muss. Das ist heute absolut unnötig.

Hast natürlich nicht unrecht, nur iPad und iPhone (24h) benutzt man mehr oder weniger den ganzen Tag, ersetzt das Festnetztelefon und den Computer.
Der Computer muss aber deswegen nicht 24 Stunden im Bereitschaftsmodus oder Standby sein, wenn man den selten braucht.

 

[MURX]

Der neue Mini verhält sich (wie bereits seine Vorgänger @ Apple-Silicon SoC) bez. Stromaufnahme im Sleep-Mode vergleichbar so, wie iPhones oder iPads.
Nun die Frage: Wer von euch fährt das eigene iPhone oder iPad nach "der Benutzung" vollständig runder, um das Gerät auszuschalten? Denkt mal drüber nach.

Der ein/aus-Knopf ist genau richtig bei dem neuen Mini positioniert und kaum einer wird diesen täglich bedienen, weil man sowas bei den neuen schlicht nicht mehr machen muss. Das ist heute absolut unnötig.

Weil das Thema überall gerade aktuell ist, habe ich heute mit einem Stromverbrauchsgerät den Verbrauch beim Mini M2 8GB 256GB nachgemessen.

Im Standby sind es 0,6 Watt. Im Idle zwischen 7 und 7,8 Watt schwankend. 10 Kerne GPU unter Volllast ca. 20 Watt und CPU unter Volllast ca. 25 Watt. Bei der Messung im Standby sind keine weiteren Geräte angeschlossen gewesen. Im ausgeschalteten Zustand schwankt der Verbrauch alle paar Sekunden zwischen 0 und 0,6 Watt. Um auf 0 Verbrauch zu kommen, müsste ich den Stecker ziehen.

Den Mini habe ich seit 1,5 Jahren nur dann ausgeschaltet, wenn ich Ihn mitnehmen wollte. Ansonsten immer im Ruhezustand. Ich habe mir angewöhnt, beim verlassen des Macs, auch wenn es nur für 10 Minuten ist über die Kombi cmd-alt-auswurftaste Ihn in den Ruhezustand zu versetzen, weil dadurch automatisch auch das Studio Display in den Ruhezustand geht. Das Studio Display verbraucht 25 Watt bei 50% Helligkeit.

 

[Artur Ria]

Wer von euch fährt das eigene iPhone oder iPad nach "der Benutzung" vollständig runder, um das Gerät auszuschalten?

Hier, ich. Ich schlafe dann besser.

 

[rauschwerk]

Hast natürlich nicht unrecht, nur iPad und iPhone (24h) benutzt man mehr oder weniger den ganzen Tag, ersetzt das Festnetztelefon und den Computer.
Der Computer muss aber deswegen nicht 24 Stunden im Bereitschaftsmodus oder Standby sein, wenn man den selten braucht.

Ich schalte mein Air M1 (obwohl der Rechner immer in meiner Aktentasche verweilt) inzwischen nie aus. Das Ding wird zugeklappt und wacht sofort auf beim Aufklappen.
In diesem (sleep) Zustand hält der Rechner teils Wochen aus, ohne dass man zwingend schnell ans Netzteil muss. Das Gleiche mit meinen iPads (und ja, auch mit dem M4 iPad, was mit den neuen M4 Macs sehr gut vergleichbar ist).

Die Mac Silicon müssen gar nicht mehr ausgeschaltet werden. Dort drin werkelt im Grunde die (aufgepumpte) iPhone-Technik. Das ist mit den x86-Stromfressern überhaupt nicht mehr vergleichbar hinsichtlich Sleep-Mode.
Und selbst wenn man den Knopf unbedingt bedienen will, so lässt sich das bei dem kleinen Würfel wunderbar mit einer Hand greifen und drücken - doch wie gesagt: die Teile müssen heute gar nicht mehr runtergefahren und ausgeschaltet werden.

 

[rauschwerk]

Im Standby sind es 0,6 Watt.

Das ist ein Witz bez. Stromverbrauch. Wieviel benötigt ein iPhone 16 Max oder ein iPad M4 im Sleep-Mode? Sowas wird auch nicht immer wieder aus und eingeschaltet.

 

[noise_level_11]

Ich schalte mein Air M1 (obwohl der Rechner immer in meiner Aktentasche verweilt) inzwischen nie aus. Das Ding wird zugeklappt und wacht sofort auf beim Aufklappen.
In diesem (sleep) Zustand hält der Rechner teils Wochen aus, ohne dass man zwingend schnell ans Netzteil muss. Das Gleiche mit meinen iPads (und ja, auch mit dem M4 iPad, was mit den neuen M4 Macs sehr gut vergleichbar ist).

Die Mac Silicon müssen gar nicht mehr ausgeschaltet werden. Dort drin werkelt im Grunde die (aufgepumpte) iPhone-Technik. Das ist mit den x86-Stromfressern überhaupt nicht mehr vergleichbar hinsichtlich Sleep-Mode.
Und selbst wenn man den Knopf unbedingt bedienen will, so lässt sich das bei dem kleinen Würfel wunderbar mit einer Hand greifen und drücken - doch wie gesagt: die Teile müssen heute gar nicht mehr runtergefahren und ausgeschaltet werden.

Was mobile Geräte angeht hast du völlig recht, mein MacBook schalte ich zum Beispiel auch nicht aus. Hätte ich aber einen Mini, würde der mitsamt der kompletten Peripherie via Schalterleiste ausgeschaltet werden.

 

[rauschwerk]

Hätte ich aber einen Mini, würde der mitsamt der kompletten Peripherie via Schalterleiste ausgeschaltet werden.

Wurde der Mini vorher heruntergefahren?

 

[siebenachtel]

ein ei-phone, irgend ein zweit oder dritt macbook Air, oder der studio/audio Rechner, -> das wird am ende des Tages aber alles anders benutzt also zumindest bei mir ist das so.

Zu lange anlassen ist nicht gut. Erst ein power cycle resettet gewisse Dinge komplett.
Schadet dem Audio Rechner sicher nicht !

@Moogulator
unser Offtopic, 110 + 7/8, könnte man btw. wegschneiden. die diskussion ist beendet