Hi, simple question, spent way too much time figuring it out by myself: How can I switch off midi thru?
Whatever channel I set my master keyboard to, Pyramid will forward that channel on its Midi A output. I have Pyramidi off, Omni to ch 13. The “Midi Echo” setting doesn’t make any difference. Midi out settings are set to “out” for all 3 ports.
This is highly annoying, and I just cannot figure out what’s wrong here. I don’t want any midi thru at all on the outputs, and thought that Omni set to ch 13 would acts as the auto channel on Elektron boxes: anything received on Ch13 will play through the selected track, any other channels are ignored.
Thanks!
EDIT: this is the culprit:
CH01 to CH16 will play events of the selected channel on the current track. Other channels are always sent thru MIDI A output.
So I conclude I can’t switch that off. Super annoying, and this will probably lead to me selling the Pyramid. It can’t fit into my workflow and set-up if we can’t have full control of midi thru. The only way to prevent this seems to be the sacrifice a whole port using MULTITRACK BANK X.
Configures Pyramid MIDI out A as a MIDI out (default), as a MIDI thru (all messages received on the MIDI input will be sent directly on the MIDI out A), as a MIDI out + thru (all messages received on the MIDI input will be sent directly on the MIDI out A, together with Pyramid MIDI messages).
It’s possible to speed up the midi A communication up to 6,7 times and avoid latency problem, when sequencing an Elektron machine (Analog Four, Analog Keys, Analog Rytm, Octatrack), by using the TURBO MIDI protocol.
By the text from the manual above it seems it’s quite easy to choose whether to use midi out, Thru or both ?
Nope, this is overridden by the Omni=Channel mode, as I discovered. But I found a workaround, I just filter out all incoming channels except CH 13 on my midi interface. So if I want to record something on the Pyramid I just choose Ch 13 on the master keyboard and select a track. And if I play a synth on whatever USB channel, I don’t have a second synth on Port A playing along.
Will not sell the Pyramid yet, finally. But I’m getting a bit frustrated with the workflow, I must admit… Bought it because of the weird midi implementation in the Elektron boxes that drove me mad, but I discover weird choices in all the modern hardware sequencers I try, as if we need to reinvent a personal wheel all the time. I don’t remember having all this fuss to deal with when I used sequencers from the 80’s, they just worked as expected…
with complex setups, different setups are going to require different configurations.
so for some, having the Pyramid pass the midi thru is a logical thing to do IF you have specified the pyramid should only use 1 midi channel for input.
why send it midi data on a different channel if your not going to do anything with… if seems reasonable to assume its because you have it in a chain?!
but for sure, I can see if you set this up at one point, it’d be easy to forget this is the case.
perhaps you can send an FR to Contact us | Squarp instruments for what you would prefer (e.g. some extra midi thru setting?)
thats kind of the ‘nut’ - the choices are not ‘weird’ , all design decisions are done for a reason - but they just might not match your needs/setup/expectations… we all have different ways we use things, so you can’t please everyone all of the time…
unfortunately, at the end of the day - you have to find things that you can work with, or move on… find something else that works better for you.
Oh, I quoted the issue 2 times already: If we choose to set Midi Out to “Out” instead of “Thru” or “Out&Thru” but want to use the convenient Omni “channel” mode then the Midi Out setting is reverted to “Out&Thru” for port A only, as per the manual:
OMNI is a bit of a misnomer… it really means , how does the Pyramid react to midi input on different channels
OFF = ignore midi channel, send all data to active track
Mulitbank X - use midi channel to select track on bank X
Ch X = use ch X for active track, and forward all other channel to Midi port A
@roadmoviemusic would prefer Ch X , just ignores other channels.
Well, it is just classic use of a master keyboard where you dial in the channel of the expander (as they were called once) you want to play. So if you have synth A on USB Ch1 and synth B on Din midi A using all 16 channels, and use CH 13 (or whatever) for recording into the Pyramid, when playing synth A you always have some part of synth B playing along…
Main issue was that Elektron sequencers don’t send a CC or PC if it has already been sent before, and, concerning the Octatrack, that the channel the OT listens to is not fixed, but something like IIRC “the first available audio channel that is not used by a midi channel”. And there was some midi thru stuff as well similar to what we’re discussing here, plus the fact that the OT default commands are Note messages, and all ended up to be pretty unpredictable. When you use many of these complex devices, you easily end up spending hours to figure out what’s going on, before turning to the forums and look for input (thanks everyone, btw, much appreciated!).
not quite sure I follow… use Midi port B?
honestly though, I generally use the pyramid as the central hub, so I always want midi data going thru it, and then it routing it (so I use OFF, or Multibank A)
but for sure, I can see, there are lots of other ways others might want to configure it - so that raises other needs.
and for sure, I think most of us think the ‘input handling’ is a weaker point on the Pyramid, e.g. DIN A/ DIN B / USB cannot be used for selection , and many have requested ‘per track’ input selection.
(similarly, Ive requested a ‘multibank’ option that would target the active bank, rather than being fixed to one bank)
so as a ‘midi router’ in a more complex setups it is not ideal.
I’ve used a blokas midihub to solve some issues (similar to yours) , and now moved on to an iConnectivity mioXM (as I needed more usb midi and also rtp midi ) … but yeah, its ‘another’ box, and yet more cables
My main midi hub is a iCM4+ (using all ports and RTP midi too) , then in addition I use LiveProfessor on a laptop for some more complex routing presets or specific stuff you can’t do on the iConnectivity interfaces. I don’t use the Pyramid as a central hub, it’s “just another hardware sequencer” in my set-up. So if I decide to use it for something specific, I don’t expect it to make decisions of its own: If I set the Midi Out function to “Out” it should be “Out” all the way. Not “Out but …” !
I’m a musician, not a mathematician…technology is there to make things easier, not more complicated…
after reading this long list of posts somethings comes up for me :language is the problem here, and a few other things too… If there is a set terminology for a function then it must be respected. if every developer uses his own terminology, a lot of time is wasted trying to figure out things that would transparent otherwise . In terms of implementation of features, same could apply after the users have tested the system. It’s not just a matter of taste. I have been working with MIDI since the very beginning (yes that’s right and I di not have a long white beard that step on) and I find that I waste a lot of time figuring out the peculiar implementation and documentation (including non standard language). I was a synth and MIDI programmer in the very first studio in NYC to offer full programming services, I should not be sweating to learn a new device. Things need to be cleaned up a little and yew we do use our devices in multiple configurations which lakes it more complicated; all the more reason to be methodical with language and features: that’s why MIDI ws invented in the first place!
I absolutely agree with you. I was pioneering midi in the early eighties, I owned what I believe was the very 1st midi interface (from Sequential Circuits) that plugged into a Commodore 64… been a VST coder as well… was doing intensive midi sequencing on the very 1st MacIntosh using Performer 1, after making a lot of stuff with a Yamaha CX5, I’ve been through all that.
