Note off

My "fault" was, that I sent three notes in my test program at the beginning of the firmware start, and I omitted the last notes' 80 nn xx "note off" command. This was leading to having the unit play the last played not everytime it was receiving a "note off".

I got information meanwhile from the SAM2695 manufacturers team: they say, what I'm doing with "note off" in mono mode is "exploring the chips implementation of mono mode". What I'm reporting is specified behaviour of the chip's implementation of mono mode.

"The mono mode tries to replicate the behaviour of Mono Synth back in the days (MiniMoog, Arp Axxe, Sequencial Circuits Pro 1, Roland SH2, Roland SH101, Korg MS20, Yamaha CS5 ...)" they say.
So in the end I wasn't all that wrong.

And I was pointed to the following links:

http://www.soundonsound.com

Priorities & Triggers

and

forum.moogmusic.com


https://forum.moogmusic.com/viewtopic.php?f=2&t=12732&__cf_chl_jschl_tk__=pmd_cfb08181e9cc29ff6713dda299fc0ec3ea5b15ed-1628000903-0-gqNtZGzNAeKjcnBszQhO

"The implementation of the 2695 was done to match the one used in the General MIDI module SC55 which was the standard of GM sound module when the GM standard was created"


So now I can live with is explanation the more so I'm using the solution proposed here to use the sustain function. I'm sending always a note on - note off sequence.

Correction: the interspersed B0 sequences are made by my program, when the pot value of one of the 4 pots (ATTACK,DECAY,VOLUME,VOICE) changes value.
They may appear at random. I also will have to take measures that the messages don't interleave of overlap. I'm checking this right now.

UPDATE:
I definitely could not find any cause for the fact that a B0 nn vv made another note appear sounding. I built a little state machine in the Midi output chain to filter out B0 nn vv sequence. So only note on (90h) messages get through.
And the undesired behaviour has stopped. No more notes are triggered by B0h sequences.
This applies to mono mode. For fun I left off the mono mode initialization and guess what? In polyphonic mode this B0 sounding notes do not appear. A bug in the chip?

I'm at my midi project again. The read errors are gone now.
But I have another strange effect. This is what the SAM2695 is getting right from the start

FF

F0 41 00 42 12 40 00 7F 00 41 F7

B0 7E 00

B0 07 64

90 36 78

80 36 00

90 38 78

80 38 00

90 39 78

C0 21

B0 07 44

B0 63 01

B0 62 63

B0 06 29

B0 63 01

B0 62 64

B0 06 18

90 0D 25

80 25 40

90 27 40

80 27 40

90 25 40

80 25 40

90 27 40

B0 07 45

80 27 40

I have two test switches, button press makes a contact, button release is sensed also and in consequence of this the follwoing is sent:

-

90 25 40

80 25 40

90 25 40

80 25 40

90 27 40

80 27 40

90 25 40

80 25 40

90 27 40

80 27 40

90 25 40

80 25 40

90 27 40

80 27 40

90 25 40

80 25 40

90 27 40

80 27 40

The above cannot controlled by me. It is what the PEDSCAN midi board is sending.
The "make contact" sends the 90h (which is note on) and releasing the contact sends 80h (note off).
with the 90h the SAM2695 correctly plays the wanted note, but releasing plays another sound (or note) which is unwanted.It is a note a tritone higher
BTW, the "mono mode" I send to the SAM2695 works fine.
I have no idea, why the note off code makes another note sounding. Maybe it has got to do with the setting of attack and decay?

Quoted from Christoph on Wednesday, 15 March 2023

can I achieve a mode that does the following: I tap a bass pedal note, say "G". The voice 33 (acoustic bass) sounds plucked. I release the pedal key. "G" The "G" just plucked still sounds and keeps on decaying, although the pedal key is released.I tap another note, say "G#". The previously played "G" disappears and the "G#" decaying sequence is started. Is this possible? Is that, what is understood by "mono mode"?

Mono mode means only one pitch can sound at a time on that channel you sent the Mono mode message to. If there's a pitch currently making a sound on that channel and you send a new Note On message, then the old pitch will stop making any sound and the new pitch will start making a sound.

Normally, I think the Acoustic Bass sound will quickly mute (decay very fast) once you send a Note Off message. However, if you send a Sustain pedal on message, then I think the Acoustic Bass sound will continue to sound (decay slowly) even after you send a Note Off message.

So if you are still able to send any MIDI message, try sending both a Mono On message and a Sustain pedal on message:

B0 7E 01 (Channel 1 Mono On)
B0 40 7F (Channel 1 Sustain pedal on)

Alternatively, if you are only able to send Note On and Note Off messages, then you can try setting up the Roland SC-55 using the buttons on its front panel. Using the buttons on the Roland SC-55, you can enable Mono mode and you can set the Release time to the maximum value. I think setting the maximum Release time will help keep the Acoustic Bass sound decaying slowly after a Note Off message.

Roland Sound Canvas SC-55 manual

Hello,

You might need to try this, and see what the specific device, the S55, actually does.

Yes, Mono Mode says that the instrument will play one note at a time, ONLY. But, in the situation you describe, the pedal may have stopped the note that was playing, it is now OFF, but the envelope may still be sounding something even though the note is OFF. Will the S55 use the mono mode to cancel/silence the envelope even though the note is actually OFF anyway? Or will it respond by doing nothing as the note is OFF already?

Is there a technical difference here between the note 'sounding' even though it's OFF and therefore not 'playing'?

Geoff

Since I'm presently a bit stuck with my microcontroller interface I'm thinking of a quick solution: buy a used Roland Sound Canvas S55 and plug the midi pedal into it.
The midi note on7 note off sequence is coming reliably out of the PEDSCAN module (90 xx 40 80 xx 40).

The only problem: can I achieve a mode that does the following:

I tap a bass pedal note, say "G". The voice 33 (acoustic bass) sounds plucked. I release the pedal key. "G" The "G" just plucked still sounds and keeps on decaying, although the pedal key is released.I tap another note, say "G#". The previously played "G" disappears and the "G#" decaying sequence is started. Is this possible?

Is that, what is understood by "mono mode"?

More issues

In this message you said you were trying to send the "GS_VOLUME" message:

f0 42 00 42 12 40 00 7f 00

But the Master Volume message for GS looks like this (from page 27 of the manual):

F0 41 00 42 12 40 00 04 vv xx F7

In this message, you mentioned sending

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

Be aware in MIDI messages bytes, hex 80 to FF are Status bytes that indicate the type of message, and hex 00 to 7F are for data bytes. The FF on the end of the "Release button" message above is not a valid data byte. It indicates the Status byte FF for Reset.


More information about Running Status

The Dream SAM2695 almost certainly correctly supports Running Status because it is part of required MIDI standards. In fact, on page 27 of the manual, the various RPN and NRPN message examples are shown using Running Status.

For example, the NRPN 37xx message format is shown using the following bytes:

Bn 63 37 62 xx 06 vv

This uses implied Status bytes (Running Status) and has the following meaning:

Bn 63 37 (Control Change Channel n+1, Controller 99 Non-Registered Parameter Number MSB, Value hex 37)

   62 xx ("       "      "       "    Controller 98 Non-Registered Parameter Number LSB, Value hex xx)

   06 vv ("       "      "       "    Controller 6 Data Entry, Value hex vv)

You can also send the Status Bytes explicitly and it would mean the same thing and have the same effect:

Bn 63 37 (Control Change Channel n+1, Controller 99 Non-Registered Parameter Number MSB, Value hex 37)

Bn 62 xx (Control Change Channel n+1, Controller 98 Non-Registered Parameter Number LSB, Value hex xx)

Bn 06 vv (Control Change Channel n+1, Controller 6 Data Entry, Value hex vv)

Running Status can only be used for Status bytes that contain a channel number (hex 80 to EF).

System Common and System Exclusive status bytes (hex F0 to F7) cause the remembered Running Status to be forgotten. The next message after these System messages must begin with a Status byte. If it doesn't, then the device has to ignore incoming bytes until it gets a Status byte (hex 80 to FF).

System Real-Time messages (hex F8 to FF) are 1-byte messages that may occur in between the bytes of other messages. A System Real-Time message makes no changes to the remembered Running Status. Except: If the device obeys the Reset message (Status byte FF), it is supposed to forget the remembered Running Status as part of its reset process.

So when you sent the following bytes:

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

This would get interpreted as:

FF (Reset)



F0 41 00 42 12 40 00 7F 00 41 F7 (GS Reset)



B0 7E 01 (Control Change Channel 1, Controller 126 Mono On, Value 1 for one channel)

   37 20 ("       "      "       "  Controller 55 unused, Value 32)

FF       (Reset)

   37    (ignored as invalid, Status byte required)

   22    (ignored as invalid, Status byte required)

   07    (ignored as invalid, Status byte required)

   10    (ignored as invalid, Status byte required)

C0 21    (Program Change Channel 1, Electric bass (finger))

Geoff:

Quoted from Geoff on Wednesday, 08 March 2023

The FF on line 5 (timing byte) should NOT affect the this.

Status byte FF is the Reset message, which would have an effect. The manual says it causes the device to reset to power-up conditions.

Quoted from Geoff on Wednesday, 08 March 2023

Line 4 [b0 7e 01] 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?

In the Mono On message, the value part of the Control Change message indicates the number of channels you want to use (one channel for each monophonic note you want). A value of 0 is a special value that means to use as many channels as the number of maximum simultaneous notes the device can sound. A value of 1 means you just want to use 1 channel. However, this "number of channels" value is mainly intended for monotimbral devices -- devices that can only play one instrument sound at once. The main example is a MIDI guitar controller would send a Mono Mode message set for 6 channels, then each string would transmit notes monophonically on unique channels and each channel can have unique pitch bend.

Modern devices are multitimbral -- they can play multiple instrument sounds at once. A multitimbral device effectively acts like it contains 16 single-channel monotimbral sub-devices that are each listening to single MIDI channel and control a single instrument sound. If a multitimbral device supports Mono mode, then when you send a Mono On message to a channel, the "number of channels" value is usually always treated as if it were 1, no matter what value is sent.

According to the Dream SAM2695 manual, the SAM2695 has a serial port and a parallel port. In its default mode (the "serial mode"), you can send MIDI messages to the serial port which the SAM2695 synthesizer will interpret to generate sounds. It's also possible to send some special device control messages to the parallel port. However, it seems like the board you are using is this GM Mini Module (German manual), which leaves the Dream SAM2695 parallel port unconnected, so the only thing you are able to use is the serial port. (The SAM2695 also has a "parallel mode", but it's not available to you since you can't use the parallel port.)


In the Dream SAM2695 manual:

• Pages 15 to 18 are all describing Non-Registered Parameter Number (NRPN) messages. (The overview table on pages 15 and 16 shows all the commands at a glance. The following tables and descriptions on pages 16 to 18 give more details.)

• Pages 19 to 25 describe device control messages for the SAM2695's parallel port. (The overview table on pages 19 and 20 shows all the commands at a glance. The following tables and descriptions on pages 20 to 25 give more details.)

• Pages 26 to 29 show the various MIDI messages the device understands.


Be aware that in MIDI, NRPN messages are sent using a special pattern of Control Change messages. For the Dream SAM2695, be aware that all of the NRPN functions from pages 15 to 18 correspond to the following row on page 27 of the MIDI message table:

MIDI MESSAGE	HEX CODE	DESCRIPTION	COMPATIBILITY
NRPN 37xxh	Bnh 63h 37h 62h xx 06h vv	Special Synthesis features controls (see §2-1)	DREAM

where n is 0 to F for MIDI Channel 1 to 16.

For the parallel port device control messages, notice that the overview table on pages 19 and 20 has a column called "Compatible NPRN/Sysex". Since you don't have access to the parallel port, if you want to do something shown in this section of the manual, you should send one of the corresponding NRPN or Sysex messages to the serial port.


In your original message today, when you tried to send the following

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

It looks like you wanted to use the "37 20" and "37 22" messages from the NRPN section of the manual and the "07" message from the parallel port device control section of the manual. You'll need to convert these into MIDI messages. Also note:

For the NRPN message 3720 "Spatial Effect volume", notice that the value range is 00 to 7F. (It looks like you wanted to use FF which isn't valid.)
For the NRPN message 3722 "General MIDI volume", notice that the value range is 00 to 7F. (It looks like you forgot the value.)
For the device control message 07 "Master Volume" (range 00 to FF), you should use compatible NRPN message 3707 "Master volume" (range 00 to 7F). (I think you could convert hex 10 in the bigger range to hex 08 in the smaller range.)

After converting them to MIDI messages, I think you'd get the following:

ff (Reset)

f0 41 00 42 12 40 00 7f 00 41 f7 (GS Reset)

b0 7e 01 (Channel 1 Mono On)

b0 63 37 62 20 06 7f (Channel 1 "Spatial Effect volume" max)

b0 63 37 62 22 06 7f (Channel 1 "General MIDI volume" max)

b0 63 37 62 07 06 08 (Channel 1 "Master Volume" value 8)

c0 21 (Program Change Channel 1, Electric bass (finger))

(Note: Even though you are sending the NRPN messages on MIDI Channel 1, I suspect some of these commands might have a device-wide effect on all MIDI channels and the specific channel you sent it on doesn't matter. If you ever need to use multple MIDI channels, you might want to preform some listening tests to confirm if these commands affect the volume level you hear on all MIDI channels.)

However, I think you might be trying to test too many different volume controls at once. I suggest you just try Control Change 7 (channel volume) and see if that works for you.

ff (Reset)

f0 41 00 42 12 40 00 7f 00 41 f7 (GS Reset)

b0 7e 01 (Channel 1 Mono On)

b0 07 7f (Channel 1 Volume max)

c0 21 (Program Change Channel 1, Electric bass (finger))

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

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

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

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.

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

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

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.

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 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.

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

    }

}

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.