Proposal: Real MIDI routing


#35

Indeed, especially for multitimbral instruments.

On the other hand, definitions can speed up things that otherwise require some more actions to do…

If you just have to call an instrument channel, where everything is set already (MIDI I/0, CC’s,…), you don’t have to manually program each of these settings apart.

In a live situation that might be handy also…


#36

Theoretically, the Pyramid can listen to 32 midi channels, not just 16, because USB in and DIN in are different ports, and could be addressed separately.

Pair that up with a midi router like the Motu or iConnect series and you could route almost as many inputs as you have outputs


#37

up, I keep on saying how important this is.

The actual limited MIDI IN functionality caused me a lot of frustration on a jam with multiple keys last night.

I always find myself recording into the wrong tracks, or while playing along the Pyramid with a keyboard, causing another synth or piece of gear to receive the data this keyboard sends to the pyramid on the selected ‘active track’…

maybe I should reserve an empty track assigned to an unused MIDI output, and trying to select that track via a PYRAMIDI CC command from another MIDI controller, each time after I’ve recorded or changed something on the selected / active track…

Other suggestions on how to work around this, and get as few as possible mistakes while recording / playing live with keyboards, would be great thanks! Especially with just one UNDO, it’s just too frustrating sometimes…

Thanks!


#38

yeah, same here. Per-track routing would be a god send.

for example, I was trying to figure out how to use a master midi controller set to one channel so that I can quickly switch between instruments, whilst having another midi controller that only sends to the transpose track. Still having trouble setting this up properly. The midi controllers I’m using can’t change midi channel on the fly, so I’m using fixed channel mode :frowning:


#39

The iConnectMidi routing solve me a lot of problem, but I have trouble setting usb midi for play virtual synths in Logic when I drive external gear as well because Logic can’t set a midi input per track…


#40

I use iConnect Midi also, but that doesn’t solve these issues… At the end every MIDI signal that is being sent to the pyramid is recorded at the ‘active track’. Like I described before on other topics, I ended up recording stuff on the wrong tracks quite often in Live mode… Again, MIDI-input routing and recording workflow for live use could get some more attention by Squarp.


#41

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.)


#42

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.


#43

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…


#44

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.


#45

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


#46

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…)


#47

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 :wink:


#48

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.


#49

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.


#50

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. :slight_smile:


#51

@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.


#52

Also would love true MIDI routing for multiple channels!
Necessity for something like Pyramid


#53

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.


#54

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 :expressionless:

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.