Re: [PATCH] SND_SEQ_BLOCK and SND_SEQ_PORT_CAP_NONE defines

[Aldrin Martoq <amartoq@dcc.uchile.cl>]

On Fri, 2008-02-01 at 13:38 +0100, Takashi Iwai wrote:
> At Thu, 31 Jan 2008 14:42:42 -0300,
> Aldrin Martoq wrote:
> > Hey hackers,
> > While developing pyalsa sequencer API, I found that sometimes 0 is
> > used instead of a #defined value or constant.
> > In my opinion, given that the alsa API is opaque (hides internal
> > structure and provides methods for accessing them), we should define
> > those missing "constants" for being consistent. So far I found:
> > SND_SEQ_BLOCK 0 (blocking mode)
> > SND_SEQ_PORT_CAP_NONE (the port defines no access capabilites)
> Well, I myself don't mind to add such defintions, but remember that
> these flags are no enum but bits.  When you see BLOCK and NONBLOCK
> definitions, you'll likely think these are exclusive.  However,
> (BLOCK|NONBLOCK) or (NONE|READ) can be passed without problems.

I'm sorry, you are right and I was absolutely wrong. I thought mode is
something like an enumeration rather than a flag (I think still there is
a problem, for example there is no "change mode" api function, instead
there is a snd_seq_nonblock function ?!); the port cap type was clearly
a mistake.

I will correct this in the python version (remove this non-meaning
constants) and please forget my patch. Thanks,

-- 
Aldrin Martoq <amartoq@dcc.uchile.cl>