I am beginning to wonder if the MIDI implementation in the M:S rather incomplete. My DAW does not receive the MIDI data:
when I use retrigger (recording it and sending the data back to the M:S results in a black gap where I used “retrigger”).
when I change parameters with “CTRL ALL” selected (No CC is received by the DAW)
when notes have specific parameter locks (for example the pitch), these parameter locks do not get send as MIDI CC data. However, changing the parameter on the fly does generate MIDI CC data.
Is this a configuration problem that I am running in to, or is MIDI not fully implemented in the cases I described above?
not really - it’s what I’d expect the outcome to be on all three fronts
retriggering is internal seq fn
control all is internal function
there is no CC sequencing - the values are only transmitted when the encoder is twisted
it’s a device that’s designed to be played - most Elektron’s are performance orientated and users will bemoan the lack of a midi equivalent command, but that’s the way it is to varying extents across the range - you have to make the most of what you have and use it accordingly
I would like to use the S:M in my workflow as a means to create rhythms/loops/whatever, and then import these data into my DAW for final editing and finetuning.
Guess I will have to switch to a workflow where I import the M:S loops in my DAW as wave-files, instead of MIDI data.
I was hoping to use the model:cycles as a performative midi sequencer to control VSTs in a DAW and/or other hardware synths.
After having limited success, knobs do send CC messages when turned but do not forward the p-lock values, I went on a search but couldn’t find any conclusive answers on how to achieve this behaviour, or if the M:C is even capable of this.
I did find that OT and DT (and maybe others?) are capable of doing exactly that. If what I’m reading is correct, they do send out p-lock values over midi CC. And so you can p-lock values on external (hard or software) synths, as well as retrigs and so on.
Then I stumbled on this mini thread that seems to imply that M:S (and so most likely M:C) don’t do that. That would be a big bummer. And it seems like an intentional debilitating of their product, as the hardware is there and the software is inhouse.
Implementing these features would turn the model series into some great and affordable elektron style midi controllers. (Which I was hoping they were)
But alas, if what avantronica says is true, it was all just a pipedream.
I’m not sure I think of it that way. I think they were designed as standalone grooveboxes, nothing more. You can’t even combine a model:samples and a model:cycles in a useful configuration without adding something else (a mixer) because the model series doesn’t have an audio input allowing you to mix the two.
It’s also also quite possible the software was built from the the ground up, (rather than starting with all the features and cutting them out, which seems to be your train of thought, perhaps ?).
I do agree with you, though, it would be useful for them to have included that feature.
I fall into that trap all the time when figuring what to buy next. “Right, so it’s a sampler, so it must do [X] right … though, maybe …” (does some research) … " oh, it doesn’t do [X] at all".
True,
in my defence, as other elektron machines do have those features and even after I’ve been playing with the M:C and know what to look for, it wasn’t easy to find a definite answer, I see how I overlooked this.
Also, what makes me think this is intentional is that, all instructions are there internally and the infrastructure to communicate over midi is there as well. Sending those instructions over that infrastructure isn’t the hard part of developing the software.
To me that sais that there was a conscious decision at some point, not to do that. As I don’t know the reasoning behind that decision, I can’t say if it’s a good or bad one. But I’m convinced at least one of the developers or betatesters came up with the idea, don’t you think?
Anyway, you live, you learn. It’s all good and who knows, maybe they find the need to implement it after all!
No they don’t .
You may mix that up with the Midi-Tracks they have.
In the Midi-Tracks you can define CC’s and send them sequenced. But the Synth/Sample-Parts are not sending the plocked values at all.
Imagine how much data would be transfered each step when using it excessivly.
It would end up in constant hickups as Midi-Bandwidth is fairly limited.
I suppose I am talking about the midi tracks on the OT and such. As the M:C doesn’t have separate midi tracks that would not apply there.
The amount of data would still be under your control tho, as you still have to switch on the MIDI out on a per track basis.
As you say, the limiting factor is the serial implementation of the midi protocol for each of the 16 channels.
But it certainly isn’t a computational problem. For all intends and purposes midi is a low density data protocol. Also, other gear seems to handle it just fine.
BTW I’m not trying to ditch on elektron gear, I was just surprised of the way it’s implemented.
Now that I know, I can keep that in mind in my workflow.