Machinedrum, MIDI & MAX MSP

Hello,

I’m not sure if anyone can advise, but here goes. I’ve recently started using a Machinedrum with MAX MSP. I’m sending either SysEx information or MIDI CC information from MAX to the Machinedrum. The SysEx information is fine, however, I seem to be having an issue with the CC information. On occasion the CC information doesn’t seem to register with the Machinedrum, or it takes a while for the change to register.
The other problem I’m having is that once I’ve stopped the pattern within MAX the Machinedrum continues to perform the pattern. The Machinedrum has to be disconnected and powered off to stop performance. I’ve tried all the stop MIDI instructions I can find within MAX, but all of them are proving to be ineffective. Any advice gratefully received.

Thanks

Welcome to the forum!

It would be useful to know more about the circumstances under which this happens.

Which “stop MIDI instructions” have you tried?

Hello,

Thanks. I seem to have a problem when there are a number of continuous changes happening at the same time, regardless of which parameters are being altered, and attempting to make changes while everything is live. In this kind of performance mode, certain changes don’t seem to be recognised.
I’m pretty new to Elektron stuff, as well as working with MIDI in MAX, so I’m only aware of a couple of stop commands, including note off, flush, clear and sending a 0 to a control channel.

Cheers

I don’t have my MD any more but from what I remember it’s easy to send it too much midi data so that it “chokes” on it.

Are you sending midi clock to the MD? If so, try finding another way to sync it. Also be aware that sysex contains quite a few more pieces of data than CC does. I never tried to use a Turbo midi interface with the MD, but if you have a USB one from Elektron that is definitely worth a try.

Sorry I can’t be of more help. Best of luck.

1 Like

have a look at this patch, it uses the global transport which also clocks and syncs the MD sequncer start/stop with a few extra bits. i believe the messages 250 and 252 start and stop the sequencer respectively, i found the core of this stuff on the old elektron users forum.

MD_Clock.maxpat (11.4 KB)

hope this helps

1 Like

would be helpful to know, how you send midi-cc to the Machinedrum. maybe post a building block or pic of the max environment. there are many possibilities of sending midi data to the "outside"world.

what’s really helpful is a midi-monitor like snoize: MIDI Monitor
to keep track on what’s going out and in…sometimes you spot unnecessary double/triple messages.

Hello,

Thanks for the input. I’ll try and respond in order.
The idea of the Machinedrum ‘choking’ on data seems quite plausible, and would make sense in terms of the problems I’m experiencing. The question then becomes, how much CC, as in continual, not control, data can the Machinedrum comfortably handle? At the moment I am not sending clock data. I’ll give the Turbo MIDI a try.
At the moment I am not using the transport within MAX, as the elements of the patches do not adhere to an overall timing structure, but are independent. But I’m thinking of amending things to implement transport. If/when I do I’ll give your patch a try.
The problem with MIDI CC is not restricted to one patch, but is an issue with a number of different patches/controls. The issue seems to be too much continual change. Parameter changes with SysEx are fine. Yes, I have a MIDI monitor. The issue is with the Machinedrum’s reception of data.

Thanks

1 Like

As always with Max, it would be much easier to help if you provided a patch.

1 Like

Hello,

Like I say it’s not an issue with a particular patch. It’s really about how much continual change a Machinedrum can take. The same patches work correctly on other pieces of equipment. It’s a problem specifically with the Machinedrum. Having a number of automated continual change parameters adjusted in real time creates the problem, regardless of how this patch is created.

Thanks

Can’t remember if parameter changes have an effect on the « release » portion of the hits. If not, maybe you could send your ccs only on steps ? Just a thought

Hello,

Yes, the idea of ‘steps’ was something I was thinking about. I think this is why SysEx works successfully. It was really seeing if working with continual changes would be doable, or whether I needed to think of something else.

Thanks