What do you mean by 'in the same position'? In the same position as what?

CC84 is referred to as 'undefined' in the information that I have. Maybe the sequencer part of your devices does in fact use CC84 for some purpose of it's own, and therefore needs to clear it from incoming data. What are you using CC84 for in the data you're sending to the sequancer?

Geoff

CC84 is used in guitar parts for a more real sound, in one position (tic) with notes up to 4 CC84. When, for example, you continue recording from the 16th bar, CC84 disappears in the interval from 1 to 16 bars and only one remains, which leads to the wrong sound of the guitar. Although the segment 1 through 16 is preserved, nothing should change there. Is it a hardware error or a software error? And how to eliminate it?

You don't explain, but it sounds like you're using 'live' input, so the midi is being generated as you record? So the CC84 messages are being created by something?

Are you using some sort of guitar controller?

The Yamaha devices should know nothing about the midi (controllers). If they are received, they should add them to the message chain. If they are to be played, they should be sent to be processed by the device that makes the sounds. They should not be messed with.

If this is specifically guitar data, then the problem would be coming either from the device that is creating the data (guitar controller), or the device which is 'playing' the data (i.e. the device that receives the midi data and tries to re-create the sound.

There are various normal midi (CC) controllers that could involve a succession of similar CC messages, so there is nothing 'wrong' with a succession of CC84 messages. And no reason why any of the messages might vanish.

One thought. How are devices connected together? Are you using one of those cheap DIN/USB converters? They do have a tendancy to interfere with the data!

Geoff

Everything is simple. I record in midi on one Yamaha psr sx900 device in auto accompaniment mode on channel 12, I record a guitar part, take chords, the chord notes are recorded in the sequencer, each has its own CC84 and all this is on the same tick. I record 16 bars, stop, then continue recording from bar 17, 2 more bars, stop. I check in Step Edit mode and see that CC84 disappeared in the first 16 bars and only one note remained. The sequencer itself takes and deletes CC 84, considering the same midi date on one tick as garbage.

OK - so when you say you're recording guitar you mean you're using a guitar voice on the synth/workstation? So perfectly normal midi data.

There must be some setting on the sx900 to prevent duplicated CC? Cannot be hw or sw, as duplicate CC is normal, say from pedals, or a fade or a cresendo, or a moving stereo image (using pan).

Please attach example of midi file where this happens. need not be complete, just to include the CC84 data that is there, and place where it was there but gone.

Geoff

Test 1 midi recording from 1 to 16 bars, test 2 midi recording continued from 16 bars, make sure of the difference.

Watch channel 12

Hello,

Yes, I've got the two .mid files.

I've used a process to convert the files into easily readable text. The two test files are attached as test_1.txt and test_2.txt.

There are no real surprises here.

This are a lot of SysEx messages, and a number of 'Sequencer Specific' messages. I don't know what these are, maybe the manuals for your machines might help explain some of this.

I suspect that the messages to apply the facility you're trying to use comprises a number of parts, or levels. The process may be initialised using SysEx, it may be started via the Sequencer Specific message, and the actual implementation may be in the BB 54 (hex) Controller. Where these things happen in the correct order, they may work OK. When you add data for your second section to the existing data for the first section you may be messing up the data, so it does not work correctly. This is of course a guess.

Can you do the same (more or less) two sections as one 'take'. Doesn't matter if the notes are not correct, as long as this special process is carried right through. Then I can compare the extra stuff between the two versions. When you get this longer version, does this play back correctly?

When you play back the present version created as two 'takes', what parts play correctly, and what does not. I assume that the first part is OK, but is ALL the second part NOT ok, or is it just the start of the second park wrong, and the rest is OK?

Geoff

Thank you. And you can view the midi files in Step Edit or Microscope mode. Test1 everything is correct there, Test 2 is wrong until the 16th clock cycle, after the 16th clock cycle everything is fine, if I continue recording further, then after the 16th clock cycle it will become wrong until the third record.

Thanks for the latest clarifications.

On the basis of what I see in the midi files, and what you now add, I suspect that what is happening is that the various parts of the data that implements the effect you are using is getting messed up, as I suggested above. I'd need to fully understand the structure of the parts of the data to be sure, and I do not yet have this understanding.

I assume that you have the relevant manuals. Maybe you could at least refer me to the specific pages where this is detailed. Both the place where the function is explained, and the part of the MIDI Specification where the midi messages are detailed.

I wonder if you are 'breaking' the recording at almost exactly the point at which the process is adding part of the controlling data, so that when you restart something is not there where is should be? What control do you have regarding the insertion of the SysEx and the Sequencer Specific data, and ditto regarding the insertion of the CC84 items. If the SysEx etc data is inserted automatically, then you need to make sure you do not 'break' the recording at the same moment as this data might be inserted?

Geoff

Control Change 84 is Portamento Control*. On this site, see the List of Control Change Messages and the MIDI 1.0 Detailed Specification, PDF page 21 / printed page 16: "Portamento Control [...] communicates which note number the subsequent note is gliding from. [...] When a Note-On is received after a Portamento Control message, the voice's pitch will glide from the key specified in the Portamento Control message to the new Note-On's pitch at the rate set by the portamento time controller [CC5] (ignoring portamento on/off [CC65])."

If I understand correctly, Andrey is using a Yamaha PSR-SX900 to record Auto-Accompaniment chords into a Song. In the first recording (Test 1.mid), everything is correct -- various notes have a CC84 message in front of them. But when Andrey re-recorded part of the song starting at measure 17 (Test 2.mid), the Yamaha PSR-SX900 apparently modified and removed CC84 messages in measures 1 to 16. For example, here is the first chord that is changed:

Before (Test 1.mid)                     After (Test 2.mid)

═════════════════════════════════════   ═════════════════════════════════════

Position  Ch  Kind     Data             Position  Ch  Kind     Data

────────  ──  ───────  ──────────────   ────────  ──  ───────  ──────────────

3:3:1856  12  Control  CC  84, Val 45   3:3:1856  12  Control  CC  84, Val 52

3:3:1856  12  Note On  Key 50, Vel 30   3:3:1856  12  Note On  Key 50, Vel 30



3:3:1856  12  Control  CC  84, Val 64

3:3:1856  12  Note On  Key 65, Vel 35   3:3:1856  12  Note On  Key 65, Vel 35



3:3:1856  12  Control  CC  84, Val 60

3:3:1856  12  Note On  Key 62, Vel 20   3:3:1856  12  Note On  Key 62, Vel 20



3:3:1856  12  Control  CC  84, Val 52

3:3:1856  12  Note On  Key 53, Vel 5    3:3:1856  12  Note On  Key 53, Vel 5

In this chord, the last CC84 value was moved in front of the first note, and the other three CC84 messages were removed. There are various other chords in measures 1 to 16 that were changed the same way.

The CC84 and Note On messages in the chord are all at the same tick position, so maybe the Yamaha PSR-SX900 decided only the last CC84 value at that position was worth keeping. However, it seems strange that the Yamaha PSR-SX900 would correctly keep all of the CC84 messages during the original recording, it only modifies them when you re-record part of the song starting at a later position.

Andrey: Have you tried contacting Yamaha? On the Yamaha PSR-SX900 Downloads page, I noticed the firmware update available is from earlier this year 2022, so Yamaha might still be actively supporting this keyboard. Perhaps Yamaha might be interested in trying to fix this bug. I see there is a "Product Registration" link above the download list. Maybe if you register and log in you might get a way to contact Yamaha support? Or maybe try something on the Contact Us page.

I'm not sure if we can help much, but if you tell us more details how you start the second recording, maybe we might notice some setting or procedure in the manual that you can try doing differently.

_____

(* Note about Portamento Control: I originally thought the CC84 messages in Andrey's MIDI files were being used for their standard "Portamento Control" purpose. But later I noticed the chords that use CC84 in "Test 1.mid" mostly have notes that are very short in duration -- most of them are less than 0.1 second long. I now suspect the CC84 messages and these short chords are maybe being used to encode some kind of chord information and not intended to be actual protamentos? Whatever effect they actually have on the Yamaha PSR-SX900, I guess Andrey still wants them to be preserved.)

Bavi_H , thank you. I have the latest version of sx900 1.11. There are no settings in the tool to fix this problem. A year ago, I discovered this problem in the sx600 version 1.03. I can't bring this problem to the developers of these tools in any way, maybe you can help. The recording is done simply, I record the first 16 bars, save or you can not save anything from this does not change and I continue recording from the 17th bar, stop and look at the CC84 disappeared in channel 12 until the 16th bar, after the 17th bar everything is nominal, if you continue recording from 32 bars, then from 17 to 32 bars CC84 will also disappear and so on. There are still problems there, but at least fix this one.

You can record 100 bars, and then continue recording from 101 bar, then up to 101 clock cycles CC84 will be lost.

I wonder if Yamaha have 'fudged' the implementation of this controller? The result is that it all works properly in 'normal' circumstances, but when you stop a recording, and then restart it as you are doing, something goes wrong.

Normal controllers operate to apply a setting to all notes happening on a channel, until another change is implemented. In such cases, there would be no point to having multiple CC at the same tick point, so such duplicates might properly be removed leaving the last one only. This seems to be what is happening here. So, the system if 'forgetting' that these are the special CC84 Portamento Control that operates immed on the following Note On ONLY and is treating CC84 as a normal CC and tidying them up. I guess that there is something about the way you are stopping one part of the recording, and then restarting the next, that is causing the problem.

There could well be a problem in the firmware, but how Yamaha might fix this, and how long it might take, well, more guessing games?

If we can work out what is happening to the data, there might be a work around, i.e. adjusting the timing of your restart point, or it might be possible to manually 'fix' the data/midi file - I still wonder if one or more of the 'Sequencer Specific' SysEx commands are relevant?

Geoff