Your right about all that, but would it be possible to have a feature like “track mute groups” in order to mute multiple tracks at the same time by muting either a) 1 or more “master mute track” or b) by muting any of the tracks in that mute group?
You can kind of make a seq in a seq.
I hope that makes sense.
Wish: I’d like the “save tracks info” to save assigned encoders & touchpad too
Another wish: a new FX that simply changes the output channel so that we can have several tracks that receive on the same channel (set in the tracks settings) but transmit on different channels.
That would allow for some really nice scale based improvisation using arps on each channel, with "assign note to"set to “smartpad”. Add other FX to taste (scale, chance, lfo…). One note played on a external keyboard will trigger chords on several tracks at once, processed by arps (or just droned), but they transmit to different synths (bass, pads, leads…).
It’s a bit like the NDLR from Conductive Labs (I own one, I recommend, cool device for noodling around, as the name says!) which is more specialized but we can get a similar result (the arps on the NDLR are much more sophisticated than the Pyramid FX, but there are only two, and it’s midi implementation is complete, Pyramidi doesn’t allow for much, especially for fx).
Sorry for all the posts, but I had some time to dive deeper into the Pyramid, figuring out new stuff and perfecting my workflow, so I stumble upon things…
best to send these directly to squarp via the contact form
I cannot see this happening as the output channel is a track property, so I doube the events carry the channel on them.
(we know squarp have tried to allow more events being recorded, so seems like you’d throw informatioin like this away if you were not using it internally)
perhaps there are some alternatives?
a) midi output FX
the hermod, has an FX that directly outputs to midi (where you specify device/channel)
perhaps something similar for pyramid too
albeit: I will say the reason it exists on hermod is the NORMAL output is to cv/gate …where as pyramid is obviously already outputting to midi
b) midi input filter
another way to get where you want is to invert the problem, and to say that you want multiple tracks to get the input e.g. from midi channel 1.
the issue is the only way multiple tracks can get input currently is using the omni mode= multi bank, but this has to have all data on different midi tracks.
unfortunately, this quickly gets us into an oft request feature - which is to allow each track to have a midi input filter (so each track can say, I want it from midi channel x) , and then allow data to go to any track that has a matching input.
I say, unfortunately, as this has been request so often, Id assume Squarp have not done this for some good technical reasons (perhaps concerned about processing overload if 64 tracks potential all get one event?) - so seems unlikely its going to happen now.
Yep, I can do that in multiple ways in my setup. But I thought it would be a nice addition to the toolbox.
yeah, most midi processor or even ‘smart’ midi hubs (like iConnectivity) can redirect channels.
this is certainly the workaround I think many of us do in these cases… but not ideal given omni=multibank only gives us access to 16 tracks.
I did a long time back, ask Squarp about an option for OMNI=Multibank Active
which would work like Multibank A-D, except it would target the same bank as you currently have selected. (similar to the way active track works) - this would I think make multibank alot more attractive.
alas, didnt happen…
An option in CC Step Mode (perhaps enabled in Settings) that lets you see all events, including non-selected CC messages and notes. (Please tell me if it’s already supported, I’ve read the manual…)
Ideally notes would be brighter than CC and other events, so you could “p-lock” them, and move notes along with their control events in one chunk.
I’d like to suggest a modification to the Delay FX block, as follows.
Only accessible when at 100% wet, setting Repeats to 0 places delay in front of incoming events, and scale changes from beat divisions to .1 ms divisions (up to 2 seconds), or if that’s too difficult, .1 PPQ divisions, to use as a latency compensation correction tool.
This one feature could be a true game changer. I contacted Squarp directly with suggestion, and urge others do as well, if you see this as a useful feature.
I know there is not a lot of room in the memory to add code, but this seems like it should be a fairly simple modification to what is already there. Thoughts?
I think latency compensation would be better as a separate fx… or even better as a track property
I don’t like the idea of overloading functions like this i.e. when mix= 100%, it does something different.
most users would never see this in the manual, so not know it exists, or worst activate it by accident and start reporting as a bug.
anyway, see what Squarp has to say, I think latency compensation could be a useful feature.
oh, and it should be positive only, none of this -ve delay stuff… that confuses users into think time can go backwards 
While I can see every bit of what you are saying is absolutely correct, and of course no negative delays, the trick is this: the modifcation I’m talking about is EASY, and would not require a lot more coding or trying to rewrite the whole OS to implement. Most of what it uses is already in place, and does not require a whole lot of space in what is already a jam packed OS.
Yes, to make it work as a negative, you would have to apply the delay to every other track. That’s ok. Pain in the ass, but totally manageable, if that is what has to be done to make it work. Yes, it’s a lot to keep track of, but it’s easier to deal with than no latency compensation at all, and it requires pretty much nothing that isn’t already calculated in as normal workload on the system.
Squarp loved the idea, so we’ll see if/when/how it gets written in. Good folks. 
I know why you suggested this way… I just don’t like these kind of ‘modes’, its pretty poor UI design - even if it is ‘easy’.
I recognise that likely the biggest problem with ‘doing it properly’ is to find the UI space… its just so crammed already.
also it feels like adding new FX is not an easy task for Squarp - which Im slightly surprised about, but given we haven’t see new FX, I think that speaks volumes.
… not that this would require ‘a re-write of the whole OS’
so sure, I can see why this may appeal… doesn’t mean I have to agree its a good UI model
anyway, Im pleased if Squarp want to do this… for sure latency compensation in any form would be useful.
I wasn’t even trying to suggest it’s a good UI model, but it is one that is functional within the very narrow parameters that we seem to have, currently. And the inability to add new FX or at least difficulty is why I suggested a fairly small modification to an already existing one. Regardless of its intended use, it still falls quite comfortably under the definition of “delay”.
Sure, it would be great if there was something in line that could basically delay all other channels instead of the one being adjusted, more user-friendly, but that’s a larger endeavor, almost certainly too large, and while my suggested method may be rather clunky and a lot to keep track of, it can at least get the job done, despite its inelegance, unlike the nothing we have to accomplish this task currently. If they can get into .1ms increments, it can even be used for phase adjustments, which would be a godsend.
Edit: Of course, this part of the FX would have to be excluded from a consolidation. I guess it’s just something that would have to be turned off prior to consolidation and reactivated afterward, as it is a fixed time domain adjustment and not a subdivision of the tempo. So it could turn i to a royal pain in the ass if someone is not very careful in its use…but with great power comes great responsibility, I suppose.
unfortunately, that’s the kind of problem these kinds of ‘quick fixes’ tend to cause… a bunch of exceptions and corner cases that invariably lead to other ‘bugs’ and confusions.
but yeah, it is what it is… as I said, I understand the ‘practicality’ of it… and I cannot say Ive never implemented such hacks for those very reasons
lets see what Squarp comes up with… Im sure they will think it all through carefully before committing to code!
Yes, perfect example. I agree with thetechnobear and strongly advise against setting parameters to “magic values” to change a feature into a different feature.
i agree it has to be a track property
but i need negative compensation, only having positive compensation makes it much more complicated to use
Yes, it means you have to add positives to everything else to generate a negative value. That’s how things work in the real world. Yes, it’s a pain in the ass, but it’s highly doubtful that the OS has enough room left to code something that would introduce a delay to every other track but the one you are trying to adjust. That seems like a nightmarish undertaking the nobody at Squarp has the time for and would simply end up getting shelved as another interesting idea. On the other hand, this modification seems like something feasible. Maybe make it an OS update available by special request. If you don’t think you can handle it, don’t ask for it.
We’re not talking about 'magic values", we’re talking about extremely useful values to utilize the same effect in a different capacity. Think about it like this: EVERYTHING in the Pyramid runs off of a central clock. The BPM are set by the relative number of clock ticks to 1/96 PPQ, the fewer clock ticks, the less time between 1/96 PPQ, giving you a higher BPM. Chances are, it uses a simple algorithm to generate the clock tick counts per BPM then subdivides that number for beat division. This mod would essentially bypass that calculation and instead a simple multiplier that counts clock ticks per 0.1ms or 1ms, if needs be. There’s nothing magic about it, it should be fairly easy to code, not require a lot of time, and add immense functionality to the device. And if people are so afraid of its implementation, make the update a beta, “for power users only, try at your own risk”.
I guess the question is this: Is it something you would use if implemented as described?
The question is not: How will other users handle this?
that’s your question/framing 
as I said, my issue was I don’t like this kind of UI, because it potentially damages the usability of the UI - for me often ‘less is more’ when it comes to usability.
would I use it? unlikely.
but thats pretty irrelevant, its up to Squarp to decide if they believe its useful to their user base (which extends well beyond active posters on this forum) , and if its practical to implement or not, and in what way.
I think that PyraOS already does something like this for the quantizer/humanizer effect. This effect can also add negative delay to events, so it must have some kind of ‘lookahead’.