Range values are not working with indexed event conditions

[mhthies]

The following event binding configuration does not work:

    <binding input="midicontroller" conditions="controlnum=1>7 and midichannel=0" 
     output="set-loop-amplifier" 
     parameters="loopid=VAR_my_loopid+controlnum-1 and
                 amp=controlval/127.0*2.0"/>

It is not triggered when the relevant MIDI events are received (control change event with control=1 on MIDI channel 0) and results in the following warning in the log at freewheeling's start:

 binding: input 'midicontroller'
 UserVariable: WARNING: Can't convert range to scalar!
         -condition 'controlnum' == 0>7
         -condition 'midichannel' == 0
       -> output 'set-loop-amplifier'
         -set 'loopid' = 'VAR_my_loopid'[350]+'controlnum'-1
         -set 'amp' = 'controlval'/127.00*2.00

If I declare a new UserVariable for storing the value range and use that variable in the binding condition, the log warning disappears, but the event binding does still not work:

    <declare var="VAR_my_range" type="range" init="0>7" />
    <binding input="midicontroller" conditions="controlnum=VAR_my_range and midichannel=0" 
     output="set-loop-amplifier" 
     parameters="loopid=VAR_my_loopid+controlnum-1 and
                 amp=controlval/127.0*2.0"/>

Tested with freewheeling version 0.6.6 on JACK 0.125.0 on ArchLinux.

After quickly diving into freewheeling's source code, I assume that this behaviour is caused by the max_index parameter of the EventParameter object, which is used for creating a hash index table for the parameter.

[bill-auger]

not to leave this hanging, but i am pretty busy lately - i did confirm the described behavior in my system - looking at the sources briefly, im not sure that the midicontroller->controlnum param was designed to accept a range - the configuration documentation indicates only an int, which could explain the "can not convert range to scaler" message it could be that what is happening when you refer to a range variable instead of a constant, is that the parser creates multiple event handlers internally, one for each integer in the range; but the literal range is only evaluated at runtime and can not be handled perhaps this is a bug (if 'controlnum' was intended to handle a literal range), or perhaps a caveat should be added to the documentation, if my speculation is accurate - it could be that the bug is the fact that it works at all with a range variable it needs some more investigation; but i cant say when i will have the time to look into it - if you propose any patches, i will consider them