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.

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); 

    }

}

Quoted from Christoph on Saturday, 04 March 2023

how is the checksum calculated?

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:

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[i]) >=128)

         sum -= 128;

   sum = 128 - sum;

  return sum;

}

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:

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 

I also tried GS_VOLUME to no avail.

f0 42 00 42 12 40 00 7f 00

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.

Not sure why you're trying to do this via SysEx. Maybe it is possible?

Why not try the normal midi command? If the Program Change works OK, then I'd assume that the Volume will as well.

This is a Controller, #7. You can apply a range of settings, from 0 (lowest) to 127 (loudest). The full effect of this would be dependant on other settings, but this might at least get you moving. May need to experiment to see which setting works best.

Assuming you're using Channel 1 (0H), try (all in hex)

B0, 07, 40 (Controller Ch 0, Volume, Level mid point)

Geoff

Looking again at the midi data you were sending - maybe you were trying to send the correct data, but are you trying to use Running Status?

Does the receiving device know about running status? Is it set up to add the missing Status Byte back in, or recover the byte from previous data to treat it as implicit? If the receiving device does NOT know about RS, then you're sending garbage.

Geoff

Since the Decay and Attack functions require GS mode, I'm doing a GS_Reset. What is "Running Status"?

My impression is , that the Synth (SAM2695) "forgets" the previous parts setting. I have two buttons for testing the pedal scanner (saving me from using the whole clavier).

When I push them, midi data is obviously sent:

Push button: 90 25 40 Release button: 80 25 ff 

It isn't so that I need to send all voice,decay,attack data before each note I'm playing, right? I would assume, that the controller remembers the values about
part#, volume, decay,attack etc.

Running Status is where there is a succession of midi commands that all use the same Status Byte, and the first SB is remembered by the receiving device and reused for the following commands, to reduce data flowing through the system.

In your example, lines 4, 5, 6, and 7 look like they're using Running Status. So line 4, which has the B0, is normal. Line 5 seems to have no status byte so the B0 will be reused. Ditto for line 6 and 7. Line 8 HAS a Status Byte, as it's NO LONGER B0, so this is normal so this will reset the SB buffer.

The FF on line 5 (timing byte) should NOT affect the this. A block of SysEx could well.

Again, does the receiving device recognise Running Status? Devices SHOULD, but some may not.

Geoff

I couldn't find anything about running status in the SAM2695 manual posted here.

OK. Had a look at the manual, which is not very well explained. Maybe more of a translation problem?

Most of the commands you're looking at are, I believe, midi Controllers. They should ALL be prefixed with B0 (hex). As you say, there is no reference to Running Status so you should give the complete commands just in case. Also, the SAM system is using some general Controllers for it's own purposes, so in midi info they will be referred to as something else (i.e. the reference to NRPN etc).

Regarding the example you give above,

Line 4 should be ok, this is normally Polyphonic OFF, and I assume this is what you mean by 'Mono' (Monophonic as opposed to Polyphonic). But I'm not sure about the 01 following, but this may be a dummy data value?

Line 5 I believe should be preceeded with a B0 to specify a Controller, the following data may be correct. I assume the FF is a 'timing' byte. Are these needed?

Line 6 - ditto

Line 7, This may be trying to set the main Volume level, and this should also be prefixed with B0.

I suspect that these WOULD work if your device DID support Running Status, but that may have been accidental?

line 8 is a complete Program Change, and should be OK.

I note from the manual that some of the instruments have options, implemented with a Bank Select before the program Change. This is standard, but MUST be BS followed by PC.

See if this helps.

Geoff