Logic 9.1 ist draussen

Eine gute Nachricht ist, dass sie einen Trick gefunden haben, der das ganz große Plugin-Chaos, das ich befürchtet hatte, verhindern kann: die "32-bit Audio Unit Bridge".
Fair wäre es von Apple, wenn die Bridge nicht nur von Logic genutzt werden dürfte. Sonst wird nämlich jeder andere Host-Hersteller beim Umstieg auf 64 Bit auch so was erfinden müssen.
 
Was ist eigentlich mit dem, was in VST der Unterschied VST 2 und VST 3 ist: Fenstergrößen und so. Weisst du da bisschen was wie das bei AU geregelt ist? Ich bin bisschen raus aus der Coderei bei sowas, daher…
 
Moogulator schrieb:
Was ist eigentlich mit dem, was in VST der Unterschied VST 2 und VST 3 ist: Fenstergrößen und so. Weisst du da bisschen was wie das bei AU geregelt ist? Ich bin bisschen raus aus der Coderei bei sowas, daher…
Zum Vergrößern anklicken....
Können AU-Plugs nicht schon immer die Größe ändern?
 
Ich mein von der SDK-Seite her. Die meisten sind eh portierte VSTs denke ich. Das ist einfach ne andere API und so. Ich kenn mich aber nicht gut mit diesen Verabredungen und Schnittstellen aus von INNEN. Deshalb bitte ich um Erleuchtung.
 
au und vst sind eigentlich im kern nur schnittstellen definitionen, über die die host dann auf die implementationen zugreifen können, ohne die speziellen implementationen kennen zu müssen.

die interface definition für vst gibts hier:

http://ygrabit.steinberg.de/~ygrabit/pu ... index.html

die für AU sollte im develop packet vom os-x enthalten sein...
im endeffekt kannste für die dinger sogar adapter patterns ausimplementieren wenn du es richtig anstellst. (programmatisch ist ein adapter ne klasse die das zu adaptierende objekt besitzt und dann auf das neue interface übersetzt, sprich selbiges interface zusätzlich implementiert und von dessen methoden aus das gewrappete objekt aufruft)

nur mal so. :gay:
 
Jo, deshalb ja die Frage. Das VST 2 (und davor) hatte aber eine feste Fenstergröße. VST 3 nicht mehr. AU macht das wie…?
Hab das SDK natürlich generell auch,aber mach nichts mehr (keine Zeit mehr für so Spielkram).
Dachte, jemand wüsste das direkt mal. Ich weiss nur, DASS es so ist.
 
audio units haben ne generic ui, die wird einfach aus den den definierten steuerelementen gerendert... wenn man ne richtige ui will implementiert man eine in cocoa oder carbon, da gibts keine größenbeschränkung soweit ich das in der doku blicke.
 
Ok, das ist nen Wocht. Dann haben die das vermutlich seit Anbeginn von AU drin, bei VST ist es halt ab der 3.Revision. Da gibts ein bisschen einen Reformstau. Es ist ja in der Pluginwelt so, dass auch manche ihre Sachen einstellen oder nicht zu oft updaten und damit auch nicht auf diesen Stand bringen.
 
reformstau gibts überall... ich such grad zum beispiel nen browser mit ganz wenigen aber dafür sehr großen bedienelementen... so für meinen touchscreen... alles nicht so einfach ;-)
 
@Moogulator:
Was AU seit Anbeginn hat (ich rede immer nur von AU v.2 (ab OSX10.2), vorher war es nicht ernstzunehmen), ist eine starke Abstraktion (= Nicht-Festlegung) des UI.
Entweder man liefert gar kein UI, dann kann (nicht muss!) man stattdessen die Parameter, die man angemeldet hat, in ihren Eigenschaften so detailliert beschreiben, dass das Hostprogramm immerhin ein hässliches Not-UI daraus bauen kann. Unter Parametern stell dir bitte die Dinge vor, die man im Sequenzer automatisieren könnte. Oder man liefert ein UI, wobei man dann auch Bedienung für anderes als nur Parameter einbauen kann. (Ist das vielleicht bei VST auch so ähnlich?)
Ein AU-Plugin erzählt über ein mitgebrachtes UI gar nichts, wie etwa Fenstergröße, sondern nur, unter welchem Namen es abgespeichert ist, quasi wie ein separates zweites Plugin. (Tatsächlich separat laufen tun sie bei LogicNodes!) Anfangs war man auf Carbon-UI festgelegt, später durfte man auch ein Cocoa-UI nehmen. (Man darf auch beide Arten UI, von jedem eines, so dass sich ein Carbon-Host und ein Cocoa-Host das jeweils entsprechende Plugin-UI schnappen kann -- aber wer macht das schon?)
Auf Carbon kann ich noch nicht mal danke sagen, so wenig verstehe ich davon. Über Resizing bei AU-Carbon-UIs weiß ich daher nichts, vielleicht ist da ja alles ganz schwierig? Frag andere.
Bei Cocoa geht es jedenfalls so: Der Host macht sich ein Exemplar des Plugin-UIs, schlägt ihm eine Standardgröße der "Malfläche" (View) im Window vor, das Plugin erzeugt den View mitsamt Inhalt, der Host erzeugt das Window und baut den View in das Window ein. Mit jener vorgeschlagenen Größe habe ich aber bisher noch nichts Sinnvolles anfangen können, Apple selbst wohl auch nicht. Die Größe des Views entscheidet das Plugin-UI; wenn der Host was dagegen hat, muss er halt ein Window mit Scrollbalken machen.
Weil es sich um ganz normale Cocoa-Views und -Windows handelt, stehen ihnen die normalen Resizing-Funktionen zur Verfügung. Nichts steht dem im Wege, per InterfaceBuilder baut man Resizing mit ein paar Klicks ein. Wenn der Host das Window nicht resizable macht, ist er selbst schuld. Und das Plugin ist doof, wenn es nicht auf Resizing reagiert. Ob man sich beim Host- oder Plugin-Hersteller beschweren muss, findet man durch Vergleich mit anderen Hosts und mit anderen Plugins heraus.
Fazit: AUs mit Cocoa-UI waren schon immer größenveränderbar. Also leider nur eine Teilinformation -- sorry.
 
Jens Groh schrieb:
@Moogulator:
Was AU seit Anbeginn hat (ich rede immer nur von AU v.2 (ab OSX10.2), vorher war es nicht ernstzunehmen), ist eine starke Abstraktion (= Nicht-Festlegung) des UI.
Entweder man liefert gar kein UI, dann kann (nicht muss!) man stattdessen die Parameter, die man angemeldet hat, in ihren Eigenschaften so detailliert beschreiben, dass das Hostprogramm immerhin ein hässliches Not-UI daraus bauen kann. Unter Parametern stell dir bitte die Dinge vor, die man im Sequenzer automatisieren könnte. Oder man liefert ein UI, wobei man dann auch Bedienung für anderes als nur Parameter einbauen kann. (Ist das vielleicht bei VST auch so ähnlich?)
Ein AU-Plugin erzählt über ein mitgebrachtes UI gar nichts, wie etwa Fenstergröße, sondern nur, unter welchem Namen es abgespeichert ist, quasi wie ein separates zweites Plugin. (Tatsächlich separat laufen tun sie bei LogicNodes!) Anfangs war man auf Carbon-UI festgelegt, später durfte man auch ein Cocoa-UI nehmen. (Man darf auch beide Arten UI, von jedem eines, so dass sich ein Carbon-Host und ein Cocoa-Host das jeweils entsprechende Plugin-UI schnappen kann -- aber wer macht das schon?)
Auf Carbon kann ich noch nicht mal danke sagen, so wenig verstehe ich davon. Über Resizing bei AU-Carbon-UIs weiß ich daher nichts, vielleicht ist da ja alles ganz schwierig? Frag andere.
Bei Cocoa geht es jedenfalls so: Der Host macht sich ein Exemplar des Plugin-UIs, schlägt ihm eine Standardgröße der "Malfläche" (View) im Window vor, das Plugin erzeugt den View mitsamt Inhalt, der Host erzeugt das Window und baut den View in das Window ein. Mit jener vorgeschlagenen Größe habe ich aber bisher noch nichts Sinnvolles anfangen können, Apple selbst wohl auch nicht. Die Größe des Views entscheidet das Plugin-UI; wenn der Host was dagegen hat, muss er halt ein Window mit Scrollbalken machen.
Weil es sich um ganz normale Cocoa-Views und -Windows handelt, stehen ihnen die normalen Resizing-Funktionen zur Verfügung. Nichts steht dem im Wege, per InterfaceBuilder baut man Resizing mit ein paar Klicks ein. Wenn der Host das Window nicht resizable macht, ist er selbst schuld. Und das Plugin ist doof, wenn es nicht auf Resizing reagiert. Ob man sich beim Host- oder Plugin-Hersteller beschweren muss, findet man durch Vergleich mit anderen Hosts und mit anderen Plugins heraus.
Fazit: AUs mit Cocoa-UI waren schon immer größenveränderbar. Also leider nur eine Teilinformation -- sorry.
Zum Vergrößern anklicken....

Ah, danke. Das beantwortet es weitgehend. Erstmal. Naja. Nur Carbon ist ja weg. Wie es mit 10.7 weiter gehen wird, wissen wir ja auch nicht. Aber egal. So ist das schonmal nachvollziehbar.
 
Moogulator schrieb:
[...] Nur Carbon ist ja weg. Wie es mit 10.7 weiter gehen wird, wissen wir ja auch nicht. [...]
Zum Vergrößern anklicken....
Na ja, sagen wir mal, Carbon ist strongly discouraged.
Apple wird damit endlich auch alle Plugin-Programmierer überzeugen, denn wer bei Carbon bleibt, dessen Plugins laufen zwar weiterhin, aber sie müssen bei einer 64Bit-DAW "am Katzentisch mitessen", d.h. in der 32Bit-Bridge laufen, das lässt sie gleich als zweitklassig erkennen.
Host-Hersteller müssen keine Rücksicht auf den Modernisierungswillen der Plugin-Hersteller mehr nehmen -- Apple als wichtigster hat es jetzt gezeigt.
Schon geschickt, Carbon nicht auf 64 Bit mitzuziehen. Sonst wäre die Plugin-Szene vielleicht nie von dieser Antiquität weggekommen, immer mit dem Vorwand, die Host-Hersteller tun es ja auch nicht, und in Gegenrichtung war es ja genauso. Jetzt kehrt sich das um: Die Befürchtung, die Host-Hersteller bieten 64 Bit an und degradieren damit mein Plugin, das macht wirklich Druck.
Damit wird Audio vielleicht am Ende sogar schneller von Carbon weg sein als der Rest. Wird mir gerade erst klar.
 
Moogulator schrieb:
Wobei Apple mir manchmal schon zu schnell ist beim abschnippeln.
Zum Vergrößern anklicken....
Ja, es ist schon ein hoher Preis, den man dafür zahlt, dass es die modernste Software bleibt.
Die Alternative heißt leider: Buy cheap, get cheap.
 
Das hat einen Namen: Windows. Oder es bleibt ewig Flickwerk: Linux. Ist alles nicht super. Aber egal. Ich muss ja nicht coden. Ich bin da heute auch lieber nur Kunde.
 
jetzt hab ich mir das Update runtergeladen und wollte es installieren, da kommt die Meldung " Warnung! Ihr Computer benötigt dieses Update nicht!
Hab ein brandneues MacBookPro 17" mit aktuellem Betriebssystem und der 9.02 Logc und der 2.01 Mainstage Version drauf. wass issn da los?
 
Vermutlich hast du's schon drauf oder deine Install CD ist superfrisch oder sowas. Oder das OS ist alt, denn einige Funktionen laufen nur mit Snow Leo (64 Bit) und andere brauchen mind Leo. Deshalb kann er es ggf. ablehnen. Denk ich mal.
 
Wie gesagt ist Snow Leo 10.6.2 drauf. beim Logic Paket 9.0.2 sowie Mainstage 2.0.1. Dies entspricht auf der Apple Support Seite der zweitletzten Aktualisierung.
Im Systemprofiler wird ebenfalls 9.02 und 2.01 angezeigt. Meiner Meinung nach also nicht aktuell. Warum mir bei der Softwareaktualisierung dann aber angezeigt wird, dass meine Programme alle aktuell sind kapier ich nicht.
Irgendwo auf der Festplatte müssten doch noch die Quittungen sein für die Installer Pakete mit Endung .pkg. ?
 
Moogulator schrieb:
Library Bereich wird nicht durchsucht von Spotlight.
Zum Vergrößern anklicken....
habs gefunden. die reciepts von logic sind nicht direkt sichtbar. allerdings gibts ein installhistory.plist file, welches sich als textfile öffnen lässt. 9.0.2 ist definitv am 7.1. drauf gekommen. nun denn werd ich mal warten bis nach der namm wenn mein support spezi wieder zuhause ist...
 
mmmm will auch logic 9.1 und nen mac

bin nur am grübeln welchen mac ich brauche mit was ? ???

und welche soundkarte noch dazu ...

grübel grübel

sag mal einer an bin auf pc festgefahren

klingt jetz stulle aber ich fahre mit logic 5.5 und abelton 6 ganz gut

laüft das file management genauso ab wie auf dem pc ??

auf das mir den plug ins ? bin da echt mega noob
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Similar threads

C-Dream
günstiges PlugIn Bundle für viele DAWs €17,50
Antworten
8
Aufrufe
2K
einseinsnull
einseinsnull
A
Welche Zusatzgeräte sind sinnvoll für mein System?
2 3
Antworten
89
Aufrufe
11K
hairmetal
H
Moogulator
Logic Update.
Antworten
8
Aufrufe
2K
Rastkovic
R
Booty
Logic 64bit? Das Ende des Speichernadelöhrs?
Antworten
0
Aufrufe
768
Booty
Booty
Moogulator
  • Gesperrt
SynMag - Das Synthesizer-Magazin
Antworten
1
Aufrufe
6K
Moogulator
Moogulator


Neueste Beiträge

News

Zurück
Oben