Issue with sending & receiving midi notes between 2 Axolotis

[jaffasplaffa]

Hello

I am experimenting with 2 Axolotis and I am having an issue with sending midi notes from one to another. I experience that the 2 midi notes send from one Axo to another "bleeds" into each other. They basicly send midi notes to both receiving gates on the Axo2.

I think the problem is that there is no midi/in/keyb object where you can set the midi channel on. You can send midi notes on a specific channel using midi/out/note, but you cannot receive a midi note on a specific channel. There is object that doesnt that, from what I know. I tried using subpatches in the second Axo, assigned to specifc midi channels to receive the midi notes, but it doesnt work either.

I am pretty sure it is a "receiving issue", cause I have previously used Axoloti to control my Blofeld by sending out midi notes to 16 channels on the Blo with no problems, no bleed. So I am thinking it must be the Axoloti that receives the midi notes that doesnt handle it right and I think a an object that receives midi notes on specific channels could fix this.

On this set up I tried using the midi keyzone to receive the notes in the Axoloti on the right, but it doesnt work. the midi notes bleed into each other:

In this set up I used subpatched assigned to specific midi channels 2 & 3, but that also result in midi notes bleeding into each other. On the right you see how the receiving subpatches are set up:

I think I did set it up correctly... Or am I wrong?

(PS. The help file for midi/out/note show up with a lot of "red objects" that doesnt load. Are they subpatches perhabs?)

@johannes, would you consider adding a midi/in/note object that receives midi notes on a specific channel?

Thanks

CORRECTION: It is actually mostly midi note 2 and above that bleed into midi note one and triggers it. Midi note one doesnt bleed into midi note two, etc.

[thetechnobear]

hmm, can't see why there would be an issue I use subpatch midi filtering all the time without issue ?!
another axo is not seen as differently to anything else, and the midi channel is encoded in the first data byte, so I cannot see how it would not work.

can you set the subpatch mode to mono and try... this should be set for a subpatch

also can you try putting on the new midi/in/monitor object (on top level patch) , this reports details about the midi messages coming in, so you can then see clearly, where the patching issue may be

midi/in objects with channel filtering could potentially cause confusion, since it could be in conflict with the filtering done on the patch level (which would 'take precedence' as the object would not ever see the message), these kind of things (especially new) users getting very frustrated with. its better to do it, in one (consistent) way.

[jaffasplaffa]

hmm, can't see why there would be an issue I use subpatch midi filtering all the time without issue ?!

No neither can I. And I have used many other synths this way and they receive the midi correct. And that is why I am a bit suspicious on how Axoloti receives midi.

can you set the subpatch mode to mono and try... this should be set for a subpatch

It is all ready set to mono.

also can you try putting on the new midi/in/monitor object (on top level patch) , this reports details about the midi messages coming in, so you can then see clearly, where the patching issue may be

I added the object. And I can see that it receives correctly on midi channel 2 & 3. But whatever is being send on the second midi channe still bleeds into the first midi channel.

Here are 2 test patches named accordingly for sending receiving. Please test it and see if you get the same result as me, that the second sequencer also trigger the first. I turned down volume on the synth for the second midi note send, so you will only hear the first synth. And I am pretty confident that you will hear that the second midiline wil trigger the first. Turn on and of the note in second midi line to test.

Ax1 Send Test 1.axp (3.5 KB)

Ax2 Receive Test 1.axp (8.2 KB)

midi/in objects with channel filtering could potentially cause confusion, since it could be in conflict with the filtering done on the patch level (which would 'take precedence' as the object would not ever see the message), these kind of things (especially new) users getting very frustrated with. its better to do it, in one (consistent) way.

I am open for other suggestions. I just want to understand why this happens. Take a look at the test patches and tell me if you see something wrong.

Thanks

[johannes]

As a first test, I copied the receiving patch into sending patch to run both parts on one Axoloti Core, with a MIDI cable connecting DIN MIDI out to the DIN MIDI in. And that works as expected, no MIDI bleeding.

[thetechnobear]

hmm interesting, I also did the test with 2 axolotis and could see the issue.
the reason Ive not posted back though, is after various tests, its not exactly clear whats going on.

the midi messages are fine, and the subpatch appears to be processing correctly.

the other thing is, it only happen when using the pulse sel on the sender, not a normal sel.
also you do not hear the issue if you switch from an adsr to an ad env.

I think but its only a suspicion at this stage (hence why i didnt post, but now I dont want @johannes to waste time testing what I've done) , it may be to do with the serial nature of midi, and sending 4 messages in quick succession, which essentially extends the gate on the receiving adsr so it appears louder (from the noise) ... it seems far fetch, but its the only thing that fitted the tests i did.

[jaffasplaffa]

Hey guys!

I have tested with midi cable direct from out to in and also using midi hub and as far as I remember both gave same result. I was using the pulse sequencer. I will do the tests you did @thetechnobear, with different envelopes and sequencers and see what comes out of it.

[thetechnobear]

yeah, also to be clear for @johannes the 'phenomenon' im seeing, and assume is the one @jaffasplaffa is talking about.

basically what I can hear is an 'accent' (so increase in volume) when you have a beat selected on the other track even though its not playing.

I think actually the second subpatch is irrelevant and probably could be deleted to make the 'bug' clearer. (I dont think i tested this though) ... I think you just need the sender to be sending on 2 or more midi channels.

i did also 'pitch' the player, and could not hear any evidence that the midi data from the other channel was being used.
also using the AD, it appeared that the voice was not being double triggered/
(I also tried other midi channels, and any 2 midi channels will show the same behaviour.)

as i say, it only appeared that the 'gate' was some how influencing, hence my tentative conclusion, that its not actually the gate from the other the channel, but more the gate of the 'correct' channel is somehow being extended.
not really 'bleeding' of data, more unfortunate timing, due to the nature of a slow serial line.

I'll say though, there is something about this hypothesis which doesn't seem right, but without narrowing down the problem further, I could not properly confirm or exclude it.

[jaffasplaffa]

basically what I can hear is an 'accent' (so increase in volume) when you have a beat selected on the other track even though its not playing.

Yes accent is probably a better description than bleed It seems like the first midi note send, get "accented" by all other midi notes that is send to it.

The magic combinations that I got working here, after reading your posts @thetechnobear is using a pulse sequencer to send the note and use ad env to trigger in receiving Axoloti. This combination works

But that kind og makes it impossible to send notes that can be hold for longer than a pulse's duration. Have tried a bunch og different combinations, also tried unsing pulse length object to get that working, but no luck just yet.

I'd like to add that I had some even stranger behaviour last night when I was testing this out. I need to test this again and I will post what I encountered later. But if I used a specific combination of objects the receiving Axoloti disconnects right away and I had control fail -1..... Anyway, will get back to you on that.

I'll say though, there is something about this hypothesis which doesn't seem right, but without narrowing down the problem further, I could not properly confirm or exclude it.

Yes there is definatly something weird going on, but not sure how to describe it.

[johannes]

I believe @thetechnobear's analysis is correct, the effect you are observing comes from the timing difference caused by transmitting another midi message on channel 3 between note-on and note-off on channel 2.
Without trigger on channel 3 the midi output is:

• NoteOn on channel 2
• NoteOff on channel 2

with the trigger on channel 3 active, the midi output is:

• NoteOn on channel 2
• NoteOn on channel 3
• NoteOff on channel 2
• NoteOff on channel 3

(both cases at the maximum speed MIDI can handle)
Now every MIDI message takes around 1 millisecond on DIN MIDI, that is not a limitation of Axoloti, but the MIDI standard itself. So the received note length on the 2nd Axoloti is 1 millisecond in the first case, but 2 milliseconds in the 2nd case.
Your ADSR envelopes are not completing the attack stage before going into release, so the small timing difference results in a significant accent.

[jaffasplaffa]

Hey @johannes

Thank you for the detailed explanation. Using a pulse seq and a env/ad works pretty well, no midi bleed. I am not sure yet how to hold notes or make some notes longer when sending from one Axo to another, just yet. Need to experiment a little bit more. If I remember correct, I think I tried usiing the pulse length object for this in the receiving patch, but I dont think it worked. Anyway, will test it again to be sure.