[Gambas-user] Gambas + Midi + ALSA + file descriptors

[Ru Vuott]

Hello Benoît,

I'ld like to recapitulate...


AIM:

*Receiving* Midi data FROM ALSA (rectius: FROM ALSA functions).


STRATEGY:

Putting the FD - *passed by ALSA* - under "observation" for Read by using a mechanism like:  hfile = OPEN...For....WATCH.
Normally the gambas-program sleeps, but when data come to that FD, and so it begins "ready", we'll have not to read data from FD (not from hfile !); the mechanism OPEN...etc... must awake the program and ''raise'' a gambas-event, as File_Read(). So, we'll read the right ad useful Midi data **FROM ALSA** by the special function: snd_seq_event_input(......).



> Is there a way for me to emulate a midi input so that I can
> actually run your project?

Yes, you can use "aplaymidi" program.
After run "aplaymidi", remember to allow the connection of my source TO aplaymidi, by writing the Id client number in special ALSA function:

err = snd_seq_connect_to(handle, outport, -->HERE<--, dport)

that you can find it in CAlsa.class of my source.


....But if you run my program, on its form you can send a midi data by pressing on the button "note".


I send you attached "aseqdump" Alsa program, purposely modified for verifing the FD thata it uses. You can compare the FD, used by it, with FD shown by lsof -p PID_of_program command, or strace -p PID command.

So, equally, you can compare the fd of my source. This fd is used by my program and passed by ALSA function to OPEN... etc line.

Regards
Paolo









--- Lun 26/9/11, Benoît Minisini <gambas at ...1...> ha scritto:

> Da: Benoît Minisini <gambas at ...1...>
> Oggetto: Re: [Gambas-user] Gambas + Midi + ALSA + file descriptors
> A: "mailing list for gambas users" <gambas-user at lists.sourceforge.net>
> Data: Lunedì 26 settembre 2011, 20:40
> > Hello Benoît,
> > 
> > I tried to put POLLOUT, but it doesn't change:
> 
> OK, but it couldn't work at all with POLLIN.
> 
> > 
> >  - a CPU always at 100%;
> >  - line OPEN "." & CStr(numfd) wants For
> WRITE, and the called sub-routine
> > wants File_Read(). - I can put File_Write() also, but
> so I have to put the
> > "no-blocking" Alsa function: 
> snd_seq_nonblock(handle, 1) in the calling
> > routine.
> > 
> > ...in short, no newness...
> > 
> > I'ld like remember the problem is the CPU working at
> 100%.
> > 
> > Regards
> > Paolo
> > 
> 
> You must understand that the 'Open ".xx"' feature I added
> relies on the same 
> code than any other file. I may have made a mistake, but
> it's unlucky.
> 
> Moreover, by reading your code, I don't understand what you
> are doing. You 
> want to watch a file descriptor for *writing*, and in the
> event handler, you 
> are *reading* on it. This not coherent at all, and I can't
> guess what you 
> really want to achieve.
> 
> The 100% CPU is a consequence of that mismatch : if you
> don't read during a 
> File_Read event handler, or if you don't write during a
> File_Write event 
> handler, the event will be raised again and again, eating
> all the CPU.
> 
> So, please explain better what you want to do, and we will
> find where the 
> confusion is.
> 
> Is there a way for me to emulate a midi input so that I can
> actually run your 
> project?
> 
> And can you send me your project each time you modify it so
> that I am sure to 
> use the code you are talking about?
> 
> Regards,
> 
> -- 
> Benoît Minisini
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT
> infrastructure contains a
> definitive record of customers, application performance,
> security
> threats, fraudulent activity and more. Splunk takes this
> data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aseqdump2
Type: application/octet-stream
Size: 14303 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20110927/888f4013/attachment.obj>