Yeah, the problem is that the pyramid requires extra tools for basic midi routing, but even with the iconnect (which I use and love) I cannot get the pyramid to record on two channels simultaneously. I’ve given up on multitrack mode because it’s just too clunky as it’s limited to one bank.)
2 Likes
unfortunately, given the UI changes that would be required to support this, I see it highly unlikely this is going to be done on this pyramid hardware.
(and it would be a bit of a pain if this was done using files like the def files)
perhaps as a workaround you could use a BomeBox or (when its released) Blokas MidiHUB.
with this what you would do is:
setup pyramid as multichannel
then actually configure the routing to these channels in the BomeBox, midihub - this could be based on anything , so midi note, or incoming midi channel.
sure its another box, and you are still fixed to one bank, but might be workable until a better solution is available.
1 Like
honestly I don’t see a lot of UI changes that would be needed to do that
we already have a screen that allows us to quickly select an output for each track
individually
(with the TRACK + MIDICHANNEL shortcut)
the five encoders allow quick access to different outputs
so we could imagine (for example) that the main encoder would allow us to choose the input midi channel for that track…
1 Like
I am with @art33 here. This should be a UI thing. The Pyramid already can tell the difference of the incoming MIDI by channel. As I posted 4 months ago…
Just asking for the user to be able to select that channel for each track.
I have thought about this before and I believe you are correct. The only problem here is that it would be a static setup. You would need a PC to change anything in the setup. Not really the goal of any of us I believe.
2 Likes
except that wouldn’t work would it…
this is not just about channel, its also about source i.e. DIN or USB
(without this distinction it would be of limited use to me)
then this has to be stored per track, so has a memory hit (something we know is short)
also it fundamentally changes the fact that one midi event is processed on one channel, this means multiple tracks have to be processed per midi event - this obviously would have performance impacts, and possibly introduce timing issues.
(this could be avoided IF a input source could only be used on a maximum of ONE track, but thats a hard thing to enforce without adding some complexity in the UI)
dont get me wrong, as Id stated on this thread before Id love this too…
in its simplest form, Id like to be able to say midi form by USB device goes to one track, and DIN to another
yes that’s true… there is a USB input too
(for now it’s so not handy that I forgot this one)
I don’t think it’s a problem to go through 32 different values with one encoder though
so it is not necessary to have a choice between usb and DIN I guess
but anyway, you’re right, the main problem may be a memory issue
again!
(don’t know to what extent memorizing a midi channel for each track would take RAM ressources…)
no, I don’t either, but its a different UI, and is also a little inconsistent with whats there already.
likely 64 bytes, which is not much.
however, this would introduce a cpu overhead, as you’d have to scan thru the entire set for every midi message to determine which tracks to send too, to avoid/alleviate this requires a more complex data structure = more memory.
( remember currently the midi message tells squarp directly which track to go to … its either the active track or bank X + midi channel)
I think the one midi event-> multi track is the much bigger issue.
I think it nigh impossible to expect one midi event to be processed by multiple tracks, as the impact on processing is just way to significant, and could cause a whole stack of other issues.
but that means you need to change the UI to only allow one active track per input source, and that would require much more complexity in the UI than is currently present.
(and making this so that the user is clear on whats going on, is very difficult)
this is the problem with many of the requests that ‘seem to have been ignored’ by Squarp.
they might seem trivial (or obvious) to the user making the request, but often there are many things that make it more complex, or technically not really feasible.
its a tricky one, of course we see all these features on DAWs on PCs, but they have processing power (and memory ) orders of magnitude greater than the pyramid.
Squarp have done an amazing job at squeezing what we have into the processor available, whilst also maintaining its timing. to do this requires a pretty tight design, which might also mean adding certain ‘unplanned’ functionality at a later date is extremely difficult without re-writing lots of code. (unlikely at these stage of product development!)
its a real juggling act, unlike on a PC, where often, new features is ‘just’ a matter of development effort (ok, thats a simplification)
I guess what I’m saying is… its likely many of these requested things, are likely hard/impossible to do, rather than squarp not agreeing, or wanting to do the,
perhaps they should articulate this, but often end-users don’t want to hear this, they just want their favourite feature, and unfortunately will ‘discuss’ it to death 
All UI challenges aside, I don’t think it would be a problem to have a track only respond to its assigned input channel.
I would be fine if we had to have the track active/selected when recording. It’s just like the way it is currently implemented. No other tracks would have to be taken into consideration, hence no memory issues.
1 Like
thats a pretty big limitation…
id assumed from previous posts (include OP) , others wanted to act more like a customised ‘multitrack’ rather than a variation on active track.
(also the current multitrack functionality would not work with this variation, since its dependent on midi channel, so it would never match a customised channel - change that to being allowed, and your back to the issue i already highlighted)
still memory required, as you need to store in the project, which midi source you wish to respond to per track.
but for sure, this could be really compact (64 bytes, perhaps a bit less with some bit twiddling, as you only need 0-32) as you can then index of active track - so no need for complex data structure.
Totally. Your post makes perfect sense.
That being said, I would say it’s mostly due to the fact that the Pyramid is really close to be a complete midi sequencer
that’s the thing
of course there will always be some missing features for some users
but I mean by that, there are also just a few requests that come back over and over (I am now a former user of Pyramid therefore I can testify about that)
and we can see that these same requests also come very often from brand new users, after a first takeover of the machine, or even from potential buyers who want to know if it is possible because they didn’t see it in the manual
these few points of improvement are known
I will not quote them here (they were relayed by others already)
so it’s mostly frustration I guess
I know you (@thetechnobear) don’t think that Squarp will bring another hardware evolution without changing a lot of things in their product
but still…
maybe a mk3 with a more powerful engine would be the only solution?
in order to carry PyraOS a little further
(only for those who want it and need it)
That’s my hope. 
2 Likes
@joosep this the exact functionality I am looking for, see my previous topic.
I need pyramid to record multiple channels, onto their respective tracks.
I use pyramid with a live electronic drummer.
2 Likes
Also would love true MIDI routing for multiple channels!
Necessity for something like Pyramid
2 Likes
I’m adding my voice to the others about this. Unless I didn’t understand something fundamental (which is quite possible), the current active-track routing is the most unexpected behavior of the Pyramid. I don’t care if this is how Logic works! I have multiple keyboard synths and I expect them to be playable independently of each other regardless of the state of the Pyramid.
If the Pyramid is to be used as a live instrument, which track is active should only affect sequencer’s own operation. A separate MIDI routing config should control where tracks send live messages to or receive them from, with an “omni when active” option to preserve current behavior when desired.
The current workaround I’ve found is to reserve an unassigned “sink” track that I make active to make sure there is no interference between instruments, but that is error prone and limits the usage of the Pyramid.
I understand that limitations are part of the fun but this one is not a creative constraint, just a workflow hindrance.
2 Likes
Good news / update, for reference:
My previous (soft, I hope) rant motivated me to have a look at the Pyramid’s settings again, where I found the Midi In > Omni > Multitrack Bank X options. I had it set to Multitrack OFF default, which I think would be better named Omni ON. Setting it to Multitrack Bank D solved my problem in a much better way, at least until I start needing more than 48 tracks, at which point I’ll probably just accept the fourth banks is dedicated to that special behavior, which I admit can be of use.
All in all, a nice case of RTFM 
I still think to have more granular routing options would be nice, but I wouldn’t expect the Pyramid to become a full blown MIDI router / processor either, so I’ll leave it up to Squarp to figure out what’s best as they did such a good job for the rest of the features.
5 Likes
My skull is rocked right now. I’ve been wrestling with setting MIDI channels on tracks for the last hour, wondering what the hell is going on and finally found this thread. Really Squarp? My MMT8 could assign MIDI input channels per track and that things almost as old as I am.
2 Likes
How did it work out with your logic midi settings ?
We definitely need an update here
1 Like
Sure it would be nice with more features to control midi internally. But what’s described in this thread is more the job of a midi router, and pyramid is not marketed as such.
As already been mentioned Iconnectivity (and others) offer boxes that can do some of these things. Yes it might take a PC to set it up, and if a PC is a no no, get a product that can handle presets and you only have to do it once.
So instead of trying to get a sequencer doing a midi routers job, get the right tools for the job.
4 Likes