fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Auto-connect ALSA MIDI input patch


From: Tommaso Cucinotta
Subject: Re: [fluid-dev] Auto-connect ALSA MIDI input patch
Date: Thu, 5 May 2016 01:12:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

Hi,

I'd be happy to see this integrated into some future release of fluidsynth if 
others find it useful, please, let me know if/what I can do, in order to get 
there. I have also created an associated TT where I attached my current patch:

  https://sourceforge.net/p/fluidsynth/tickets/158/

Thanks,

        T.

On 05/03/2016 09:12 AM, Tommaso Cucinotta wrote:
> Hi RL,
> 
> thanks for the comments!
> 
> You can find attached a refined patch, with the meaningless comments removed 
> :-), and the new option disabled by default.
> 
> I kept the alloca() for now, just as it clears the memory, it seems a common 
> paradigm across alsa utils and tutorials (eg, aconnect.c, where I took 
> inspiration for the patch), it doesn't seem a huge in-stack allocation, and 
> keeps code a bit simpler than real allocations. Though, if this really hurts, 
> I can change it to using FLUID_MALLOC() and FLUID_MEMSET, checking for OOM 
> etc.... just let me know what's best for the current code base.
> 
> Thanks,
> 
>       T.
> 
> On 05/03/2016 01:42 AM, R.L. Horn wrote:
>> On Mon, 2 May 2016, Tommaso Cucinotta wrote:
>>
>>> So I worked out the attached patch that adds a bool setting for 
>>> auto-connecting ALSA MIDI inputs. This is the dual of the "Auto-connect 
>>> JACK outputs" already there in fluidsynth/QSynth.
>>
>>> Feel free to try out the attached patch, and please, share your 
>>> comments/thoughts!
>>
>> I've only glanced over it, but the alloca()s and assert()s jumped right out. 
>>  The X != NULL assertion is pretty much meaningless after an alloca() and it 
>> looks like NDEBUG is normally defined anyway.
>>
>> Besides, there's no good reason to use alloca() there (there are very few 
>> good reasons for using alloca() generally), especially as you've already 
>> seen to freeing the variables (and commenting it out because, of course, it 
>> segfaults).  Use the corresponding malloc() functions instead.  And tedious 
>> old conditionals to check the return values.
>>
>> Other than that, it looks fairly sound.
>>
>> _______________________________________________
>> fluid-dev mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>>
> 
> 
> 
> 
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
> 


-- 
Tommaso Cucinotta, Computer Engineering PhD
Associate Professor at the Real-Time Systems Laboratory (ReTiS)
Scuola Superiore Sant'Anna, Pisa, Italy
http://retis.sssup.it/people/tommaso



reply via email to

[Prev in Thread] Current Thread [Next in Thread]