[alsa-devel] [PATCH] amidi: add delay option

Felipe Ferreri Tonello eu at felipetonello.com
Fri Aug 12 13:56:10 CEST 2016


Hi Clemens,

On 12/08/16 12:38, Clemens Ladisch wrote:
> Felipe Ferreri Tonello wrote:
>> On 12/08/16 08:10, Clemens Ladisch wrote:
>>> Felipe F. Tonello wrote:
>>>> +	case 0xf4:
>>>> +	case 0xf5:
>>>> +		return 0; /* ignore */
>>>> +	case 0xf7:
>>>> +		return 0; /* ignore */
>>>
>>> Silent data loss is bad.
>>
>> What do you mean by that?
> 
> When you want to send the byte F5, this code will silently drop it.

I see your point, you are right. Although, as we know, the underlying
driver won't send this byte anyway, but that is not for the application
to decide.

> 
>>>> +	case 0x00 ... 0x7f:
>>>> +		return rstate_len ?: rstate_len - 1;
>>>
>>> rstate_len - 1 == -1
>>
>> ?
>>
>> That's why there is this condition, if rstate_len is zero, than it
>> returns 0.
> 
> There is not need to use rstate_len when its value is already known and
> does not affect the computation; it could just be written as:
> 
>         return rstate_len ?: -1;

Right, that was not the original intent, so this code was actually
wrong. But I will remove it anyway based on your comment below.

> 
>>> The most robust way to find message boundaries probably would be a state
>>> machine.  However, there is actually no requirement to find all message
>>> boundaries; the _actual_ requirement is to insert pauses between SysEx
>>> messages.  So don't bother to try to parse everything; just search for
>>> F0 or F7.
>>
>> Well, I tough it would be useful to work in any type of MIDI message not
>> just SysEx.
> 
> But there is no _actual_ use case, where somebody actually needed it.
> And as shown by all those problems, handling all types of messages makes
> the code too complex.

True. So I will make sure to add this to the documentation.

-- 
Felipe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x92698E6A.asc
Type: application/pgp-keys
Size: 7195 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20160812/ad01b86d/attachment.bin>


More information about the Alsa-devel mailing list