Chord recording problems

MIDIbox SEQ
1

Hi,

 

I tried some chord recording today, with the New Improved Recording Procedure :-)  on a note track with enough note layers, as opposed to using a chord track and a transposer track. What I noticed is that if you have e.g. a Dm and an F (played in this order), the sequencer will first play the notes of the D minor (D-F-A), but when it should play the notes of the F major (F-A-C), it will play only C.

 

I suspect this has to do with F and A being shared notes in these chords. My overall chord progression was C-Dm-F-G, and all other chord changes worked fine, only the Dm -> F didn’t work properly. Also tests with other chords, e.g. C-E-G -> C-E-A give the same results, in this case the latter chord will play only A.

 

EDIT: I’m using the latest firmware (v4.086)

 

EDIT2: Plus all the notes of all the chords are in the note layers, so recording works ok, but they’re just not playing correctly.

2

I need your session files to explain the reason (and give some hints how to avoid this).

 

Could you please attach the session directory in a .zip file to this thread?

 

Best Regards, Thorsten.

3

Hi,

 

sessions files attached.

 

There’s two tracks (both on channel 1), one with chords (G1T1) and one with a slow melody (G1T2), best perhaps with some organ type sound.

 

As for the problematic Dm–F chord change, the notes are there in the layers for F major, and if you press Parameter Layer button C while the session is playing, you can see activity in the 2nd and 3rd note layers when the sequencer advances to the step with F major – but only the note C comes out of the synth. (I’ve tried this on two different synths with the same results.)

[EXAMPLE1.zip](< base_url >/applications/core/interface/file/attachment.php?id=11703)

4

Very nice melody - it has a certain christmas melancholy! :smile:

 

This issue is related to a corner case that I actually knew, but ignored so far as I thought that it’s only an exotic case which wouldn’t happen during daily work with the sequencer. However, with the new recording function it can happen quite often!

 

It happened whenever the glide function was activated to stretch the notes to the next step until a new note was played. In this case, all previous notes were cleared (note off events sent) and new note(s) were played.

But of course, in this recording the intention was to keep the notes which have been recorded again.

 

I (hopefully) managed to solve the complicated corner case, please try this version:

http://www.ucapps.de/mios32/midibox_seq_v4_088_pre1.zip

 

Additional hints:

if you want that the chord is re-played whenever the gate has been set, enable the sustain function in the MODE page.

Alternatively disable the glide function for step 11 in the Length parameter layer (change the length to < 100%)

 

However, with V4.088 the “re-played” notes should be kept so that these measure are not required. But they make sense if the sequence is played by piano-like sounds which fade out quickly.

 

Best Regards, Thorsten.

 

5

Hi,

 

and thanks for looking into this!

 

The chord change seems to work now, but recording the steps has some extra problems that I don’t think were there before. Even though there was some glitch sometimes in the recording of a chord also previously, now there seems to be more problems, or the problem has changed somewhat.

 

The problem is that when I press a GP button to record something into that step, it often happens that the chord won’t be recorded correctly. Sometimes only one note is recorded, even though I’m 100% sure I have carefully pressed three keys. I’m not sure, but somehow the problem seems to be connected to the fact that when I press (and hold) a GP button and get the {curly brackets} around the step to be recorded, often the pressing+holding the GP button also gives you some note (e.g. C-3), which doesn’t always get erased when you push the keyboard keys. So for example if you try to record C-2, E-2 and G-2 (=C major), you might get these, but also the note that you got when you first pressed+held a GP button to record something, before pressing anything on the keyboard for that step (the note seems to be the same as the one the right hand side LCD’s upper row). Or you might get only one note.

 

Sometimes when you press+hold a GP button to record, you don’t get a note (this is when the right LCD’s upper row has “…” instead of a note), but only the curly brackets; in these instances the chord recording seems to work.

 

In case it’s useful, I have attached another session, where I have recorded four chords (C-Dm-F-G) on all tracks in G1 (ch. 1-4). In all cases I’ve followed the same procedure: I’ve pressed+held a GP button and then pressed three keys on the keyboard. The outcome is not what one expects: sometimes notes are missing, sometimes there is an extra note.

[EXAMPLE2.zip](< base_url >/applications/core/interface/file/attachment.php?id=11707)

6

Works flawlessly at my side.

 

Just to ensure: first you press the GP button, then you enter the notes on the keyboard to record a chord, right?

 

How does it behave if you activate the recording function with the SELECT button, select a step with the up/down buttons (or the datawheel) and then record some notes into the step?

 

Best Regards, Thorsten.

7

Just to ensure: first you press the GP button, then you enter the notes on the keyboard to record a chord, right?

 

Yes. (Press+hold GP, enter notes on keyboard, release GP.)

 

How does it behave if you activate the recording function with the SELECT button, select a step with the up/down buttons (or the datawheel) and then record some notes into the step?

 

This works much better. But using the GP method still seems to behave erratically. I have attached another session with four tracks on G1 (ch. 1-4), all with the chord sequence C-Am-C-Am. T1 is recorded using the SELECT button and data wheel, and T2-T4 using GP press+hold.

 

T1 turned out well, T2 and T3 didn’t, but T4 again did. I’m sure I have performed the key presses (GP + keyboard) carefully. I tested this for a longer time than just what it takes to record these four tracks, and SELECT button produced consistent results, whereas the GP press sometimes did but often didn’t.

 

It would be great if someone else could try recording some chords too, if only to prove that what’s at fault is me :o)

[EXAMPLE3.zip](< base_url >/applications/core/interface/file/attachment.php?id=11708)

8

Currently I’ve only one simple explanation for this issue: your GP button don’t work properly anymore, it seems that the contacts are defective.

 

E.g. you are writing “often the pressing+holding the GP button also gives you some note”

This indicates, that the GP button function has been triggered twice.

 

Are you using the 612-TL1100 switches from Mouser?

I’m using the same (with Wilba’s Frontpanel), and after some years and a lot of usage some buttons behaved erratic, so that I replaced them completely. It was a lot of work to desolder the buttons, but it was just necessary.

 

You can doublecheck the need for a replacement the following way:

Edit the MBSEQ_HW.V4 file with the MIOS Studio Filebrowser.

Add a # before each BUTTON_GP* parameter to disable the button assignments:

# SR Pin
#BUTTON_GP1 M5 0
#BUTTON_GP2 M5 1
#BUTTON_GP3 M6 0
#BUTTON_GP4 M6 1
#BUTTON_GP5 M7 0
#BUTTON_GP6 M7 1
#BUTTON_GP7 M8 0
#BUTTON_GP8 M8 1
#BUTTON_GP9 M4 0
#BUTTON_GP10 M4 1
#BUTTON_GP11 M3 0
#BUTTON_GP12 M3 1
#BUTTON_GP13 M2 0
#BUTTON_GP14 M2 1
#BUTTON_GP15 M1 0
#BUTTON_GP16 M1 1

store the file.

Thereafter enter “reset” in the MIOS terminal to take over the new configuration.

 

After reboot press the GP buttons and check the messages in the terminal.

 

E.g. pressing the GP1 button should only show a single:

[718809.425] [SEQ_UI_Button_Handler] Button SR:28, Pin:0 not mapped, it has been pressed.

and depressing the button should show:

[718809.969] [SEQ_UI_Button_Handler] Button SR:28, Pin:0 not mapped, it has been depressed.

If you get multiple messages, you know that the button needs replacement.

Or alternatively work with the SELECT button in future (because it seems to work reliable at your side).

 

Note: after this experiment, remove the “#” characters before the BUTTON_GP* parameters to undo the changes.

 

Best Regards, Thorsten.

9

I don’t remember where I ordered my components anymore, but according to the test you suggested, all GP buttons work without problems, i.e. only one entry for each press and each depress (I tried each GP button several times).

 

I think I’ll manage with the SELECT option. (But if something else comes to your mind, I can do further tests etc.)

 

Thanks!

10

Although I don’t really like issues without plausible explanation, I’ve to say: let’s wait until somebody else notices a similar issue under different circumstances which gives me the required input to determine the actual root cause.

 

Best Regards, Thorsten.