Danke für den Hinweis. Meine obige Frage halte ich jedoch für beantwortet. Von "nativ auf Mac" und "cross-platform" kann man m. E. bei m.objects derzeit nicht sprechen.mopperle hat geschrieben:Erwin, dann würde ich Steffen Richter direkt kontaktieren ...
m.objects bald für macOS verfügbar
Re: m.objects bald für macOS verfügbar
Re: m.objects bald für macOS verfügbar
ErwinKMeine obige Frage halte ich jedoch für beantwortet. Von "nativ auf Mac" und "cross-platform" kann man m. E. bei m.objects derzeit nicht sprechen.
da muss ich dir leider recht geben.
-
m.objects
- Site Admin
- Beiträge: 1284
- Registriert: 20.06.02, 15:27
- Wohnort: Münster (Westf.)
- Kontaktdaten:
Re: m.objects bald für macOS verfügbar
Liebe Interessenten für m.objects unter macOS,
letztlich kommt es m.objects-Anwendern ja zumeist auf die Erfüllung folgender Kriterien an, die daher immer die wichtigsten Ziele unserer Tätigkeit darstellen:
- Umfassende und leicht erlernbare Funktionalität
- Exzellente Ausgabequalität und Leistung
- Stabiler Betrieb auf verschiedenartigsten Systemen
- Guter Support bei allen Fragen rund um Anwendung und Technik
Wer also primär an diesen Punkten interessiert ist, ist herzlich eingeladen, das Programm herunterzuladen, zu testen und bei Bedarf auch unseren Support zu kontaktieren.
Welchen technischen Unterbau m.objects nutzt, interessiert technisch besonders versierte Anwender aber mitunter ebenfalls. Daher will ich dem bereits zuvor Geschriebenen ein paar Anmerkungen hinzuzufügen, auch um Missverständnisse zu vermeiden:
1. m.objects nutzt - wie von uns auch kommuniziert wird - eine bekannte Bibliothek (Wine) für die Anpassung zwischen Win32 und Cocoa/Darwin. Es handelt sich dabei ausdrücklich nicht um eine Windows-Emulation, sondern um eine autarke Laufzeitumgebung, die den Betrieb von Programmen, die für Windows-Systeme geschrieben wurden, ohne jegliche Windows-Installation ermöglicht.
Für Interessierte: https://de.wikipedia.org/wiki/Wine
2. Da ein solcher Ansatz bei einem komplexen Programm mit hohen Anforderungen an ein gutes Echtzeitverhalten nicht "Out-of-the-Box" optimal funktioniert, werden an zahlreichen Stellen programminterne "Schalter" genutzt, die das Verhalten je nach erkannter Hardware und Betriebssystem automatisch anpassen. Dieses Prinzip verwendet m.objects übrigens seit langer Zeit schon: Unter Windows 7 kommen so zum Beispiel andere Rendering-Routinen zum Einsatz als unter Windows 10 oder 11. Diese Techniken wurden für macOS und die dort verwendeten Grafikeinheiten und Prozessoren erweitert.
3. m.objects verwendet derzeit Intel-Code, der nativ auf Macs mit Intel-Prozessor und via Rosetta 2 auf Apple Silicon als Echtzeit-Übersetzung läuft. Wie bereits in diesem Thread, aber auch von zahlreichen weiteren Anwendern bestätigt wird, liefert dieser Ansatz in Verbindung mit dem hoch optimierten Rendering-Code von m.objects auf den aktuellen Apple Silicon Prozessoren eine exzellente Wiedergabeleistung. Selbst auf den ersten M1-basierten Geräten aus 2020 ist eine ruckelfreie Wiedergabe von komplexen Sequenzen auf UHD-Ausgabegeräten möglich. Dennoch ist bereits eine spezielle Umsetzung für Apple Silicon in der Entwicklung.
4. Es gibt wirklich noch ein paar Dinge, die eingefleischte Mac-User irritieren oder bisweilen stören. Dazu gehört allem voran die hier bereits erwähnte Zuordnung von Laufwerksbuchstaben zu den gewohnte Mac-Speicherorten. Hinter M: verbirgt sich die gesamte vom Finder gewohnte Speicherumgebung. Während der laufenden Produktionsarbeit hat der Anwender damit in der Regel wenig zu tun, da die Integration von Medien ja am einfachsten direkt per Drag&Drop aus einem Finder-Fenster erfolgt. Zu Beginn der Erstellung bzw. beim Exportieren von Shows ist die Berührung damit allerdings noch nicht vermeidbar. Zwar hat m.objects als die derzeit technisch am längsten ausgereifte und funktional umfangreichste Software Ihrer Art bereits viele Mac-Anwender überzeugen können, jedoch werden m.objects und macOS an diesen Stellen noch viel weiter zusammenwachsen, um mögliche Hindernisse zu überwinden.
Mit freundlichem Gruß
Steffen Richter
letztlich kommt es m.objects-Anwendern ja zumeist auf die Erfüllung folgender Kriterien an, die daher immer die wichtigsten Ziele unserer Tätigkeit darstellen:
- Umfassende und leicht erlernbare Funktionalität
- Exzellente Ausgabequalität und Leistung
- Stabiler Betrieb auf verschiedenartigsten Systemen
- Guter Support bei allen Fragen rund um Anwendung und Technik
Wer also primär an diesen Punkten interessiert ist, ist herzlich eingeladen, das Programm herunterzuladen, zu testen und bei Bedarf auch unseren Support zu kontaktieren.
Welchen technischen Unterbau m.objects nutzt, interessiert technisch besonders versierte Anwender aber mitunter ebenfalls. Daher will ich dem bereits zuvor Geschriebenen ein paar Anmerkungen hinzuzufügen, auch um Missverständnisse zu vermeiden:
1. m.objects nutzt - wie von uns auch kommuniziert wird - eine bekannte Bibliothek (Wine) für die Anpassung zwischen Win32 und Cocoa/Darwin. Es handelt sich dabei ausdrücklich nicht um eine Windows-Emulation, sondern um eine autarke Laufzeitumgebung, die den Betrieb von Programmen, die für Windows-Systeme geschrieben wurden, ohne jegliche Windows-Installation ermöglicht.
Für Interessierte: https://de.wikipedia.org/wiki/Wine
2. Da ein solcher Ansatz bei einem komplexen Programm mit hohen Anforderungen an ein gutes Echtzeitverhalten nicht "Out-of-the-Box" optimal funktioniert, werden an zahlreichen Stellen programminterne "Schalter" genutzt, die das Verhalten je nach erkannter Hardware und Betriebssystem automatisch anpassen. Dieses Prinzip verwendet m.objects übrigens seit langer Zeit schon: Unter Windows 7 kommen so zum Beispiel andere Rendering-Routinen zum Einsatz als unter Windows 10 oder 11. Diese Techniken wurden für macOS und die dort verwendeten Grafikeinheiten und Prozessoren erweitert.
3. m.objects verwendet derzeit Intel-Code, der nativ auf Macs mit Intel-Prozessor und via Rosetta 2 auf Apple Silicon als Echtzeit-Übersetzung läuft. Wie bereits in diesem Thread, aber auch von zahlreichen weiteren Anwendern bestätigt wird, liefert dieser Ansatz in Verbindung mit dem hoch optimierten Rendering-Code von m.objects auf den aktuellen Apple Silicon Prozessoren eine exzellente Wiedergabeleistung. Selbst auf den ersten M1-basierten Geräten aus 2020 ist eine ruckelfreie Wiedergabe von komplexen Sequenzen auf UHD-Ausgabegeräten möglich. Dennoch ist bereits eine spezielle Umsetzung für Apple Silicon in der Entwicklung.
4. Es gibt wirklich noch ein paar Dinge, die eingefleischte Mac-User irritieren oder bisweilen stören. Dazu gehört allem voran die hier bereits erwähnte Zuordnung von Laufwerksbuchstaben zu den gewohnte Mac-Speicherorten. Hinter M: verbirgt sich die gesamte vom Finder gewohnte Speicherumgebung. Während der laufenden Produktionsarbeit hat der Anwender damit in der Regel wenig zu tun, da die Integration von Medien ja am einfachsten direkt per Drag&Drop aus einem Finder-Fenster erfolgt. Zu Beginn der Erstellung bzw. beim Exportieren von Shows ist die Berührung damit allerdings noch nicht vermeidbar. Zwar hat m.objects als die derzeit technisch am längsten ausgereifte und funktional umfangreichste Software Ihrer Art bereits viele Mac-Anwender überzeugen können, jedoch werden m.objects und macOS an diesen Stellen noch viel weiter zusammenwachsen, um mögliche Hindernisse zu überwinden.
Mit freundlichem Gruß
Steffen Richter
Re: m.objects bald für macOS verfügbar
Wine selbst will (wie der Name sagt) ja auch kein Emulator sein, es emuliert allerdings das Windows API. Dass m.objects Wine benutzt, um auf MACs zu laufen, hatte ich bisher nirgendwo gelesen. Und wenn es hier um die Anpassung zwischen Win32 und Unix geht, dann ist es also korrekt, dass m.objects selbst eine 32-Bit-Windows-Anwendung ist. Gerne glaube ich, dass es viel Sachverstand erfordert, diese mit Hilfe von Wine ans Laufen zu bringen.