--- In bc2000@yahoogroups.com, "Mark" <markwinvdb@...> wrote:
>
> --- In bc2000@yahoogroups.com, "gil.brand33" <gil.brand33@> wrote:
> > Does "ifp/ifn" corresponds to "On/Off" respectively? (Couldn't find that
> > in the BCMI
)
>
> Strictly speaking "ifp <something>" simply means "output <something> upon a positive value change".
>
> For an ENCODER this can involve any positive jump between values within the range from min to max.
>
> However, unless mode=increment/incval, a BUTTON's value only flips between its actual min and max, so in this case "ifp <something>" does mean "output <something> when the button switches to ON".
> (At least this is the case if you've used appropriate ".default" and ".minmax" statements: see below.)
>
> > I reviewed section 14.3 in the BCMI, and I'm not quite sure how
> > ".default" behaves under all possible scenarios
>
> Welcome to the club...
>
> > Therefore, in order to `ignore' both ".default" & ".minmax" (to be on
> > the safe side..), I was thinking of replacing only the first ".tx" line
> > in your block, so that the whole block would look like this:
> >
> > $rev R1
> > $button 4
> > .showvalue on
> > .default 2
> > .mode toggle
> > .minmax 2 3
> > .tx $F0 $01 $20 $01 $2A $33 ifn $02 $00 $F7 ifp $03 $00 $F7
> > .tx $F0 $01 $20 $01 $2A $35 ifn $01 $00 $F7 ifp $00 $00 $F7
> > .tx $F0 $01 $20 $01 $2A $38 ifn $01 $00 $F7 ifp $02 $00 $F7
> > $end
> >
> > Would that be a valid block?
> > Would it do exactly the same as the block you suggested?
>
> With my first .tx line (containing "val" and no "ifn"/"ifp") I was only trying to save some of your precious BCR preset memory...
> But I did try my solution before I posted it, and it worked!
> I've just tried your version too: as far as I can see it produces exactly same output.
>
> One interesting difference is that your version never mentions "val", so your version's actual minmax range is irrelevant, except that the first value must be lower than the second: so ".minmax 0 1" or ".minmax 0 127" would work as well.
>
> However, the "general structure" of your ".minmax" and ".default" statements is still crucial, because otherwise the ifn/ifp method won't work correctly.
>
> For instance, with ".default 0" and ".minmax 0 0" (or WITHOUT default/minmax statements), the BCR can NEVER determine a direction, since the value remains 0, so (no matter how often you press the button) the BCR simply outputs the bytes of BOTH the ifn and ifp sections, which is of course totally undesired (in fact: it's invalid MIDI!).
>
> The value of the ".default" statement determines the direction that the BCR detects when you FIRST press the button.
> For instance, ".default 10" together with ".minmax 2 3" would lead to this:
>
> 1st press: the display shows "on", but internally there's a NEGATIVE jump (from 10 to 3), so the ifn section is output! Not what you want.
>
> 2nd press: display shows "off", but again there's a NEGATIVE jump (from 3 to 2), so again the ifn section is output!
>
> 3rd press: "on" and a POSITIVE jump (from 2 to 3), so the ifp section is output.
>
> However, leaving out the default statement altogether would happen to go well in this case, because it would amount to setting the default to 0, so pressing the button for the first time would correctly lead to a positive jump (from 0 to 3).
>
> > Shouldn't there be some delay time between the executions of the ".tx"
> > lines, so that the receiving synth can process the incoming data?
>
> Interesting question.
>
> I've never tested how the BCR behaves temporally when it sends output, but my guess is that it does NOT insert delays between subsequent MIDI (in particular SysEx) messages - probably it just outputs all bytes in a "dumb" manner.
>
> It would be interesting if the BCR always inserts a delay between two ".tx" statements (i.e. between the last output byte resulting from one ".tx" statement and the first output byte resulting from the next ".tx" statement); however, I doubt that too.
>
> You could try to build in a delay "manually" by including "dummy" MIDI messages in between two SysEx statements, but I'm not sure whether you would be doing the receiving synth a favor this way...
>
> I do remember that older synths sometimes required long delays of 100-200 msec or so (after "big" changes like a mode switch etc.).
> However, to achieve this amount of delay on the BCR, you would have to include an enormous amount of dummy messages in the button's definition (maybe you could use the BCL elemnt ".ntimes"?).
>
> In any case I would only start worrying about delay issues when the synth indeed begins to show signs of skipping SysEx messages due to "time trouble".
>
> Best wishes,
> Mark.
>
Thank you very much Mark.
Tried it out and it works fine. So Happy!
No timing issues so far (its a DSI PolyEvolver Keyboard...)
Regarding the usage of "val" in a ".tx" command:
I want to configure an encoder to send values of 30-250:
$encoder 1
.minmax 30 250
.default 60
.tx $F0 $01 $20 $01 $2A $42 <val> $F7
.resolution 96 96 96 96
.showvalue on
.mode bar
For my synth, "val" here should be 2-Byte long, for example:
If decimal value is 49 --> hex value is x31 and the ".tx" line (after splitting
MSB & LSB), should actually be:
.tx $F0 $01 $20 $01 $2A $42 $01 $03 $F7
For value of 164, which in hex is xA4, same line should be:
.tx $F0 $01 $20 $01 $2A $42 $04 $0A $F7
So, I need to split the "val" nibbles (val[0:7] and val[8:15]) and "pad" them with "zeroes"...
Would the following syntax work:
.tx $F0 $01 $20 $01 $2A $42 $0val0.7 $0val8.15 $F7
Cheers,
Gil
