[BrunoParticipant]

(one note on the first step of 8 steps sequences)

[BrunoParticipant]

The same as my first experiment from a different interface (the same kind of cheap one, I have two), reflashed the firmware and initialized the parameters:
$ amidi -d -p hw:1,0,0
90 3F 7F
90 3F 00
91 3F 7F
90 3F 00
92 3F 7F
90 3F 00
93 3F 7F
90 3F 00

As your suggestion (4 channels on from a fresh init):
90 3F 7F
93 3F 7F
92 3F 7F
91 3F 7F
93 3F 00
92 3F 00
91 3F 00
90 3F 00
90 3F 7F
93 3F 7F
92 3F 7F
91 3F 7F
93 3F 00
92 3F 00
91 3F 00
90 3F 00

(this seems to be right, no? notes on and off on different channels)

I used 4 instances of a synth (amsynth) and it worked perfectly after the init, until I started to mess around with the notes, mostly using the wave generator and change all notes, so things that messed with the patterns a lot, for notes and mutes. After a few of these changes the channels become all messed up. There are some notes on the correct channel only if I have more than one channel ON, if I have each channel ON solo I only get notes on channel 1. I can recreate this every time.

Oh, and this is after I restarted both the USB interface and the bcr (storing the pattern and recalling it), the behaviour continues.

And it gets weirder… It only works perfectly as I said above if I have 4 channels running. This way the routing to each synth works well, if I solo a channel everything starts going to channel 1. If I mess with the patterns things start to get weirder, because if I have notes on the same step in different channels they go to the right channel, if notes are solo on any on channel, they go to channel 1.

Is there a way to dump the firmware or the pattern so I can send you? Could you understand what’s the problem from that?

Here’s another try with 8 steps sequences:
ch1 solo
90 3F 7F
90 3F 00

ch2 solo
91 3F 7F
90 3F 00

ch3 solo
92 3F 7F
90 3F 00

ch4 solo
93 3F 7F
90 3F 00

ch1+ch2
90 3F 7F
91 3F 7F
90 3F 00
90 3F 00

ch1+ch2+ch3
90 3F 7F
92 3F 7F
91 3F 7F
92 3F 00
91 3F 00
90 3F 00

ch1+ch2+ch3+ch4
90 3F 7F
93 3F 7F
92 3F 7F
91 3F 7F
93 3F 00
92 3F 00
91 3F 00
90 3F 00

ch2+ch3
91 3F 7F
92 3F 7F
90 3F 00
91 3F 00

ch3+ch4
92 3F 7F
93 3F 7F
90 3F 00
92 3F 00

ch1+ch3
90 3F 7F
92 3F 7F
90 3F 00
90 3F 00

ch1+ch4
90 3F 7F
93 3F 7F
90 3F 00
90 3F 00

Does this help at all?

• This reply was modified 10 years, 1 month ago by  Bruno.

[BrunoParticipant]

I can confirm issues with FF here. The download fails from the start or during the transfer. I tried the same link with wget and got a 500 error (FF didn’t show an error).

With Chrome it worked without issues.

[BrunoParticipant]

OK, I tried to get what the zaquencer was sending to the interface from a clean init, and just outputting one note on each channel on first note of each row (muted all others, ch1 in row 1, ch2 in row 2, etc):

Waiting for data. Press Ctrl+C to end.
Source Event Ch Data
0:1 Port subscribed 129:0 -> 134:0
20:0 Note on 0, note 63, velocity 127
20:0 Note off 0, note 63
20:0 Note on 1, note 63, velocity 127
20:0 Note off 0, note 63
20:0 Note on 2, note 63, velocity 127
20:0 Note off 0, note 63
20:0 Note on 3, note 63, velocity 127
20:0 Note off 0, note 63

The notes on are arriving on a channel below the expected (is this just an error from the software interface?) but notes off come on the same 0 channel.

So, if channel 0 here is the omni channel that goes to all channels, I’d get notes off for notes on different channels, so they’d clash, right?

Now if this is the case, is this an issue with ALSA or my MIDI interface or something on the zaquencer?
Maybe I flashed it wrongly?
Should init reach the bottom row of encoders? Here it stops on the previous to the last.

Thanks!

[BrunoParticipant]

Hmmm is it possible that these simple midi interfaces can’t handle 4 channels simultaneously, right? Could this be the problem?

[Author]

Posts