Re: [Linuxsampler-devel] [linuxsampler] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hi Rui,

It looks like the problem you described with CREATE MIDI_INPUT DEVICE 
not taking any parameters is twofold. First issue is not C++, it's just 
that i forgot to include that syntax in lscp.y :)
I can't check it in right now because i'm still cleaning up something in 
the same file for multiple connections . . . as soon as i'm done with 
that i'll check this fix in. Maybe even tonight.

But . . . that would be too easy :)
I've also found something about parameters that i dislike. It's generic 
issue with all parameters, not midi related.
Basically, they have parameterized and a default constructor that calls 
InitDefault to set the value. It is expected that the underlying things 
will be done to match the default setting of a parameter.
for example, when you create MIDI_INPUT_DEVICE parameter active is 
defaulted to true.
InitDefault() will set the parameter value and Sampler.cpp will then 
make the device to listen, so it matches the default.
Problem is, if i create MIDI_INPUT_DEVICE and specify that i want active 
to be false, parameter is set to false but Sampler.cpp is not going to 
care so it will still make the device listen.
If the default were set to false and Sampler.cpp was changed not to 
listen, then the opposite will not work because OnSetValue() is only 
called when the value is changed, not when the constructor is ran.
Unfortunately we've got pure virtuals and virtuals around and those make 
it impossible for us to do certain things in the constructor. So, for 
example, when MIDI_INPUT_DEVICE is created it is creating it's 
parameters as part of it's constructor (currently). At this time we MUST 
NOT call things like CreateMidiPort or what not.
So we can't really set most parameters to anything other than defaults 
during device creation time.

I'm thinking that we'll have to make changes to devicefactory so that 
Create calls default constructor and then calls some other method that 
will set the parameters _after_ the constructors are all done.
I'm thinking devices will have only one constructor and after calling it 
factory will interate thru all parameters and set them one by one. That 
will make sure that OnSetValue is called and the backend stuff is in the 
right state.

Does that sound good to everyone?
If so, I'm going to think about it a little bit and rework this stuff a 
little bit this coming (long) weekend.

Regards,
Vladimir.

Rui Nuno Capela wrote:

>As predicted for today,
>
>linuxsampler 0.2.x:
>
>* Unconsolidaded MIDI input related channel commands are back:
>  SET CHANNEL MIDI_INPUT_DEVICE <chan> <midi-device>
>  SET CHANNEL MIDI_INPUT_PORT <chan> <midi-port>
>  SET CHANNEL MIDI_INPUT_CHANNEL <chan> <midi-chan>
>
>* Still useful for compability with legacy clients, an almost
>  deprecated command gets re-implemented:
>  SET CHANNEL MIDI_INPUT_TYPE <chan> <midi-driver>
>
>* Optional parameter list on MIDI input device creation fixed,
>  but not quite fully effective yet:
>  CREATE MIDI_INPUT_DEVICE <midi-driver> [<key>=<val>...]
>
>As is getting usual, my efforts are mainly in maintaining good
>ol'compability with existing client legacy interfaces. If the name of
>qsampler is coming to your mind, you're a genius ;)
>
>Bye.
>  
>