Differenze tra le versioni di "Alsa e Gambas: Gestione dei dati Midi in Ricezione"

Da Gambas-it.org - Wikipedia.
(Introduzione)
(Introduzione)
Riga 9: Riga 9:
 
<P>Questa circostanza renderà necessario l'uso della funzione Timer che provvederà a scatenare l'evento della Lettura della porta.</p>
 
<P>Questa circostanza renderà necessario l'uso della funzione Timer che provvederà a scatenare l'evento della Lettura della porta.</p>
 
Purtroppo l'approccio del timer non è del tutto opportuno. Anche pensando a un timer con scadenza molto stretta, per esempio un millisecondo, l'idea non è conveniente, anche se più o meno può funzionare. La soluzione più corretta sarerbbe mediante un ''Callback'' (che in Gambas dovrebbe essere stato finalmente supportato), ma che ALSA purtroppo non è in grado invocare, quando arriva un evento. La funzione ''Callback'' dovrebbe semplicemente alzare un evento (''RAISE xxx''), che poi esegue la lettura da ALSA e gestisce quanto ricevuto.
 
Purtroppo l'approccio del timer non è del tutto opportuno. Anche pensando a un timer con scadenza molto stretta, per esempio un millisecondo, l'idea non è conveniente, anche se più o meno può funzionare. La soluzione più corretta sarerbbe mediante un ''Callback'' (che in Gambas dovrebbe essere stato finalmente supportato), ma che ALSA purtroppo non è in grado invocare, quando arriva un evento. La funzione ''Callback'' dovrebbe semplicemente alzare un evento (''RAISE xxx''), che poi esegue la lettura da ALSA e gestisce quanto ricevuto.
<P>Allora, come soluzione iniziale, anche ricordando il nostro approccio didattico, useremo un timer, accettando l'inevitabile latenza. Se nell'evento timer si troverà qualche dato da leggere si alzerà (''RAISE'') un evento di Gambas per andare a gestire la cosa.</p>
+
<P>Allora, come soluzione iniziale, anche ricordando il nostro approccio didattico, useremo un timer, accettando l'inevitabile latenza. Se nell'evento timer si troverà qualche dato da leggere si alzerà (''RAISE'') un evento di Gambas per andare a gestire il da farsi. Il RAISE, insomma, genererà un evento per far sì che sia il programma principale a decidere che cosa fare. </p>
  
  
  
 
<<<FONT Color= "red"> Pagina in costruzione </font>>>
 
<<<FONT Color= "red"> Pagina in costruzione </font>>>

Versione delle 08:43, 30 ago 2011

Nei capitoli precedenti abbiamo considerato l'argomento dell'Invio dei dati Midi con Gambas 3 ad ALSA; ora prendiamo in considerazione la gestione dei dati in Ricezione da un device esterno al nostro applicativo.

Introduzione

La situazione è la seguente:
Il dispositivo esterno invia un dato alla porta del nostro applicativo, la quale dovrà essere posta dunque in modalità Write (tenuto conto che la si deve pensare "dal punto di vista dell'altro device"). Il dato, giunto alla porta dell'applicativo, non sarà però accolto automaticamente dal programma, ma questo - per poterlo acquisire - dovrà andare a leggere la porta.
Il problema più grosso è che però l'applicativo - ovviamente - non conosce il momento esatto in cui il dato sarà scritto, cioè inviato alla sua porta; e pertanto non sa quando deve leggere la propria porta per acquisire il dato inviato.

Questa circostanza renderà necessario l'uso della funzione Timer che provvederà a scatenare l'evento della Lettura della porta.

Purtroppo l'approccio del timer non è del tutto opportuno. Anche pensando a un timer con scadenza molto stretta, per esempio un millisecondo, l'idea non è conveniente, anche se più o meno può funzionare. La soluzione più corretta sarerbbe mediante un Callback (che in Gambas dovrebbe essere stato finalmente supportato), ma che ALSA purtroppo non è in grado invocare, quando arriva un evento. La funzione Callback dovrebbe semplicemente alzare un evento (RAISE xxx), che poi esegue la lettura da ALSA e gestisce quanto ricevuto.

Allora, come soluzione iniziale, anche ricordando il nostro approccio didattico, useremo un timer, accettando l'inevitabile latenza. Se nell'evento timer si troverà qualche dato da leggere si alzerà (RAISE) un evento di Gambas per andare a gestire il da farsi. Il RAISE, insomma, genererà un evento per far sì che sia il programma principale a decidere che cosa fare.


<< Pagina in costruzione >>