100% Natif OS X?, Réécrit, ou juste carbonisé? Options

[deleted]

Je me posais la question de quel séquenceur, en dehors d'intuem, était réécrit à 100% pour OS X (dit natif). Donc sans trace de Carbon. Du genre:

Pro Tools 6: __% cocoa
Logic: __% cocoa
Cubase SX: __% cocoa
Nuendo 2: __% cocoa
Metro: __% cocoa
DP: __% cocoa

Dans le même genre:
Reason 2: __% cocoa
...

Alors?

Bye.

[nicotech]

Il faut arrêter de dire que les applications carbon ne sont pas natives.

Elles le sont tout autant que les applications Cocoa.
Carbon et Cocoa sont les deux API (Application Programmer Interface)natives de Mac OS X.

Cocoa est l'interface de programmation qui vient de l'origine Next de Mac OS X.

Carbon vient de Mac OS 9, mais est aussi totalement native. Simplement elle facilite le portage d'application d'origine Mac OS 9.

Maintenant certains portages (carbonisation) mal faits peuvent ne pas être optimums à cause d'une mauvaise gestion de la boucle d'évènements.

Un carbonisation bien faîte fournit une application qui n'a rien à envier en terme de vitesse à une application Cocoa, au contraire (à cause entre autre du langage Objective C utilisé par Cocoa).

[deleted]

On va arrêter de le dire, puisque maintenant on le sait, non?
Mais faut avouer que c'est visiblement une grosse idée reçue, que j'ai entendue/lue à de très nombreuses reprises, mais pas de la part de développeurs, c'est vrai, et pour cause, j'en connais pas!

Ca m'amène à la question suivante: où se situent les améliorations de cocoa, si elles ne sont pas sur le plan de la performance? Quel réel interet? API plus riche et fonctionnelle?

Sinon, pour revenir à la question initiale, est-ce qu'une appli peut utiliser à la fois carbon et cocoa?
Dans la négative, j'efface tout de suite ce fil . Dans la positive, qqn sait pour les softs cités plus haut?

Bye.

PS: quel compilateur est utilisé sous X, gcc?

[nicotech]

Les avantages de Cocoa :
- API moderne et orientée objet.
- Développement plus rapide grâce à ObjectiveC et inteface builder.
- Modèle graphique très performant (Quartz) issue de PDF.
- Intégration simple de la scriptabilité et des services.

Les avantages de Carbon :
- En compilant en CFM, les applications peuvent être exécutées par Mac OS 9 et Mac OS X (voir les applications Adobes). Toutefois si une application tire partis d'une fonctionnalité propre à OS X (coreaudio par exemple) elle n'est plus utilisable sous Mac OS 9.
- Les programmeurs Mac OS9 ne sont pas dépaysés.
- Portage plus simple d'application Mac OS9.

Carbon n'est pas orientée objet (c'est du C) mais il existe des Frameworks objet qui l'utilise comme Powerplant (Metrowerks), MacApp (apple en cours d'abandon).
Protools dans ses premières versions était une application MacApp, aujourd'hui je ne sais pas.

Il est possible de mélanger Carbon et Cocoa, mais c'est lourd à mettre en oeuvre et cela n'est utile que si la fonctionnalité n'est disponible que dans l'un des deux environnements, donc rare.

Les compilateurs sont GCC et Metrowerks CodeWarrior (le second pour carbon principalement).

[deleted]

Merci bcp Nico pour ces éclaircissments, peu courants chez nous les musiciens et techniciens du son.
J'y vois un peu plus clair maintenant.

Mais j'ai d'autres petites questions pour toi :-D .

Pour Cocoa, tu disais:

- Modèle graphique très performant (Quartz) issue de PDF.

Concrètement, ça veut dire quoi? PDF c'est bien un format de document (portable document format), non? Rapport à l'affichage d'OS X? Paske pour l'instant performant ne rime pas avec réactif.

- Intégration simple de la scriptabilité et des services.

S'agit il de l'utilsation de script shell (tcsh, bash, etc.)? Ou d'une amélioration d'Applescript? Scriptabilité...
Pour les services, c'est très prometteur, on peut imaginer un tas d'applications utiles pour l'audio.

Pour Carbon, tu disais:

- En compilant en CFM

C'est l'acronyme de quoi? Je vois l'idée, c'est juste pour... savoir.

Les compilateurs sont GCC et Metrowerks CodeWarrior

Heureux de voir l'utilisation de soft GNU (tu connais des applis "pros" autres que gimp etc. compilés avec GCC? Genre?), mais je suis surpris de ne pas voir de compilateur proprio Motorola ou IBM..?
Et GCC peut compiler du code pour Altivec aussi?
Qqn utilise encore l'assembleur pour des softs OS X?

Je me souviens que qqn (BusError?) avait écrit ici que même les plugins étaient généralement écrits en Pascal ou en C, voire en Basic? Plus personne n'optimise son code en assembleur pour les calculs intensifs?

Bye.

PS: euh, je déplace ce fil dans Développement, non? BusError, je te laisse juger.

PS2: j'y connais rien en développement, mais j'avoue être passionné de tout ce qui se cache derrière nos systèmes et applications de tous les jours, ie comment ça a été fait, etc. Si mes questions de béotiens te gonflent (Nico), n'y répond pas ;-)

[Miss Kiki]

no no no, ne changez rien , ça m'interresse aussi!

[BusError]

Bah, vous avez eut l'opportunité de bouger ca en forum Dev, hein :-)

Ahhhh comme j'ai horreur de ca. Ca me fait mal a dents quand je lis des trucs pareils.
Cocoa n'est pas plus 'natif' qu'autre chose. Cocoa est base sur les memes APIs que Carbon; et quelquefois utilises *directement* des APIs Carbon.

Les parties 'sensibles' de OSX sont ecrite en C++. Au dessus, une legere couche d'interface C est ajoutee (ce qu'on appelle un 'stub') et au dessus, on peut trouver Cocoa.

Genre, puisqu'on est dans ce forum, CoreAudio et CoreMIDI sont techniquement des APIs "Carbon" qui collent parfaitement a ma description du paragraphe precedent.

Les avantages de Cocoa :
- API moderne et orientée objet.

Moderne circa 1984, aussi. Ca vient du NeXT faut pas oublier. Ca traine autant de casseroles que n'importe quelle API qui se traine 20 ans derriere elle.

- Développement plus rapide grâce à ObjectiveC et interface builder.

Objective C te permet de developer un application *simple* uniquement pour OSX. Ca n'est utilisé nul part ailleurs - a part pour une bande a barbu qui font GNUstep -.
Donc, oui, tu peux ecrire un Convertisseur de Monnaie en facile, 15 minutes. Mais c'est a peu pres tout, le reste prends autant de temps que dans un autre environnement - a part que tu as aucune chance de porter le code ailleurs -.
D'autre part, il ne faut pas oublier que ObjC est un language semi-interprete. La taille du runtime et le processus qui est necessaire pour que le code tourne (prebinding etc) est digne d'un Java. Qualifier ca de 'rapide et moderne' c'est une monstreuse blague.

- Modèle graphique très performant (Quartz) issue de PDF.

Alors CA, ca me fait mal aux dents aussi tiens. Quartz est une grosse blague, qui est peut etre 'beau' mais ne fait pas beaucoup plus que Postscript il y a 10 ans. Aussi, il ne fait pas beaucoup plus que QuickDraw GX d'il y a 5 ans (d'ailleur, une grosse partie a etée recyclée de la)
A la GROSSE difference que pendant ces 10 ans, les cartes graphiques se sont pourvues d'accelerateurs hardwares; que meme OS9 pouvait utiliser!
MAIS, Quartz ne peut pas utiliser ces possibilités des cartes puisqu'il fait le rendu 'manuellement' en RAM principale et donc n'a aucune chance d'etre accéléré un jour.
Et non, Quartz Extreme n'a rien a voir. QE ne concerne que la partie 'postprocessing' et 'compositing' du rendu; TOUT (le texte, graphique et autre mickeys) on deja ete dessines lentement en RAM avant d'etres passes a QE pour faire un rendu 'rapide' sur l'ecran. Tout ca n'empeche pas que le reste du rendu (la partie principale, comme dessiner du texte) reste extraordinairement lente.

- Intégration simple de la scriptabilité et des services.

Tout le mode s'en fout de ca. C'est du gadget. Et c'est aussi simple en carbon; la partie 'scriptabilité' de Cocoa est basée entierement sur une implementation... Carbon.

[deleted]

Bah, vous avez eut l'opportunité de bouger ca en forum Dev, hein :-)

En clair, ça veut dire quoi? Tu le bouges ou pas?

Ahhhh comme j'ai horreur de ca. Ca me fait mal a dents quand je lis des trucs pareils.

Carrément mal aux dents? Arghh, qu'est ce que ça doit être pour des trucs plus... importants, disons ;-) Tu sais que ça rend fou le mal de dent, y'a pas pire!

Cocoa n'est pas plus 'natif' qu'autre chose. Cocoa est base sur les memes APIs que Carbon; et quelquefois utilises *directement* des APIs Carbon.

Ok, ok, donc pour toi, cocoa est simplement une "évolution" de carbon, donc basé sur lui. Ce qui me parait logique, pourquoi réinventer la roue si des solutions existent déjà, non?
Pourrais tu me donner ta définitiopn d'une "application native", stp?

Les parties 'sensibles' de OSX sont ecrite en C++. Au dessus, une legere couche d'interface C est ajoutee (ce qu'on appelle un 'stub') et au dessus, on peut trouver Cocoa.

Quand tu dis "sensibles", tu parles de tout ce qui se trouve entre le noyau/serveurs et l'interface utilisateur, non? Style CoreMIDI et CoreAUDIO, Quartz, etc.? Juste pour clarifier ce qui semble être évident pour toi, mais pas tant que ça pour moi (et peut-être d'autres, hein Miss ;-).

CoreAudio et CoreMIDI sont techniquement des APIs "Carbon" qui collent parfaitement a ma description du paragraphe precedent.

Tu veux dire par là que ca se programme de la même façon du point de vue du dev? C'est plutot bien, non? Ca remet pas toutes les habitudes en question.

Les avantages de Cocoa :
- API moderne et orientée objet.

Moderne circa 1984, aussi. Ca vient du NeXT faut pas oublier. Ca traine autant de casseroles que n'importe quelle API qui se traine 20 ans derriere elle.

Et tu crois qu'en 20 ans ca a pas évolué? Sérieusement?
C'est pas pask'un truc est basé sur des concepts d'il y a 20 ans que ce n'est pas un bon modèle, ou pas un truc à suivre, AMHA... Y'a qu'à voir les revirements d'Apple et de Microsoft. Mais c'est un autre débat.

- Modèle graphique très performant (Quartz) issue de PDF.

Alors CA, ca me fait mal aux dents aussi tiens. Quartz est une grosse blague, qui est peut etre 'beau' mais ne fait pas beaucoup plus que Postscript il y a 10 ans. Aussi, il ne fait pas beaucoup plus que QuickDraw GX d'il y a 5 ans (d'ailleur, une grosse partie a etée recyclée de la)

C'est vrai que c'est le gros point faible actuel d'OS X, la réactivité du GUI! Si je comprend bien, quartz gère l'affichage 2D d'OS X, et son éventuelle optimisation? D'après toi, ça peut s'améliorer à l'avenir?
L'affichage est super clean par rapport à OS 9, c'est vrai, mais c'est aussi vrai que ça rame de façon hallucinante et anormale sur de petites configs... Et si c'est basé sur quickdraw (qui m'a jamais vraiment impressionné dans mes utilisations habituelles de l'ordi, perso), pourquoi est-ce si "lourd"? Même X-Window avec n'importe quel WM est plus réactif, et c'est pourtant pas un modèle de rapidité! Pourquoi?

Bref, Nico et Bus, vous prenez pas le choux, c'est normal que vous puissiez avoir des vues divergentes, mais n'entrez pas dans une guéguerre stérile sur quel kit de dev est meilleur, quelle API est meilleure, ou quel compilateur est meilleur, etc. etc., la majorité d'entre nous ici s'en fout! Facts, just facts :-)
On a la chance de vous voir participer sur MacMusic, alors vous tapez pas dessus les gars, on a besoin de vous, nous ;-) Qui sait qui va me tomber dessus dés que je dis une connerie, sinon?
:-D

Bye et surtout, Peace.

[Miss Kiki]

Bah, vous avez eut l'opportunité de bouger ca en forum Dev, hein :-)

En clair, ça veut dire quoi? Tu le bouges ou pas?

La Dame aux tongs vient de faire le nécessaire!

[nicotech]

je ne pensais pas en répondant à Yukulele créer une polémique.

D'abord je n'ai jamais laissé entendre que carbon était moins natif que Cocoa, au contraire.

De plus dire que CoreAudio et CoreMidi sont des API carbon n'est pas exact. Ce sont des API Mac OS X qui sont accessibles aussi bien depuis Carbon que Cocoa.

Cocoa n'est pas construit sur carbon, elles sont toute deux contruites sur une base commune.

Le choix de quartz basé sur PDF à été fait pour des raisons économiques car postcript donc DPS (Display Postcript) nécéssite le paiement d'une licence à Adobe. Effectivement il n'y a pas une grande différence de fonctionnalités.

Pour ce qui est du manque de réactivité, je suis d'accord maintenant on ne peut présager de l'avenir (sur le Next DPS était accéléré par un hardware spécifique basé sur le i860 intel).

N'étant pas un professionel du développement, je suis ingénieur du son avant tout, je serais intéréssé de savoir quelle API est moderne et bien conçu. Je ne connais que Mac OS 9 via Powerplant et un peu Cocoa qui me semble assez élégante.

Pour finir, "keep cool" BusError, il faut savoir être modéré pour être modérateur.

Amicalement,

nicotech.