Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Ajouter ce produit à
  • Mon ancien matos
  • Mon matos actuel
  • Mon futur matos
Cycling'74 Max/MSP
Photos
1/35
Cycling'74 Max/MSP

Problème de son

  • 13 réponses
  • 4 participants
  • 2 896 vues
  • 4 followers
Sujet de la discussion Problème de son
Bonjour,

Debutant sur Max/MSP , et ayant quelques bases sur puredata je rencontre un problème sur Max/MSP que je n'arrive pas a surmonter.

En effet, je crée don comme premier patch un sampler basique (fiable parce que copié de tutoriel) et c'est a ce moment la que je me suis rendu compte du problème, je n'ai pas de son lorsque j'appuie sur 1 pour démarrer la lecture.

Je vais dans l'audiotester, plus rien non plus.

Je rallume Max/MSP , je vais dans l'audiotester, ça marche, je lance le sample, ah tiens ça marche, je l'arrete, je le relance, il n'est plus lu et j'ai a nouveau plus de son sur l'audiotester. Je suis donc obliger de redemarrer Max/MSP pour récuperer du son. Je pense avoir un soucis avec ma carte son qui est pourtant plutot fiable (edirol FA66), ou peut etre avec le buffer , mais e n'ai pas réussi a régler mon problème.

Pouvez vous m'aider ?
Afficher le sujet de la discussion
11
D'abord un tout grand merci pour votre aide!

Pour votre info:
voici ce que j'ai envoyé à Cycling 74 support
Bonjour,
je rencontre un problème de plantage chaque fois que je fais appel à une ressource audio (mic , HP) et ce uniquement avec MAX/MSP, quelle que soit la version.
Je n'ai aucun problème avec Pure Data , ProTools, Cubase, Ableton, Logic, Reason, Sonar, Camtasia, PAD, et tous mes logiciels et plugins son.
J'ai modifié les paramètres de buffer et les fréquences d'échantillonnage. J'ai éteint l'application après modification du set-up audio, mais après avoir relancé l'application, je vois
un disque multicolore qui n'en finit pas de tourner. Que je modifie le setup avant ou après le placement des objet DAC~ ou ADC~, ne change rien.
J'ai MAC OSX 10.8.2.
Pour ce qui est des autres objets , pas d soucis , mes patches fonctionnent.
Voir le problème sur Youtube.


Si vous avez des pistes, je reste à l'écoute.

Cordialement

Guy Verbruggen

12
par rapport à mon souci de plantage de max msp lors de manipulation d'objets son, 'ADC et DAC,
j'ai reçu une réponse de Cycling74 qui assure un super suivi:
voici leur réponse :

Hello,
I notice that in your audio settings you have your I/O Vector size set to 32 and your Sig Vector size set to 1.
This will cause the coreaudio hardware to stall, it is not really capable of such performance. Try changing them to 512/128
Cheers

J'ai modifié ces paramètres selon leurs indications et magie, magie! tout fonctionne à nouveau.
Par contre pour ce qui est de la compréhension de ces vecteurs...??? S'agit-il de buffers?
Je me documente et reviens vers vous si je trouve de quoi il s'agit , sinon, l'un d'entre vous a -t-il une piste?
Merci à tous.

Guy Verbruggen

13
voici un extrait de la doc : de MAX/MSP --> Tutorial :MSP Audio input and output


The I/O Vector Size may have an effect on latency and overall performance. A smaller vector size may reduce the inherent delay between audio input and audio output, because MSP has to perform calculations for a smaller chunk of time. On the other hand, there is an additional computational burden each time MSP prepares to calculate another vector (the next chunk of audio), so it is easier over-all for the processor to compute a larger vector. However, there is another side to this story. When MSP calculates a vector of audio, it does so in what is known as an interrupt. If MSP is running on your computer, whatever you happen to be doing (word processing, for example) is interrupted and an I/O vector's worth of audio is calculated and played. Then the computer returns to its normally scheduled program. If the vector size is large enough, the computer may get a bit behind and the audio output may start to click because the processing took longer than the computer expected. Reducing the I/O Vector Size may solve this problem, or it may not. On the other hand, if you try to generate too many interrupts, the computer will slow down trying to process them (saving what you are doing and starting another task is hard work). Therefore, you'll typically find the smaller I/O Vector Sizes consume a greater percentage of the computer's resources. Optimizing the performance of any particular signal network when you are close to the limit of your CPU's capability is a trial-and-error process. That's why MSP provides you with a choice of vector sizes.
Changing the vector sizes does not affect the actual quality of the audio itself, unlike changing the sampling rate, which affects the high frequency response. Changing the signal vector size won't have any effect on latency, and will have only a slight effect on overall performance (the larger the size, the more performance you can expect). However, certain types of algorithms benefit from a small signal vector size. For instance, the minimum delay you can get from MSP's delay line objects tapin~ and tapout~ is equal to the number of samples in one signal vector at the current sampling rate. ith a signal vector size of 64 at 44.1 kHz sampling rate, this is 1.45 milliseconds, while at a signal vector size of 1024, it is 23.22 milliseconds. The Signal Vector size in MSP can be set as low as 2 samples, and in most cases can go as high as the largest available I/O Vector Size for your audio driver. However, if the I/O Vector Size is not a power of 2, the maximum signal vector size is the largest power of 2 that divides evenly into the I/O vector size.

Guy Verbruggen

14
Ce sont effectivement des réglages de buffers.
De manière empirique... IL faut que tu te situes entre 128 et 512, pour un bon compromis qualité sonore non dégradée / latence acceptable. Pour les deux paramètres.