Hey Chris, I just tried this and was able to get it working. I will send you an email with more info, rather than bog down this forum with techno babble ;)

So I added a names.c to the 3x3 example sketch, and it all worked as expected with the CME H4 after uploading it to the ARP. The names.c was pretty much a carbon copy of the actual strings that the real ARP uses. I didn't add a MIDI_PORT1_NAME to the names.c though, as I believe that port names are no longer supported by default with Teensy 4. I also added printing to Serial to see if that made any difference like I initially thought, but even with printing to serial, the H4 was still able to receive MIDI data from the modified ARP. So I'm at a loss as to why the OG ARP doesn't work with the H4. The lights on the H4 do blink when the ARP is transmitting MIDI, but for some reason the H4 doesn't like it. I'll send a message to CME to see if they have any ideas, and I'll try out some of those other differences that you mentioned.

Sure I'll give it a bash later. I don't think the name.c file will make many difference though. My Teensy Midi interface also uses a name.c and is working ok, but I'll have another play.

I did video this process ... https://youtu.be/7uvG3U-wjiI?si=FvMr7Df1XDrvwDGp I had to use a portable version of Arduino purely because it has a vanilla copy of the Teensy core files with no edits.

No worries.... Purely out of curiosity, I just loaded up the example Teensy USB MIDI Interface sketch in Arduino (File>Examples>Teensy>USB_MIDI> interface_3x3). Set the USB type to ''Serial + Midi'', and uploaded it to the ARP (basically turning the ARP into a Midi Interface.... Not recommended to others), and the CME H4 was able to successfully receive Midi data from the ARP via USB. Not sure what to make of that, but thought you'd like to know.

That's a shame. I know the early Novation 'Launch' devices have weird USB descriptors. My Lanchkey mini Mk2 doesn't work on the H4, but it's USB descriptors are a bit odd, and also give an error when using TDD to analyze them. I think some gear which also sends Audio over USB (like the TR8, and seqtrak) are also not supported on the H4. Also the H4 also only supports full speed USB (1.1 or 12Mbs), which I've heard that some Roland gear doesn't support anymore. I'm surprised that you couldn't get it working though. My Teensy USB device works fine (even with 16 virtual ports). It has identical descriptors to the ARP (apart from the string data), so I could only assume it's something else. I'm in the CME beta group, and have spoke to the developers quite a bit, so I'll get in touch to see if they have any ideas, or possibly solutions.

So I've had a little play this morning. I tried my Teensy USB Midi interface using the exact same default Teensy USB descriptor as the ARP (Midi + Serial) and the Midi interface seems to work fine on my H4, so I don't think the descriptors are the issue. The only thing I can think of right now is that the ARP does send CDC (serial) messages over USB as well as Midi which may be confusing these host devices like the CME H4 as they are only expecting class complaint Midi. Might be worth completing disabling printing to Serial to see if that fixes the issue? (You could try the 'Midi' only Teensy USB descriptor, but even that has a emulated Serial device built in, which may have the same problem?). HTH

Can confirm that although the CME H4 recognises the Midicake ARP when plugged into its USB host port, it does not seem to be correctly receiving Midi Data (i.e not receIving note offs). ARP's USB Midi seems to function correctly when plugged directly into a USB port with Windows. Not sure if this is an H4 or ARP issue. The H4 has had some compatibility issues and can be a bit picky when it comes to usb descriptors. My Teensy based USB Midi Interface seems to behave ok with the H4 and correctly sends note offs (although I have changed the default teensy USB descriptors a little). Will try to spend some more time on this over the weekend if I get a minute or two.

Could you not just do an additional Firmware build that has a different Name (''MIDICAKE ARP2''), & different PID, and supply it on demand to people that have two (or maybe more) Arps?

There is a sneaky way to change the device ID (VID/PID) by editing the firmware file. I've had to do this in the past due to multiple Teensy based devices conflicting with each other as they've used the same USB VID/PID. It's easy to do, but probably not recommended as this could make bad things happen if you get it wrong. Maybe if you ask nicely enough, Chris could sort you out with an alternative firmware file that has a different device PID?

Maybe try setting Midi Control Mode to On in the ARP, and then in the Digitakt preferences only have it send clock messages only, and deselect "send transport". That way the ARP should stay in sync, and won't receive Start/Stop messages from the Digitakt (although that might not be suitable if you have other gear that relys on the start/stop commands from the Digitakt) It 'should' allow for Live Play, whilst keeping clocked to the Digitakt. It might work better?

Hey Chris, Quick question about 'Live Play'.... I noticed that baj said they tried 'Live Play' on the ARP but couldn't have the clock sync'd, I guess because pressing play on the Digitakt would start the ARP sequencer. Would it be possible to have an option so that ARP ignores start/stop messages, so that ARP can still be sync'd up to external gear, but not start the ARP sequencer, so it would still allow Live Play whilst being in sync? Quantized notes from external sequencers should work better then? Does 'Live Play' start playing instantly on Note on messages, or does it still wait for the next tick when the ARP sequencer is not playing? (I'm not at home at the moment so can't test.) Hope that makes sense.

Is it because the Hardware ID's (PID & VID) are matching in the usb descriptors? ....... Just curious

Hey... Yeah it's a bit of a problem with MPC's.... I think it may be worse than you think. A 'Note Off' message on ANY MIDI channel that the MPC receives (from a single port i.e from ARP) will affect every other MIDI channel it is receiving regardless of MIDI channel, so using an MPC is still broken if you want to just use it as a sound module because it's not processing multi channel MIDI input correctly. You will get some sound from the MPC, but it's probably not the same MIDI data that the ARP would be sending. Drone notes are completely out the window! I've looked into this a bunch, here's the video I sent Akai..... https://youtu.be/ZA0X3J53R3w?si=sjrlk6CdEFozz8ji There are some workarounds to this.... I've made a custom MIDI interface purely so I could use my ARP, and DIgitone with the MPC without it messing with my MIDI. Some more info here: https://www.mpc-forums.com/viewtopic.php?f=48&t=217906 If you need any help sorting something like this out I'd be glad to help!

Ok scrap that..... I thought pressing stop once will keep any played notes held, I didn't realise they will stop after their gate time... Sorry bud! ....but I think separating them anyway like you have wrote there would still work..... Say If you wanted to stop the notes early, but not cut all the sound.

Ok bud, Functionally I still think I would prefer if CC123 & CC120 was separated somehow, and not sent together, so the synths gets chance to play out any release, but we'll see how you get on.

One thing I also forgot to say on this..... I think it would be cool if CC123 and CC120 were separated anyway, and not sent together. Sent at the same time, the synth sound will potentially stop dead! If CC123 is sent out first (by pressing stop twice) the synth will at least get the chance to let the sounds play out any release stage nicely, so to not cut the sound off immediately. I would definitely prefer this. Then provide an alternative means to send CC120, like the physical only long press on the stop button perhaps? What do you think?

So I found this thread from a few years back. Seems to vaguely discuss this issue. https://www.elektronauts.com/t/cc-120-all-sounds-off/8677 Seems that when Elektron gear receive a CC120 message they will assume a 'Panic' button has been pressed, and in turn will stop their sequencer. It seems that perhaps this is by design, but would explain the stop messages being generated. I think the Digitone only responds to 10 midi channels at a time, so that should account for only 10 stop commands showing, and not 16. I think a good solution would be to keep CC123 sending as is, but to only transmit CC120 when physically pressing the stop button on the ARP only, and not in response to external stop messages. Maybe a quick double press (or long press) on the Stop button to trigger sending a CC120? Thought this might help.

Just to be clear..... Sending CC123 All Notes Off from the ARP to the Digitone doesn't generate any Midi on the Digitone side whatsoever, and doesn't cause a loop, so I reckon it's safe to keep CC123 being generated by ARP. The stuff that the Digitone did generate was only caused by the CC120 All Sound Off messages. So maybe just stop ARP generating CC120, but keep in CC123?

Here you go bud! https://youtu.be/4xCeDoh1hc4?si=SnoZIhvBVR4n9mwC