Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Ajouter ce produit à
  • Mon ancien matos
  • Mon matos actuel
  • Mon futur matos
Native Instruments Maschine 2 Software
Photos
1/104
Native Instruments Maschine 2 Software

Séquenceur électro de la marque Native Instruments appartenant à la série Maschine

8/10

réactions à la news Maschine passe en version 2.6

  • 112 réponses
  • 21 participants
  • 7 755 vues
  • 22 followers
Sujet de la discussion Maschine passe en version 2.6
Native Instruments met à disposition des détenteurs des Maschine Studio, MK1, MK2 et Mikro la version 2.6 du logiciel.

Lire la news
 


Ce thread a été créé automatiquement suite à la publication d'une news pour ce produit. N'hésitez pas à poster vos commentaires ici !
Afficher le sujet de la discussion
71
Et actuellement tu utilises quoi ? Je fais mon curieux

[ Dernière édition du message le 28/02/2017 à 14:16:43 ]

72
Celui de Melda. Il marche bien est facile et dispose de quelques options pratiques comme des vu-mètres.
73
Ok freeware en +. Cool
74

Moi perso j'utilise Wavelab et j'enregistre ma sortie de console dans 90% des cas.

Amha, si c'est implémenté, on pourra tout simplement créer un groupe qui puisse fonctionner en linéaire et non par patterns et on mettra dans ses sounds ce qu'on veut, audio ou MIDI.

Oui, ce serait déjà très pratique et sans doute pas trop compliqué à mettre en place.

Tant qu'il y aura des couilles en or, il y aura des lames en acier

75
Pour avoir travaillé des années dans l'informatique, puis pour travailler depuis des années pour un site web, je me méfie toujours du "pas trop compliqué" quand il s'agit de développement de programmes, surtout quand ça ne vient pas d'un membre de l'équipe de développement. :-D
76

Le sans doute se veut peut-être icon_bravo.gif

Tant qu'il y aura des couilles en or, il y aura des lames en acier

77
x
Hors sujet :
Pour ceux qui ne fréquentent pas le monde du développement, il m'est arrivé de demander des trucs que je croyais hyper simples à faire et dont on m'expliquait que c'était super difficile, long ou complexe et, inversement, de demander s'il serait éventuellement possible un jour d'imaginer trouver le temps de faire tel ou tel truc que je croyais complexe et qu'on me réponde "j'en ai pour 5 mn, je te fais ça tout de suite".
Et ceci aussi bien quand je bossais en SSII sur de l'informatique de gestion que chez AF à propos de dev web.

A la brève époque où j'ai moi aussi développé, j'ai pu voir que des demandes qui semblaient super simples au client représentaient beaucoup de boulot alors que des features assez conséquentes pouvaient parfois se développer facilement et rapidement.

C'est pour ça que je me méfie beaucoup des commentaires du genre "ça ne serait pas sorcier de faire ça".

On l'a encore vu récemment avec les gens qui râlaient contre les limitations des synthés boutique de chez Roland pour cause de ressources processeur (notamment polyphonie) : beaucoup de monde déclarait qu'ils auraient pu "simplement" mettre un proc de plus pour augmenter la polyphonie sans que ça coûte trop cher.
Jusqu'à ce que quelqu'un donne les propos d'un concepteur de synthé qui expliquait très clairement que la gestion des ressources sur plusieurs DSP simultanément était un gros bordel long et compliqué à développer et, si ma mémoire est bonne, ayant des incidences dans un peu toutes les zones du programme.
78

Citation de : Will Zégal

Hors sujet :
On l'a encore vu récemment avec les gens qui râlaient contre les limitations des synthés boutique de chez Roland pour cause de ressources processeur (notamment polyphonie) : beaucoup de monde déclarait qu'ils auraient pu "simplement" mettre un proc de plus pour augmenter la polyphonie sans que ça coûte trop cher.
Jusqu'à ce que quelqu'un donne les propos d'un concepteur de synthé qui expliquait très clairement que la gestion des ressources sur plusieurs DSP simultanément était un gros bordel long et compliqué à développer et, si ma mémoire est bonne, ayant des incidences dans un peu toutes les zones du programme.

 ça dé pend du proc/dsp, mais avec certain de ceux-ci, et selon leur programmation, de la puissance en plus suffit pour plus de polyphonie (par ex DSP sharc de la plateform Scope qu'on pouvait augmenter en ajoutant des cartes et avoir plein de polyphonie - ou comme uad dans une certaine mesure). 

Pour le hard ça dépend de la marque (sharc ne fonctionne pas comme motorola du tout par ex), et de l'os. Par ex, sur une sonic core Xite, on peut "fixer" certaines parties du circuit et ça ne bougera plus, alors que pour d'autres design , l'assignation est libre. En général, on fixe sur DSP  pour éviter d'éventuels problèmes de phase, ou bien parcequ'on veut attribuer une puissance fixée d'avance à un process donné (sans compter le fait qu'il faut parfois des dsp rien que pour gerer plein d'autres  dsp :-) ) . Mais là aussi il y a des limitations hardware (d'ou l'utilisation de dsp ancienne et nouvelles génération en même temps, par exemple et pour faire vite). par ex, je sais pour xite, le "génie"  se trouve dans la gestion dynamique des entrées/sortie de chaque processeurs, c'est de l'architecture et de la programmation. 

Donc, même si ce que je dis n'est pas toujours valable et selon les possibilités techniques des proc/dsp (nombre d'entrées/sorties, existence d'une RAM suffisante etc etc ) faut aussi comprendre que la musique n'est qu'un client parmis tout un tas d'autres appli et que les fabricants de dsp/proc spécialisés ne s'interessent pas forcément au marché de la zic car ils ont des clients plus important pour eux, et ils ne vont pas modifier leurs produits rien que pour la zic. donc le soucis des fabricants peut simplement être de "faire avec" . On peut faire beaucoup, mais ça a aussi un prix. 

je parle de Scope/Xite car c'est un très bon exemple en fait, même si je ne pense pas que roland utilise la même chose (ils ont peut être des trucs à eux avec d'autres limitations, ou peut être simplement qu'ils veulent vendre  plus de machines vu qu'on peut les cascader pour plus de polyphonie si j'ai bien compris, tout en proposant l'unité de base à pas cher du tout! 300 euros c'est quand même une prouesse dans ce monde là non?). Donc, des choix a faire, et parfois c'est réussi, et d'autres fois c'est raté (par rapport aux attentes des utilisateurs) ....

 

Dans le cas de maschine, je suppose que native instrument sait parfaitement comment réaliser une piste audio avec un play et un stop  :-) maintenant, comment l'inserer parrallèlement aux scenes, l'intégrer dans un workflow utilisateur, c'est là la vraie reflexion: je pense que n'importe qui peut imaginer que les scènes qui s'enchainent, c'est une une chose, mais que une piste audio qui doit démarrer à tel sample précis selon la scène ou l'on est, le tempo, les patterns (si on y reflechit un peu, les pattern hors scènes+piste audio, c'est un peu la m.... niveau organisation, ça veut dire que l'audio ne peut être qu'au niveau des scènes...) , effets, que sais je encore... c'est encore une autre chose.

 c'est peut être pas sorcier, mais ça doit demander des ressources humaine et du temps. sans compter que la moitié des utilisateurs s'en fichent bien de la piste audio, et preferent d'autres choses (il n'y a qu'à voir sur leur forum sur le sujet concernant la MPC ou les pistes audios, c'est un peu la baston ;-) ) ). Donc, surement aussi une histoire de priorités dans le but de satisfaire les demandes les plus pressantes/annciennes en premier. MAschine a quand même beaucoup évolué depuis la première version qui était deja bien avancée.

d'ailleurs, il me semblait avoir vu que c'était prévu sur leur forum, mais je ne suis pas sur d'avoir bien compris, dans le sujet concernant le nouveau workflow qui est mis en place pour les arrangements et qui demande pas mal de reflexion et de tests d'usabilité avant de passer à la moindre programmation. 

Donc à mon avis, surtout une question de temps.

 

[/fin de hors sujet]

 

 

 

 

[ Dernière édition du message le 01/03/2017 à 20:39:09 ]

79
+1

Il n'est pas impossible que le temps de développement sur Maschine soit impacté par le temps passer à penser et vérifier l'ergonomie des fonctions qu'à programmer.

D'ailleurs, on peut reconnaître qu'ils font assez fort : quand on voit tout ce qui a été rajouté et qu'on peut toujours faire avec un contrôleur MKI sorti il y a bientôt 7 ans ! :8O:
80
Citation de Will :
+1

Il n'est pas impossible que le temps de développement sur Maschine soit impacté par le temps passer à penser et vérifier l'ergonomie des fonctions qu'à programmer.

D'ailleurs, on peut reconnaître qu'ils font assez fort : quand on voit tout ce qui a été rajouté et qu'on peut toujours faire avec un contrôleur MKI sorti il y a bientôt 7 ans ! :8O:


Éh oui tu as vu juste, dans le développement (je suis dev dans d'autres domaines) la rétro-compatibilité avec l'existant (super chiant), et l'ergonomie sont 2 facteurs qui bouffent énormément de temps.