I’ve just got a M-Vave Chocolate bluetooth controller pedal & MidiPort that I wanted to use to simply start and stop the current pattern.
The app allows me to set the footswitches to Start / Stop Current sequence but the model cycles doesn’t respond.
I’ve got MIDI ports = M+U inp from
In channels unaltered
Am I missing something obvious? I’ve seen in some other threads that transport doesn’t work without clock? I’m new to this so please bear with!
hi
Channels isn’t a factor here, transport controls are part of ‘system’ realtime messages
i know the Model series group the transport rx/tx (receive/transmit)
so one toggle will enable/disable clock send and transport send rather than setting those individually - make sure this is enabled to accept incoming control of transport
Now if you send a standard start/stop message i would not expect that the MC would look for clock arriving too, it should react to the message and use its own clock settings … can’t say i have tried, but that would be disappointing
sounds like you have the wrong setting there or you have not configured your MC port to be a type A (default) midi dongle (assuming you are using the one that Elektron ship with teh MC)
I’m fairly sure that the M:C adapts itself to either polarity of midi input (which is what we’re concerned with here). It’s midi output that has to be explicitly configured in settings.
it does indeed
indeed it is, so those discussions were accurate
If you enable settings/sync/ CLK IN to on it will cue playback but won’t proceed without clock being fed !
you can enable clock and the pattern will then play, and it will continue even if you kill the clock … so it doesn’t need it, it’s just defaulting to looking for it which i find a very strange choice and i am at a loss to understand it … it’s feasible that a very sophisticated midi device would allow sending a custom midi message and in this case you could possibly trigger it with a single clock message (or a few) … but without trying this in Max/MSP it’s hard to know whether it would run at its own sync rate after you trick it to run
i am confused about that constraint, especially in this circumstance where a device is used to remotely start/stop … my os isn’t up to date, but i guess this is the issue
nope - make a feature request or ask support if it’s already planned or not !
Is it possible the Models were designed simply to work with eachother (which they do just fine) or within the Elektron ecosystem, but not particularly with devices outside that ?
I suppose I’m asking, are transport commands without clock a bit of an edge case ?
Whatever … a feature request is in order, regardless of how this came about.
i really don’t think so, it’s a regular requirement, especially when you have a device with good clock to play … whether the MC MS are seen as poor brethren of the other devices or not or are simplified (too much) to make them approachable
it won’t affect many users in the grand scheme, but it also wouldn’t be an issue to add the flexibility by separating the setting of clock and transport reception
it doesn’t affect me, but i can empathise with anyone affected - i’d like to think they’d address this longer term if people asked for it
or just allowed the device to use its own clock - or more accurately allow a setting for Transport in e.g. a third option for CLK In …
So it’s On / Off / Tpt
(Tpt) : where it uses its own clock but also listens for Transport
Thanks for your input everyone, if I’ve understood it’s not a problem I’m going to be able to solve.
I can stick in a support case/ feature request but I suspect a result might be a long time coming if at all.