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