C++

Thread concurrency ? (OpenGL vs STK)

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Thread concurrency ? (OpenGL vs STK)

spinzero

Bonjour à tous :jap:

Débutant en C++, j'ai une animation (win32) OpenGL à laquelle j'essaie d'intégrer de la synthese sonore avec
la lib STK(http://ccrma.stanford.edu/software/stk/.(au passage, si vous connaissez autre chose, tournant sous windows... )

Mon problème vient du fait que le rendu graphique via une fonction glut:

main.cpp :

Code :

int main()
{
...
glutReshapeFunc(ReshapeCallback_1);
glutDisplayFunc(RenderCallback_1);
...
}

est bloqué pendant le calcul du son:

attack.cpp:

Code :

int Attack::tick( void *outputBuffer, void *inputBuffer, unsigned int nBufferFrames,
double streamTime, RtAudioStreamStatus status, void *dataPointer )
{
SineWave *sine = (SineWave *) dataPointer;
register StkFloat *samples = (StkFloat *) outputBuffer;
for ( unsigned int i=0; i<nBufferFrames; i++ )
*samples++ = sine->tick();
return 1;
}
//--------------------------------------------------------------------------------------------------------
bool Attack::play()
{
SineWave sine;
//- Figure out how many bytes in an StkFloat and setup the RtAudio stream.
RtAudio::StreamParameters p;
p.deviceId = dac.getDefaultOutputDevice();
p.nChannels = 1;//_o_->channel;
RtAudioFormat format = ( sizeof(StkFloat) == 8 ) ? RTAUDIO_FLOAT64 : RTAUDIO_FLOAT32;
//-The bufferFrames argument is an API-dependent buffering parameter (see RtAudio for further information).
unsigned int bufferFrames = RT_BUFFER_SIZE;//defined in Stk.h.
//--1) OPEN STREAM
try {
dac.openStream( &p, //RtAudio::StreamParameters *outputParameters,
NULL, //RtAudio::StreamParameters *inputParameters,
format, // RtAudioFormat format, unsigned int sampleRate
(unsigned int)Stk::sampleRate(), //unsigned int *bufferFrames
&bufferFrames, //RtAudioCallback callback, void *userData
&Attack::tick, //RtAudio::StreamOptions *options
(void *)&sine
);
}
catch ( RtError &error ) {
error.printMessage();
goto cleanup;
}
sine.setFrequency( _o_->frequency );
//--2) START STREAM
try {
dac.startStream();
}
catch ( RtError &error ) {
error.printMessage();
goto cleanup;
}
// Block waiting here.
/*char keyhit;
cout << "\nPlaying ... press <enter> to quit.\n";
cin.get( keyhit );
-> QUOI METTRE A LA PLACE (ci-dessus) ??
****************************************/
cleanup:
dac.closeStream();
//delete dac;
//_o_->func_killFM(_o_->id);
}

... qui semble utiliser une thread , concept que je n'ai pas encore abordé :heink:

Je suis donc parti d'un exemple(http://ccrma.stanford.edu/software/stk/crealtime.html) un Callback, dont une portion du code est en partie responsable du problème:

Code :

// Block waiting here.
char keyhit;
cout << "\nPlaying ... press <enter> to quit.\n";
cin.get( keyhit );

J'ai voulu remplacer cette partie par

Code :

return 1;

...pensant que le son continuerait à jouer mais cela provoque une erreur (error.printMessage(), qui ne s' affiche pas ) , enfin je crois :heink: puisque

Code :

goto cleanup

est aussitôt appelé !

Faudrait-il remplacer le code supprimé par autre chose ou bien est-ce la thread tick() qui pose problème ?

...sachant que Attack est une classe pouvant avoir de multiples instances...

Voilà, j'espère être assez clair
merci

ps: On m'a suggéré de mettre

Code :

return 1;

juste après startStream() , ou dans tick()
... ou encore de m'intéresser au concept de concurrency!??

Publicité

spinzero

Apparement ça n'emballe personne :-(

bjone

Insert booze to continue

D'après ce que j'en comprends et comme son nom semble l'indiquer RtAudio et juste une api bas-niveau temps-réel.
Donc:
- un flux de sortie pour tout le programme donc un openStream et un closeStream en début et fin de programme, hors boucle-temps réel

- ton callback de remplissage de buffer sera par la suite à remplacer par un callback de mixage avec sa petite machine à états et sa queue de buffers à mixer, on verra peut-être à ce moment pour le threading.

Dans ce cas il consisterai je pense à un thread de mixage qui fourni qui pousse un buffer en queue d'attente, et le callback passé à RtAudio qui vienne chercher les buffers mixés en queue.

Donc revois ta structure générale, parceque là c'est pas bon.

Pour moi tu devrais avoir un truc style:

Code :

int main()
{
my_zuper_audiomixing_engine.start(); // openStream
glutReshapeFunc(ReshapeCallback_1);
glutDisplayFunc(RenderCallback_1);
my_zuper_audiomixing_engine.close();
}

Quand tu sais que tu dois avoir un bruit, tu le mets en queue d'attente, et au prochain callback tu commence à le mixer avec les autres dans le buffer final qui sera passés aux dac par RtAudio.

Etant donné que tu sais pas où tu mets les pieds, je te conseillerai OpenAl ou autre une lib audio de plus haut-niveau pour avoir un truc qui te guide.
Même si par après pour ta culture générale tu peux très bien revenir sur un mixage complètement maison utilisant une API bas-niveau.

Message cité 1 fois
Message édité par bjone le 21-03-2009 à 12:41:06

spinzero

bjone a écrit :

...- un flux de sortie pour tout le programme donc un openStream et un closeStream en début et fin de programme, hors boucle-temps réel

C’est justement le rapport avec la boucle temps réel que je ne saisi pas. J’ai l’impression que, par rapport à ce que je recherche comme la génération et la modulation du son par rapport à des évènements graphiques (ex la rencontre aléatoire de 2 sphères), l’évènement sonore sort de cette boucle puisqu’une fois déclanché à partir de celle-ci, il se produit en dehors par le calcul de sa thread !?

Je dis surement des bêtises mais j’imagine dans mon cas le rôle de la Thread comme une sorte d’écouteur activé et désactivé par des évènements asynchrones (évènements physiques et graphiques)…

Par ailleurs j’ai cru comprendre qu’il fallait éviter d’ouvrir et de fermer systématiquement un stream, mais plutôt jouer sur le contenu d’un buffer circulaire qui pourrait être vide lorsqu’aucun son n’est joué …

bjone a écrit :

- ton callback de remplissage de buffer sera par la suite à remplacer par un callback de mixage avec sa petite machine à états et sa queue de buffers à mixer,

Mis à part ce que tu appelles la « machine à états et sa queue » j’ai 2 autres membres susceptibles de jouer ce rôle :

Code :

bool Attack::init()
{
pipe = new CircBufferNoLock(sizeof(_o_)*10);// buffer circulaire
return true;
}
//--------------------------------------------------------------------------------------------------------
//...lorsque la thread audio tourne, on met les données modifiés par les évènements graphiques...
void Attack::gui_callback(float u)
{
audioStruct->frequency = u;
//---( ! ) error C228 left of 'writeBuffer' must have a class/strut/inion !?
// pipe.writeBuffer(&_o_, sizeof(Attack_o));
}

bjone a écrit :

- on verra peut-être à ce moment pour le threading.

Que veux tu dire par threading, car le callback c’est bien l’aboutissement d’une thread non ?

bjone a écrit :

-Dans ce cas il consisterai je pense à un thread de mixage qui fourni qui pousse un buffer en queue d'attente, et le callback passé à RtAudio qui vienne chercher les buffers mixés en queue.

Dit comme ça, je n’demande pas mieux ;-)

bjone a écrit :

.
- Donc revois ta structure générale, parceque là c'est pas bon.

Pour l’instant la partie graphique et physique tourne bien. J’ai pensée à une classe principale (statique) pour les manip globales (gestion des canaux, effets) et à une classe dynamique représentant du son singulier. C’est le code du STK lui-même et la notion de thread qui me perdent encore.

Pour être plus précis sur ma structure générale j’ai:

Define.h // contient des déclaration d’entêtes et descriptions de structures utilisées ds les classes statiques et dynamiques

Une classe principale Engine déclarée dans le main, qui instancie les classes graphiques, physique et sonore dont les membres seront appelés dans une boucle glut :

Code :

glutDisplayFunc(RenderCallback_1);
void RenderCallback_1()
{
if (gScene && !bPause)
RunPhysics();
// Clear buffers
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
ProcessKeys();
GraphicCORE::updateBUTTONSAndSLIDERS();
PhysicCORE::updateCAMERA();
PhysicCORE::updateSHAPES();
PhysicCORE::updateLINES();
PhysicCORE::updateSTICKERS();
RenderScene(bShadows);
if( gSelectedActor != NULL ){
NxVec3 V= gSelectedActor->getGlobalPosition();
GraphicCORE::drawAXIS(V.x, V.y, V.z, 10.0F,8.0F,10.0F, 10.0F,6.0F,10.0F,"<X>","<Y>","<Z>" );
}
DisplayText();
gPerfRenderer.render(gScene->readProfileData(true), glutGet(GLUT_WINDOW_WIDTH), glutGet(GLUT_WINDOW_HEIGHT));
glutSwapBuffers();
//----------------------
//SoundCORE::render();
}

Comme je n’ai pas pu intégrer toutes mes classes respectives (image, physique…), certaines fonctions sont restées dans le main comme la boucle glut ou le gestionnaire de collisions physiques …

L'articulation des 2 classes, statique et dynamiques me semblait cohérentes jusqu'à ce qu'apparaissent les threads...d'ailleurs
on m'a conseillé de mettre

bjone a écrit :

my_zuper_audiomixing_engine.start(); // openStream

glutReshapeFunc(ReshapeCallback_1);
glutDisplayFunc(RenderCallback_1);

my_zuper_audiomixing_engine.close();
}

En imaginant que le Stream serait ouvert/fermer indépendamment, my_zuper_audiomixing_engine…() pourrait remplir le buffer de nouveaux paramètres audio ?

bjone a écrit :

Quand tu sais que tu dois avoir un bruit, tu le mets en queue d'attente,

A moins qu’il y est un exemple dans le STK je vais faire qlq recherches mais si tu as exemple de queue d'attente ...

bjone a écrit :

et au prochain callback tu commence à le mixer avec les autres dans le buffer final qui sera passés aux dac par RtAudio.

…si j’arrive au premier callback ;-)

bjone a écrit :

... je te conseillerai OpenAl ou autre une lib audio de plus haut-niveau pour avoir un truc qui te guide.

Je pensais que c'était plutôt pour jouer des sons (sampling) que de la synthèse sonore où tu travailles vraiment son signal...

bjone a écrit :

Même si par après pour ta culture générale tu peux très bien revenir sur un mixage complètement maison utilisant une API bas-niveau.

En fait, j'avais pensé que pour générer un son particulier, par ex une onde faite de plusieurs sinusoïdes modulées par une série de variables(ex : liste de positions) ce serait la meilleur alternative. Maintenant, je sais que ça me dépasse totalement cette histoire, d’autant plus que je commence le c++ très tard, mais bon je reste fasciné par le bas niveau et le plus grand degré de liberté qu'on peut en espérer. De plus, à défaut d'avoir pu suivre des cours, ce sont des gens comme toi qui permettent à d'autre de toucher des choses qu'ils n'aurait jamais eu l'occasion ou le courage...et blablabla, enfin voilà, en tout cas ton analyse m’éclaircit bien les idées et si mes précisions change ta vision du prob … poursuivons

bjone

Insert booze to continue

ton callback doit balayer une liste de sons actifs, et générer le buffer que RtAudio consommera.

ça veux dire qu'à l'initialisation de RtAudio, tu n'as qu'un seul openstream, un seul callback, et ce callback balaye une liste de sons que tu auras mis en queue lors de tes événements physiques & co.

ces sons auront comme propriétés, si tu veux mixer des sinus: fréquence, phase, amplitude, balance g/d, durée. (et pourquoi pas une enveloppe ADSR http://en.wikipedia.org/wiki/ADSR_envelope)

tu pousses les descripteurs de ces sons dans une collection qui sera prise en compte et actualisée par le callback.

par exemple quand le callback génére 20ms d'audio, tu retires 20ms de vie aux descripteurs, et supprimes ceux qui ont expirés.

Message cité 1 fois
Message édité par bjone le 22-03-2009 à 13:15:13

spinzero

Salut

bjone a écrit :

...tu pousses les descripteurs de ces sons dans une collection qui sera prise en compte et actualisée par le callback.

Les descripteurs seraient des Structures tandis que la collection pourrait être un Array ?
C'est ce que j'ai essayé de faire plus bas...
D'autre part, on m'a proposé d'utiliser un Buffer circulaire (CircBufferNoLock) mais je n'arrive pas à convertir une Structureen const unsigned char.

bjone a écrit :

... quand le callback génére 20ms d'audio, tu retires 20ms de vie aux descripteurs, et supprimes ceux qui ont expirés.

Tu t'y prendrais comment ?
Car si je devais vraiment utiliser CircBufferNoLock , je serais bien embêté pour le vider car il n'y a pas de membre prévu à cet effet; que:

Code :

bool writeBuffer(const unsigned char *data, unsigned int len)
bool readBuffer(unsigned char *data, unsigned int len)
unsigned int getSize();

Mon sound system modifié :

Code :

//------------
soundCORE.cpp :
//-------------
#include "SoundCORE.h"
static NxArray<Attack *>Attack_A;
int att_i = 0;
CircBufferNoLock* pipe;
RtAudio dac;
typedef struct {
float frequency;
float amplitude;
} control_data_t;
...
...
bool SoundCORE::init()
{
int t1 = 10;
pipe = new CircBufferNoLock(sizeof(control_data_t)*t1);
return true;
}
void SoundCORE::setRingBUFFER( int id )
{
//---Recherche la Struct relactive au dernier sons
Attack* fm = NULL;//getFM( id );
int t1 = Attack_A.size();
if( t1 != 0)
{
for(int i=0;i<t1;i++)
{
if( Attack_A[i]->_o_->id == id )
{
fm = Attack_A[i];
break;
}
}
}
//--- ajoute un son (Struct audio)
if( fm != NULL)
{
control_data_t data;
data.frequency = fm->_o_->frequency;
data.amplitude = .1;
/****************************************************
le 1er param de 'writeBuffer' n'accepte que des Const Unsigned Char
Comment convertir data ?
***************************************************/
bool pWritten = pipe->writeBuffer( &data, sizeof(control_data_t) );
}
}
int SoundCORE::tick( void *outputBuffer, void *inputBuffer, unsigned int nBufferFrames, double streamTime, RtAudioStreamStatus status, void *dataPointer )
{
//--- Tout les sons fm sont stockés dans l'array Attack_A
int t1 = Attack_A.size();
if( t1 != 0)
{
int j;
SineWave *sin = (SineWave *) dataPointer;
register StkFloat *samples = (StkFloat *) outputBuffer;
/*******************************************************
Comment adapter 'samples' en fonction des multiples sons (Attack) ?
C'est sans doute ici que 'pipe' devrait intervenir !?
********************************************************/
for ( unsigned int i=0; i<nBufferFrames; i++ )
{
for( j=0;j<t1;j++)
{
*samples++ = Attack_A[j]->TICK();
}
}
//-- à integrer ds la boucle ci-dessus
/*
Attack_o o;
float frequency;
if (pipe.readBuffer(&o, sizeof(Attack_o))
{
frequency = o->frequency;
}
*/
}
return 0;
}
//---------
Attack.cpp:
//---------
#include "Attack.h"
SineWave sine;
Attack::Attack( Attack_o * _o )
{
_o_ = _o;
sine.setFrequency( _o_->frequency );
SoundCORE::setRingBUFFER(_o_->id);
}
...
StkFloat Attack::TICK()
{
return sine.tick();
}
...

Message édité par spinzero le 23-03-2009 à 04:12:35

bjone

Insert booze to continue

Le buffer circulaire est une solution locale pour la gestion des buffers mixés.

Mais là tu pourrais ignorer cette problématique, vu que le callback te fourni déjà le buffer de sortie. (tout dépends si tu veux tourner avec quelques buffers d'avance ou pas au dépends de la latence).

Pour les descripteurs tu pousse un objet qui décrit ton son dans une collection, et le callback supprimera les sons expirés de cette collection.

Donc le choix de l'implémentation tu le fait, tu essayes tu vois.

Message cité 1 fois

spinzero

Salut Bjone

bjone a écrit :

Le buffer circulaire est une solution locale pour la gestion des buffers mixés.

Ah, je croyais qu'il ne pouvais y en avoir qu'un seul :??:

bjone a écrit :

Mais là tu pourrais ignorer cette problématique, vu que le callback te fourni déjà le buffer de sortie. .

bjone a écrit :

tout dépends si tu veux tourner avec quelques buffers d'avance ou pas au dépends de la latence.

très utile ! donc à voir plustard...

bjone a écrit :

Pour les descripteurs tu pousse un objet qui décrit ton son dans une collection, et le callback supprimera les sons expirés de cette collection.

Pour l'instant ce que je comprends, c'est que *samples est un float qui représente l'ensemble des sons.
Du coup j'ai pensé calculer mes sines en incrementant *samples dans une boucle qui récupère le calcul du son de chaque Attack :

Code :

int SoundCORE::tick( void *outputBuffer, void *inputBuffer, unsigned int nBufferFrames, double streamTime, RtAudioStreamStatus status, void *dataPointer )
{
register StkFloat *samples = (StkFloat *) outputBuffer;
TickData *data = (TickData *) dataPointer;
if( attack_T != 0 )
{
int i, counter, nTicks = (int) nBufferFrames;
while ( nTicks > 0 )
{
counter = min( nTicks, data->counter );
data->counter -= counter;
for( i=0; i<counter; i++)
{
*samples++ = attack_A[i]->TICK();
nTicks--;
}
}
}
return 0;
}

Ici, le Callback semble bien appeller chaque Attack, mais j'ai l'impression de n'entendre qu'en seul son.
La fréquence se régle pourtant sur la derniere Attack ?

ps: je me suis basé sur un exemple car cette boucle, qui me paraissait logique :

Code :

for ( unsigned int i=0; i<nBufferFrames; i++ ){
*samples++ = attack_A[j]->TICK();

...provoque une erreur l'allocation mémoire...

bjone

Insert booze to continue

A toi de traquer tes bugs.

Par contre pour l'instant tu n'itères pas sur ta liste de sons, tu n'en traite qu'un.

Message cité 1 fois

spinzero

bjone a écrit :

A toi de traquer tes bugs.

:jap:

bjone a écrit :

Par contre pour l'instant tu n'itères pas sur ta liste de sons, tu n'en traite qu'un.

Alors que fait ?:

Code :

*samples++ = attack_A[i]->TICK();

J'ai essayé d'intégrer une autre boucle :

Code :

...
TickData *data = (TickData *) dataPointer;
int i, j,counter, nTicks = (int) nBufferFrames;
while ( nTicks > 0 )
{
counter = min( nTicks, data->counter );
data->counter -= counter;
for( i=0; i<counter; i++)
{
for ( j=0; j<attack_T; j++ )
{
*samples++ = attack_A[j]->TICK();
nTicks--;
...

...mais c'est pas ça :sweat:
Comment ferais tu ?

Publicité

bjone

Insert booze to continue

*samples++ = ...

ça c'est pour remplir ton buffer de sortie, sample par sample.

mais par sample, tu dois sommer tes sinusoides.

Message cité 1 fois

spinzero

bjone a écrit :

*samples++ = ...ça c'est pour remplir ton buffer de sortie, sample par sample.

Ok, ça j'avais saisit

bjone a écrit :

... par sample, tu dois sommer tes sinusoides.

Sommer, sommer, je ne suis pas sûr de comprendre; les appeler tu veux dire !?
En tout cas je me suis posé une question dans le genre en observant l'exemple demo :

Code :

int tick( void *outputBuffer, void *inputBuffer, unsigned int nBufferFrames,
double streamTime, RtAudioStreamStatus status, void *dataPointer )
{
TickData *data = (TickData *) dataPointer;
register StkFloat sample, *samples = (StkFloat *) outputBuffer;
int counter, nTicks = (int) nBufferFrames;
while ( nTicks > 0 && !done ) {
if ( !data->haveMessage ) {
data->messager.popMessage( data->message );
if ( data->message.type > 0 ) {
data->counter = (long) (data->message.time * Stk::sampleRate());
data->haveMessage = true;
}
else
data->counter = DELTA_CONTROL_TICKS;
}
counter = min( nTicks, data->counter );
data->counter -= counter;
for ( int i=0; i<counter; i++ ) {
sample = data->volume * data->reverb->tick( data->voicer->tick() );
for ( unsigned int j=0; j<data->nWvOuts; j++ ) data->wvout[j]->tick(sample);
if ( data->realtime )
for ( int k=0; k<data->channels; k++ ) *samples++ = sample;
nTicks--;
}
if ( nTicks == 0 ) break;
// Process control messages.
if ( data->haveMessage ) processMessage( data );
}
return 0;
}}

Quand il n'y a pas tout les crochets je m'y perd un peu...enfin, par rapport à ce que tu me disais, la réponse semble être ici.Car en plus de *samples, il y a sample; soit un float pour le son global résultant et un autre pour chaque son lu
Enfin , je crois... donc à ma sauce ça donne:

Code :

for( i=0; i<counter; i++)
{
SineWave* sn = attack_A[i]->getSINE();
sample = data->volume * sn->tick();// ca paraît absurde d'appeller tick() ici !?
for ( unsigned int j=0; j<attack_T; j++ )
{
sn = attack_A[j]->getSINE();
// dans l'autre exemple tick() prend 'sample' comme argument, qui est un StkFrames
// mais ds mon cas SineWave ne possède pas de membre acceptant d'argument!
//
sn->tick();//sample;//frames;//
}
*samples++ = sample;
nTicks--;
}

ou encore :

Code :

for( i=0; i<counter; i++){
for ( unsigned int j=0; j<attack_T; j++ ){
sample = attack_A[j]->TICK();
}
*samples++ = sample;
nTicks--;
}

Mais bien sûr, c'est mauvais car je n'arrive pas à l'adapter dans le cas d'une sinWave :heink:

...au cas ou il y aurait une erreur ici, Attack.cpp:

Code :

#include "Attack.h"
SineWave sine;
Attack::Attack( Attack_o * _o )
{
_o_ = _o;
sine.setFrequency( _o_->frequency );
sine.addPhase(_o_->amplitude);
//SoundCORE::setBUFFER(_o_);
}
Attack::~Attack()
{
}
SineWave* Attack::getSINE()
{
return &sine;
}
StkFloat Attack::TICK()
{
//sine.setFrequency( _o_->frequency );
return sine.tick();
}
void Attack::TICK( const StkFrames& frames, unsigned int channel )
{
;// sine.tick( &frames );
}
void Attack::KILL()
{
SoundCORE::killFM( _o_->id );
}

Comme j'ai encore bcp à apprendre du c++, peux-tu être plus explicite qd tu dis 'sommer' ?

Message édité par spinzero le 27-03-2009 à 11:15:09

bjone

Insert booze to continue

Sommer: Si tu as plusieurs sons, comment tu crois qu'ils arrivent a tes oreilles ?

Au vu de ça:

Code :

sample = data->volume * data->reverb->tick( data->voicer->tick() );
for ( unsigned int j=0; j<data->nWvOuts; j++ )
data->wvout[j]->tick(sample);

Comme le port-salut, data->reverb doit être un objet qui permet de générer de la reverb en rééchantillonnant du son précrédent.

data->wvout[j]->tick(sample) doit certainement prendre un float & en paramètre, et cette boucle somme chaque son à l'échantillon final.

Message cité 1 fois

spinzero

Salut Bjone

bjone a écrit :

Sommer: Si tu as plusieurs sons, comment tu crois qu'ils arrivent a tes oreilles ?

En block, du saint esprit :ange:

bjone a écrit :

...de la reverb en rééchantillonnant du son précrédent.
data->wvout[j]->tick(sample) doit certainement prendre un float & en paramètre, ...

sample ne représente donc que la réverbe ?
Alors il ne me sert à rien, et en le supprimant je retombe sur ma dernière proposition:

Code :

for( i=0; i<counter; i++){
for ( unsigned int j=0; j<attack_T; j++ ){
sample = attack_A[j]->TICK();
}
*samples++ = sample;
nTicks--;
}

Message cité 1 fois

bjone

Insert booze to continue

spinzero a écrit :

Salut Bjone

spinzero a écrit :

En block, du saint esprit :ange:

spinzero a écrit :

sample ne représente donc que la réverbe ?
Alors il ne me sert à rien, et en le supprimant je retombe sur ma dernière proposition:

Code :

for( i=0; i<counter; i++){
for ( unsigned int j=0; j<attack_T; j++ ){
sample = attack_A[j]->TICK();
}
*samples++ = sample;
nTicks--;
}

regarde la fonction data->wvout[j]->tick(sample), tu sauras comment ils somment. (certainement un += )

Message cité 1 fois

spinzero

bjone a écrit :

regarde la fonction data->wvout[j]->tick(sample), tu sauras comment ils somment. (certainement un += )

Ben :

wvout.h:
...

Code :

// These abstract functions must be implemented in all subclasses.
// They are used to get around a C++ problem with overloaded virtual
// functions.
virtual void computeSample( const StkFloat sample ) = 0;

wvout.cpp:

Code :

...
void WvOut :: tick( const StkFloat sample )
{
this->computeSample( sample );
}

Donc computeSample est implémenté d'une manière différente dans chaque ss classe que sont les instruments comme Clarinet, Flute...

Dans mon cas, computeSample de sineWave prend un void en argument:

Code :

StkFloat SineWave :: computeSample( void )
{
// Check limits of time address ... if necessary, recalculate modulo
// TABLE_SIZE.
while ( time_ < 0.0 )
time_ += TABLE_SIZE;
while ( time_ >= TABLE_SIZE )
time_ -= TABLE_SIZE;
StkFloat tyme;
if ( phaseOffset_ ) {
tyme = time_ + phaseOffset_;
while ( tyme < 0.0 )
tyme += TABLE_SIZE;
while ( tyme >= TABLE_SIZE )
tyme -= TABLE_SIZE;
}
else {
tyme = time_;
}
lastOutput_ = table_.interpolate( tyme );
// Increment time, which can be negative.
time_ += rate_;
return lastOutput_;
}

Ce que j'vois, c'est qu'il boucle sur une plage de valeures table , c-à-d un échantillon de base calculé lors de l'initialisation :

Code :

...
SineWave :: SineWave( void )
: time_(0.0), rate_(1.0), phaseOffset_(0.0)
{
if ( table_.empty() ) {
table_.resize( TABLE_SIZE + 1, 1 );
StkFloat temp = 1.0 / TABLE_SIZE;
for ( unsigned long i=0; i<=TABLE_SIZE; i++ )
table_ = sin( TWO_PI * i * temp );
}
Stk::addSampleRateAlert( this );
}
...

Donc si c'est bien ce que tu voulais dire par [i]Sommer ,
j'ai l'impression qu'ici on ne peut pas ajouter d'effets ou autres traitements ?
De toute façon tout ce que je cherche pour l'instant c'est de faire tourner ensemble ces échantillons...
Alors pourquoi

Code :

sample = attack_A[j]->TICK();

...ne suffit pas ?

Par ailleurs SineWave::computeSample est un membre protégé, accessible uniquement par la fonction tick() , prenant elle aussi un void en argument, hérité de la classe Generator:

generator.h:

Code :

...
//! Compute one sample and output.
StkFloat tick( void );
//! Fill a channel of the StkFrames object with computed outputs.
/*!
The \c channel argument should be zero or greater (the first
channel is specified by 0). An StkError will be thrown if the \c
channel argument is equal to or greater than the number of
channels in the StkFrames object.
*/
StkFrames& tick( StkFrames& frames, unsigned int channel = 0 );
protected:
// This abstract function must be implemented in all subclasses.
// It is used to get around a C++ problem with overloaded virtual
// functions.
virtual StkFloat computeSample( void ) = 0;
StkFloat lastOutput_;

Message édité par spinzero le 28-03-2009 à 21:26:37

spinzero

Yep

Finallement j'en suis arrivé à :

Code :

for ( unsigned int i=0; i<nBufferFrames; i++ )
{
*samples = 0;
for( int j=0;j<t1;j++)
{
*samples += Attack_A[j]->TICK();
}
samples++;
}

J'ai l'impression que l'on somme bien ici toutes les sines :whistle:
Mais à l'oreille ... :non:
je n'entends que la dernière tonalité; chaque sine ayant une fréquence supérieure à l'antécédente, de manière à pouvoir les distinguer...

Ce qui m'intrigue c'est que je sais pas si ça vient de mon callback audio (ci-dessus) ou des Attacks, qui renvoient pourtant des ticks() différents ??

}

Message édité par spinzero le 02-04-2009 à 12:08:12

bjone

Insert booze to continue

Là je sais pas a toi de voir.

Tu écrêtes probablement, je suppose que RtAudio attends un buffer normalisé, donc ça clippe peut-être.

divise sample par le nombre d'ondes cumulées ou un truc du genre.

spinzero

Oui, ça règle le problème du volume sonore qui dépassait la bande passante,
thank's doctor

Code :

*samples /= attack_T
samples++;

Quand au problème de l'addition foireuse des ondes,
je pense enfin savoir d'où ca vient :pt1cable:

En fait si j'utilise, pour commencer, un simple tableau[3] dans la classe qui gère le buffer,
les trois première sines tournent correctement :bounce:
...petit hic, je n'arrive pas à étendre la capacité de mon tableau.

Code :

NxArray<Attack *>Attack_A;
SineWave inputs[1];
void SoundCORE::genFM( ...)
{
Attack_o* o = new Attack_o;
o->id = att_i;
o->frequency= 220.0 * (attack_T+1) ;
...
Attack * m = new Attack( o );
Attack_A.push_back( m );
attack_T = Attack_A.size();
att_i++;
//--- Redéfinit foireuse de la taille du tableau
inputs[attack_T];
inputs[attack_T].setFrequency( 220.0 * (attack_T+1) );
}
int SoundCORE::tick( ... )
{
...
...
for( int j=0;j<t1;j++)
{
//--A) Attack Class
*samples += Attack_A[j]->TICK(); // foireux, seule la dernière sine joue
//--B) Ici même
*samples +=inputs[j].tick(); // super, les ondes s'ajoutent ;-)
}

Donc le problème doit venir de ma manière d'implémenter la classe Attack ...

...ah, finallement l'erreur venait du fait que j'avais pas déclaré SineWave ds le .h d'Attack, c'est tout :lol:
Donc les 2 fonctionnent très bien !!!

Message édité par spinzero le 03-04-2009 à 10:33:56

bjone

Insert booze to continue

alors bouquine ça:
std::vector<>, boost::shared_ptr<>, boost::ptr_vector<>, etc..
faut que tu bosses les collections et autre trucs objet en c++, ça va t'aider a refactoriser ton bousin

accessoirement les NxArray<> c'est une solution, mais avoir une dépendance au moteur physique dans l'audio, c'est un peu gore

Message cité 2 fois
Message édité par bjone le 03-04-2009 à 11:57:12

spinzero

bjone a écrit :

alors bouquine ça:
std::vector<>, boost::shared_ptr<>, boost::ptr_vector<>, etc..
... bosses les collections et autre trucs objet en c++, ça va t'aider a refactoriser ton bousin

Aah, Boost ..!
J'avais pas encore osé mettre de nez dedans...mais l'heure est venue :jap:

bjone a écrit :

... les NxArray<> ... une dépendance ...un peu gore

Aah l'élégance, c'est pas mon fort

ps: merci, merci, merci pour tes conseils; ça booooste !

Message édité par spinzero le 03-04-2009 à 18:49:01

bjone

Insert booze to continue

bin c'est pas interdit de l'utiliser le NxArray, c'est juste un std::vector<>-like de PhysX, mais bon dans l'audio

Message cité 1 fois

spinzero

bjone a écrit :

bin c'est pas interdit de l'utiliser le NxArray, c'est juste un std::vector<>-like de PhysX, mais bon dans l'audio

Oui bien sûr, mais tu me diras " pensez modules indépendants"

spinzero

bjone a écrit :

alors bouquine ça:
std::vector<>, boost::shared_ptr<>, boost::ptr_vector<>, etc..

Salut

Voici (http://www.exitframe.net/stk_sample/stk_gl.zip)un exemple utilisant openGl et stk-4.4.0, qui compile sous VC++2005. Pourriez vous y jeter un oeil SVP ?
Le programme plante 3/5 au moment où l'on crée un son :??:
Le code est sans doute maladroit mais je ne trouve pas d'où ça vient...le problème ne doit en tout cas pas venir du type de tableau utilisé.

ps: depuis que j'ai potassé les smart pointer j'ai pu faire un teste avec shared_ptr d'après un exemple( http://arb.developpez.com/c++/raii/shared_ptr/ )mais l'accès au membres de ma classe Attack est plus délicat...enfin j'ai pas encore bien saisit la manip :sweat:
J'ai récemment découvert ptr_vector après être passé de la version 1.38 à 1.39 -d'ailleurs où est passé le folder lib ds la nouvelle version???- , je n'ai pas encore réussi à l'implémenter mais il semble qu'il soit déconseillé pour la désallocation contrairement au vector classique, donc inutile si je veux pouvoir vider mon tableau !? finallement est-ce qu'un simple array ne serait pas plus efficace ?

merci

Message édité par spinzero le 01-06-2009 à 15:07:03

Publicité

FORUM HardWare.fr

Programmation

C++

Thread concurrency ? (OpenGL vs STK)

Sujets relatifs
Besoin d'aide OpenGL/GLUT	erreur avec le thread
thread-safety et buffers	[C / OpenGL] Comment faire un deplacement libre (si possible: freefly
[GLSL OPENGL] Light Culling pour une maison	[RESOLU] Probleme synchro thread
inserer un personnage dans openGL	Cmt répartir les sorties de différents thread sur différents terminaux
Thread JAVA	Passer un tableau 2D vers un thread
Plus de sujets relatifs à : Thread concurrency ? (OpenGL vs STK)

Page générée en 0.196 secondes