Short answer, "Yes."
It's standard procedure to follow a Note On with a Note Off after the appropriate duration, i.e. quarter note, half note, etc.
N.B. A Note Off message can take one of two forms 1/. Note Off - 8nH etc., or 2/. a Note On 9nH with a velocity of zero, both for the channel and note that was sounded.

Ah, I see. Thanks. An "ALL NOTES OFF" (B0,00) as in the SAM2695 on bottom of p. 26 would not be appropriate?

Nope.
All notes off is something one puts typically at the end of a MIDI file.

An important part of any music is normally the duration of any specific note. It is therefore useful to retain control of the durations. If you're using a keyboard as a controller, this helps as most keyboards generate a Note On when the key is pressed, and a Note Off when the key is released. I take it that you cannot use such a controller, for some reason. So you start a note, then lose control of it.

Not sure if this applies to you, but mand devices may have some degree of polyphony, so they can play more than one note at once. Usually, there is some limit. If there is no explicit Note Off, notes may be still playing, and using up part of the polyphony, even if notes cannot be heard due to the envelope having reduced the sound. In due course, new notes will not be possible as the polyphony has been use up. Explicit Note Off will avoid this problem.

All Note Off could be used, but it would be a help to know how this works on your system. Does your system know which notes are playing, or does it need to check ALL notes to find the ones that are playing (even if not heard) to turn them OFF. This might be OK, but there might be too much time delay involved.

If you're using any sort of software, you could maintain your own list of Notes On, so you DO know which notes are On. Then you would know which notes to turn off. If you are generating the Note On via software, i.e. NOT using a keyboard) then you could create a duration as well, and automate the generation of a Note Off?.

Geoff

Thanks, Geoff, actually I'm testing that SAM2695 with an Arduino Nano with a small test program which sends notes.
Final aim is to midify a bass pedal of a Hammond organ (25 notes). The playing mode is monophonic, that is, only one note is played at a time. The next played note mutes the previous one. Moreover, just tappinp and releasing a pedal key does not mute the played note. The note decays like a plucked string on an acoustic bass. Midi source is a midi controller made by a firm from Poland, midi-hardware.com.

I'm coming back to this issue. Actually in my application of a Hammond organ midified bass pedal I want to assure a certain behaviour.
A couple of years ago I did this already for someone and he solved the single note behaviour by programming his Korg Kronos to monophonic mode.
This resulted in alway only one note playing when tapping on the pedals. Tapping inprecise (more than one at a time) resulted in only the last one being played.

I'm wondering whether this mode can be achieved with the SAM2695 chip. I'm attaching the data sheet. Or could it be there is a standard Midi command for this mode?

Yes there is a standard way to request mono mode, and the SAM2695 manual suggests it might support that. At the beginning of section 3 "Detailed MIDI Implementation" on page 26, the table includes lines for both "CTRL 126 ... Mono on" and "CTRL 127 ... Poly on (default power-up)", suggesting each channel uses (Omni Off) Poly mode by default but can be changed to (Omni Off) Mono mode.

If your pedal board is sending notes on channel 1, try sending these messages then see if the SAM2695 behaves in a mono fashion:

Control Change Channel 1, Controller 126 (Mono on), Value 1 (one channel) [hex B0 7E 01]

or

Control Change Channel 1, Controller 126 (Mono on), Value 0 (all channels) [hex B0 7E 00]

@Bavi_H:
Thanks. Found that and implemented it. The final test still is due. Before going into field test, just one thing: Duration/Decay, is that
a parameter that can be controlled also? It would be nice to have a knob to adjust the decay length. Here is my breadboard setup:

Sure, the dispayed voice isn't a typical bass voice and not suited for decaying. It's just for fun, since I like it. I have a 12position switch and there are only 8 or so typical bass voices.

EDIT: I guess I found it:

NRPN 0163h Bnh 63h 01h 62h 63h 0ch vv (Env. attack time modify)
NRPN 0164h Bnh 63h 01h 62h 64h 06h vv (Env. decay time modify)

I don't have experience with these messages, so you'll have to test them to see how the unit reacts to them.

As you noticed, page 27 of the manual mentions these messages:

hex "Bn 63 01 62 63 06 vv" is "Env. attack time modify (GS)"
hex "Bn 63 01 62 64 06 vv" is "Env. decay time modify (GS)"
hex "Bn 63 01 62 66 06 vv" is "Env. release time modify (GS)"

n is for the MIDI channel, vv is for the value.

These are Non-Registered Parameter Number (NRPN) messages which are actually made up of three Control Change messages. The manual listing only uses one Status byte at the beginning which is allowed on DIN MIDI cables. If you are using a computer or USB cable to send the messages, you might have to send the Status byte for all three Control Change messages like this

hex "Bn 63 01 , Bn 62 6_ , Bn 06 vv"

Since these are GS messages, you might have to put the unit in GS mode first to use them. To do that you should send the "GS reset" message shown a little further down the list:

hex "F0 41 00 42 12 40 00 7F 00 xx F7" is "GS reset"

In GS System Exclusive messages like this, the xx byte position is a checksum. Maybe this xx notation in the manual means the unit accepts any byte without bothering to confirm if it is the correct checksum? For this message, the correct checksum is actually hex 41.

I'm at this topic again. First off: just out of curiosity, how is the checksum calculated? I xor'ed all bytes and get 0x29 (which is accidently decimal 41, but you said "hex 41").

Other thing: I can't get yet a noticeable effect of setting decay.
[code type=markup]
char reset[] = { 1,0xff };
char GS_Reset[] = { 11,0xf0,0x41,0x00,0x42,0x12,0x40,0x00,0x7f,0x00,0x00,0xf7};
char decay[] = { 7,0xb0,0x63,0x01,0x62,0x64,0x06,0x7f};

setup() {
play(reset);
play(GS_Reset);
Decay(0);
}
void Decay(int val) {
decay[6] = val&0x7f;
play(decay);
}

int play (char *s) {
char str[3];
for (int i=0;i<s[0];i++) {
snprintf(str,s[0]+1,"%02X",(unsigned char)s[i+1]);
midiSerial.write(s[i+1]);
mySerial.write(str);
}
}
[/code]

[quotePost id=17877]how is the checksum calculated?[/quotePost]
Calculating the Roland checksum is covered in my SysEx Tutorial.

I'm still trying to understand the checksum calculation. Following your tutorial page the checksum starts being calculated at begin of data. Where is that in the above example (hex "F0 41 00 42 12 40 00 7F 00 xx F7" is "GS reset")?

Also in your tutorial it is difficult to assign the values in brackets [6] to bytes. You are putting multiple bytes under the array address [6]. The formatting there isn't very helpful in understanding the method.

OK, I got it:
[code type=markup]
char test_string[]={0x40, 0x00, 0x7F};

printf("%03d\n", checksum(3,test_string))
;
int checksum(int count, unsigned char* c){
int sum=0;
for (int i = 0; i < count ;i++)
if((sum+=c) >=128)
sum -= 128;
sum = 128 - sum;
return sum;
}

[/code]
returns 65 = 41 hex.

Not quite easy though, how to decide where the "data" to be checksummed begins in a particular case.

I made some blatant programming error in the posted program snippets. Things seem to get to the better. I now see a reaction on a change of the decay and attack parameters. I was one off in the array index. Forgot to take the count byte into account 🙂

I'm still struggling with programming the device. It doesn't seem to do what I want it to do.
First off, it doesn't obey the volume setting. I'm sending the following initial sequence to the device:

[code type=markup]
REST: ff
GS_R: f0 41 00 42 12 40 00 7f 00 41 f7
MONO: b0 7e 01
VOL : 37 20 ff
GMVL: 37 22
MSVL: 07 10
VOIC: c0 21
[/code]

I also tried GS_VOLUME to no avail.
[code type=markup]
f0 42 00 42 12 40 00 7f 00
[/code]

On startup I send a note to the device and it is screamingly loud, far louder than I would expect compared to other volumes I was able to set the device to previously.

I'm a bit confused about GM and GS mode.