On Thu, May 02, 2019 at 02:51:08PM +0200, Raphael Graf wrote:
> On Fri, Apr 05, 2019 at 10:40:18PM +0200, Alexandre Ratchov wrote:
> > On Thu, Apr 04, 2019 at 02:40:19PM +0200, Raphael Graf wrote:
> > > The attached diff adds input support to portmidi.
> > > For each open input device, a thread is started, waiting for input using
> > > poll(2).
> > >
> > > The following program can be used for testing input and ouput:
> > > /usr/ports/pobj/portmidi-217/build-amd64/Release/test
> > > (it is not installed by the port)
> > >
> > > If I understand the API correctly, portmidi is not a good choice for
> > > realtime
> > > midi-input. There is no callback functionality for reading, so
> > > busy-waiting is
> > > needed, like this:
> > >
> > > while (Pm_Poll(midi)) {
> > > Pm_Read(midi, buffer, 1);
> > > }
> > >
> >
> > Thank you very much for your update.
> >
> > I've never used portmidi, but this lack of multiplexing forces the
> > caller to also start a thread (per device) and we'd end up with two
> > threads per device!
> >
> > > (see
> > > http://portmedia.sourceforge.net/portmidi/doxygen/group__grp__io.html)
> > >
> > > Currently, audacity is the only user of portmidi, only using it for
> > > output.
> > > .. so I'm not sure how useful this diff is ;)
> >
> > I remember having tried few times to download & build midi programs
> > until I notice they depend on portmidi. Now I can try again :-)
> >
> > >
> > > Any comments or ok?
> > >
> >
> > few comments about the midi bits below:
>
> Thank you, attached is a new diff, see comments below.
>
> I have tested it using portmidi's test-programs 'test' and 'sysex'.
> For testing, I have also enabled portmidi in audio/mscore and audio/hydrogen
> where it seems to work fine.
>
Looks fine.
ok ratchov@
