Have all incoming midi converge to one and sent to the active track.
Use omni-mode, where each track corresponds to one midi channel, which is just too rigid. No customization.
Proposal? As each track has an MIDI output channel, so each track should have a MIDI input channel. So that track would always listen to the input of that channel, regardles if it is active or not.
This would solve so many issues!
Controlling multiple tracks with one controller! - Set up multiple tracks to listen to the same controller channel and control them at the same time with different FX on each! Layering!
Having dedicated midi input and output one track, so having full control over instruments with “local control” off. (Regardless of which track active, they would send and receive perfectly).
Multiple tracks for one instrument! Having two tracks receive and send to the same channel with differet FX (think of having different chance/scale!).
And all this would record! - No longer would you have to swap tracks mid performance to not send wrong MIDI data to the wrong channel. Press record and start playing! Everything would be sent to the correct track and outputted to the correct channel!
These are a few possibilities that would be possible! This would really open up the Pyramid!
Drum mode!
If the definitions note filtering get fully developed, the Pyramid could actually work as a real drum sequencer! One could set each track to listen to the corresponding drum MIDI messages and filter out the correct notes. So you could set up a “kick” track, a “snare” track etc. Press record and play your drums in from a controller and have all the parts get recorded on separate tracks!
Maybe one could set the MIDI input channel with “2nd + MIDI Input”.
+1!
I agree
I thought the v3.0 would be an opportunity to finally have more options on the MIDI inputs management
this seems to me really essential for a MIDI sequencer.
Indeed, configurations (and needs) can be very different from one user to another, but this could solve so many issues.
I also use the iCM4+. This does not and cannot solve the issue. At the Pyramid side it will still converge all the incoming MIDI to the active track. The only other option is the OMNI mode, but that has absolutely no customization options and still cannot solve all the issues.
I too use an ICM4+, it is great.
But I doesn’t let me do all the things I want.
With individual midi in per track we could conveniently track incoming midi on all receiving tracks. And without using the MULTITRACK feature as implemented right now which is too restricting for my use case.
Wait up. The ICM devices do channel routing and remapping on all ins and out though. So if you have a controller that sends on channel 5 but you want to control Instruments on track 4 or 8 or 11 (or all 3) in the Pyra, can’t you just remap midi Channel 5 out on the controller (connected to an in on the ICM) to Channels 4 ,8 and 11 in the ICM and route them on to the Pyra IN (In Multitrack On Mode)?
Pyramid just uses the midi channel information to know which track to send midi to, right? And the MIDI out channel on the Pyra track just sends it where it needs to go. The fact that it’s coming in on Ch8 just sends it to track 8 where the track’s designated output channel routes it to your synth - whatever MIDI channel that happens to be listening on.
(If that’s not the case- I can’t check today - then you just do the remapping to they synth in the ICM interface)
Then for layering, send MIDI out to ICM on whatever channel/Track you want on the Pyra, duplicate it to however many channels you want to layer in the ICM, remap these to the channels/tracks you want to layer up and send the MIDI back into Pyra in Multitrack mode, pyra applies the FX to the incoming MIDI and drives the synths from there - on whichever MIDI channel they are listening on.
OK so you only have 16 possible routing options and this is no good to composers who don’t have ICM devices. And the mapping/routing interface in the ICM devices is a bit of a headspinner. And I get that you want to be able to save this stuff into a Pyra project rather than relying on another interface.
But it solves the layering on the outs and the controller to track mapping on the ins for those that have ICM devices.
Thats two. You need a PC and configurations are fixed. We are asking for a way to do this inside the Pyramid per project.
Third? Customization.
Having your own track bank layouts. Not having that 1-16 channel logic. Have it mixed. Some tracks have dedicated MIDI input, some not etc. Layering track next to each other etc.
Also this is pretty big.
What we are asking is not “big”. Its a small touch. And it would open the Pyramid up to EVERYONE.
You can save and load multiple configurations in the iConfig interface. So you could have one for each Pyra project. I know from comms with them that they are looking into ways to hot-swap between saved configurations without having to load up the iConfig application. Maybe in time you would be able to do that with a programme change or similar from the Pyra to the ICM leaving the PC off, but not right now.
And yes, you need to have your PC switched on and connected to the ICM device to manage configurations and that doesn’t work for some people.
Also, I shoulda said, I use an MIO 10, so I am not short of ins/outs which makes the multiple configuration piece much more straightforward. And I can have pretty much everything I need always connected without using merge or splitter boxes or chaining devices or fiddling around with MIDI/USB leads. And I use other sequencers and clocks alongside the Pyramid (Novation Circuit, Bitwig, Electribe, ERM Multiclock) so routing and re-mapping channels, loading fresh configurations is kinda ingrained in my workflow)
I guess my point was that via ICM, 16 tracks do have their own input and output channels and you can largely achieve points 1-4. Albeit with some bothersome limitations.
BUT - Completely agree that ideally, it would be nice to be able to manage all this within the Pyramid. The iConfig app is baffling at times. I have given up on complex routings many times because I’m gazing at the computer trying to fathom the Iconfig interface when I could/should be bashing pads and tweaking knobs and vibing.
If it all happened in the Pyramid as you rightly propose I could get more done quicker. So this proposal is one I wholeheartedly endorse and your suggestions are super smart, as ever.
Haha, I’m glad I’m not alone - I’ve found myself in that scenario too many times. truly is some counterintuitive (albeit powerful) software.
The point is that it defeats the purpose of a hardware sequencer if you’ve got to carry around a PC to configure midi with an external bit of hardware. I’d hazard a guess that many people gravitate hardware not only because it’s trendy, but because they’re sick of staring at screens all day and just want to play some music. On top of being a killer sequencer, the Pyramid could certainly allow a more flexible connectability. I use an ICM box and yeah, it’s great, although it sometimes glitches and needs to be reset - I would much prefer to configure the routing per project rather than having to interrupt the flow and stare at the shitty routing matrix in some confusing software. I change my setup constantly as I go, and anything that eases workflow and allows less time wasted troubleshooting is a huge boon in my book.
I don’t expect the Pyramid to do what ICM devices do, but simple in/out options would really open up the possibilities for users (like myself) who use several controllers, like stacking voices, and like to record several tracks at once in live mode. Yeah, I know it’s possible, but it could be much simpler to pull off.
Ok I never actually use a controller with my Pyramid, I can see why this proposal would be desirable though - but what would happen if the user wanted the current behaviour - eg just to have their controller set on say ch1 and then only have the cuurent active track recieve data from the controller? How would you cater for this?
Maybe a long press on an encoder could toggle between the mode you suggest and the default mode? Or maybe it could be set in settings?
I see, what about Pyramidi messages such as muting tracks with controller notes, how would it still be possible if users were using all the available input channels like in a large setup? I’m not trying to be difficult here BTW I like your idea.
The only option we have right now to do something like this is to use “OMNI MODE”, which routes ALL 16 channels to 16 tracks inside a bank. Yes, thats ALL 16! Thats exactly what this solution would solve, giving the user the ability to define which tracks listen to which channels.
Yes but if all the channels were being used how would pyramidi control be possible? Maybe in the def file the input channel could be specified, and then if the user wanted to use the pyramidi control a key combo could be used to turn on pyaramidi and simultaneously turn off the individual channel input routing of the definitions?
What I mean is if all 16 input channels are being routed to tracks then using pyramidi functions won’t be possible as it requires a midi channel. If the proposal you suggest was added then some way of toggling the behaviour would be needed so that pyramidi functions could be used.
