but without this “events limit” and with a few adjustments (maybe for 3.0) it could be this one…
it’s a pity
I have to say this killed it for me… I use pitch bends and a fair amount of CC messages in my tracks so I’m not going to pay €700 for a sequencer with this limitation…
The Cirklon has a limitation of only 4 MIDI CCs per track which also kind of kills it for the amount of money they’re asking.
Why can’t anyone make a hardware sequencer without so many limitations? It’s just MIDI, it’s not like some crazy amount of data we’re talking about…
limitations of the protocol ? may not be a massive amount of data… but still limited by capabilities of the 5-pin midi connection ? I don’t know this I’m supposing
The limitations of the 5-pin DIN are not why there is a 7000 event limit, the MIDI bandwidth is extremely capable of transferring the required data in good time.
yes, the MIDI protocol is only limited in terms of simultaneous events (not really “limited” btw : up to 128 simultaneous notes per channel !)
but not in terms of events number
this is a RAM limitation
the Hermod which has a more powerful engine has a 80,000 events limit per project
most of the old MIDI sequencers have a memory of at least 100,000 events (e.g. Roland MC909 1,300,000 notes!!)
not bad for old machines…
in short, it is not the MIDI standard would prevent to have all the 64 tracks, with dozens of CC# automations on each of them, filling all the patterns and sequences (or even more sequences)
or to do “Black MIDI”!
But that’s not possible with the current hardware version so I know some of you don’t want to hear that we would have to wait for another HW version for that, but I don’t see how it could be done differently…
We just have to deal with that!
and let’s them give us some new cool features that can make our projects even more awesome (in less than 7000events)
actually midi cant do anything ‘simultaneously’ - its a serial protocol
so in terms of events, its limited by throughput speed, though in practice this is only an issue for DIN, USB is fast enough (even if jitter is an issue)… the hermod is using CV, so that’s only limited by the DAC used.
but yeah, the 7000 event limit is a memory issue.
there are a number of solutions to this:
- new hardware = more memory
- improved internal representation, i.e. make the events take up less memory. this also includes things like quantisation and interpolation
- streaming , i.e. keeping less in memory
hardware is easy, and the realistic way to get lots more events, so more likely to happen
internal representation, we do not know the software code , so its impossible to know what improvements can be made here - bound to be some ‘quick wins’ (like quantisation/interpolation) and some that are really hard, which are possibly not worth the (time) investment… and some in between.
Note: often reduced memory footprint, leads to high cpu consumption, i.e. it becomes a trade off, so this might also limit squarp
streaming, so taking events from sd card , ok theoretically this can happen… on Axoloti, a similar processor it can stream audio, which is much more data than midi
this takes cpu cycles, and the code to do this looks very different to code, that that assumes everything is in memory i.e. its quite likely the effort to do this would be prohibitive.
a more practical approach would be to ‘chunk’ the data, i.e. so it is loaded in sections… depending on how you split it up, this becomes less or more dynamic. the natural spit would appear to be project, because its self contained.
so the question is, is this practical? without seeing the code, difficult to say … butfor sure its would not be trivial…
the idea is two projects could be simultaneously held in memory i.e. a second project could be loaded in the background, whilst the first is playing, then at a point in time, you ‘flip’ the active project, and the other inactive project can be swapped out for a new project.
this ‘approach’ is actually not that uncommon e.g. we do it with graphic rendering all the time.
there are some limitations:
- projects can only be half the size (more likely 3000 events) , (if they are to be ‘flipped’)
- projects flipping can only happen at a certain rate (time to load + initialisation etc)
is it simple? no, there are all sorts of assumptions in code, and this would break many of them…so depending on how the code is written, this could be a few weeks work, to being virtually impossible.
(unfortunately, this is one of those things, if you have it in mind when you write the code is not that hard… but its hard to retrofit)
summary… id say its perhaps possible we might get some of the easier optimisations (of internal representation) , which will help in certain use-cases - but apart from that, its likely to come from a hardware revision.
personally, i don’t mind, as I knew the limitation before I bought the pyramid.
the only area this effects me, is pitchbend and pressure recording - if they quantised, and interpolated that, then id be 100% happy
@thetechnobear thanks for this detailed (and more accurate! ) post
I simplified my point … but we agree
I also think they will try to implement interpolations for automation curves
and that should help to use less events …
hoping that it does not impact the CPU too much, indeed
(personally, I have often reached the RAM limit, but on the other hand, I don’t remember having reached the CPU limit on the Pyramid yet…)
heh I think it’s fair to say I stand corrected
Sorry to necropost but for anyone coming across this thread a year later, the specs now read:
● Maximum number of midi events (notes, CC, …) per project: >8000
It’s not mentioned in any of the pyraOS updates so I’m not sure at what point it changed or what the actual new hardlimit is.
OS 3.0 increased the maximum number of events. The current specifications on the website are correct.
● Memory optimization:
You can add up to 9000 CC MESSAGES per project, instead of 7000.
You can add up to 8000 NOTES per project, instead of 7000.
I take this to mean that if you only have notes in a project, the hard limit is 8000 but if you only had CC messages in a project, you could store 9000 of them (because a CC message has less associated data compared to a note).
So the exact upper limit depends on the notes/CC ratio in a project, but it’s somewhere in 8000-9000 range.
I was just about to place my order when I came across this thread. What’s up exactly? On the main website, the sales pitch says:
Pyramid mk2 sequencer
The ultimate brain for your setup, from studio to stage. 100% standalone, packed with tons of creative tools.
64 polyphonic tracks, unlimited number of notes & automation
up to 2048 patterns per project
12 dynamic midi effects
chords and scales generator
real-time recording and step sequencing
full connectivity: midi, usb, cv/gate, dinsync
and that’s exactly what I am about to order it for. I have already 4 step sequencers, but I want to record midi clips using my Touché , SourceAudio HotHands, Roli keyboars. These all spit out a huge amount of CC data and 7000 looks like I will not go as far as I intended…
So what is the final word? 9000 total events like discussed here, or unlimited events as adveritise on the website’s frontpage??
Events are limited by memory.
However, there are generative functions that do not record events.
Its sort of splitting hairs perhaps, or maybe failure on Squarps part regarding updating their marketing material, but the fact remains: 7k-9k limit on events depending on other factors (type of events, etc)
If you are generating CCs on the Pyramid, the number of events is limited by your lifespan or impending power outages.
If it is imperative that you need unlimited events, this may not work for you.
I think the “unlimited notes and automation” in that context refers to polyphony, for which the Pyramid has no hard limit, in contrast to eg Hermod which is limited to 8 notes of polyphony, Octatrack only supports 4 (or something like that) note polyphony etc. It is really poorly worded though, especially for a device which has such a severe limitation for number of events.
Well, yes that might well be the case. But then indeed the sales pitch is erronous. I just read through the whole manual again and there’s absolutely no reference to a data limit. My whole point was to be able to record live midi using the expressive capability of my controllers. For step recording I have already a bunch of Elektron devices, and a SP16, but I hoped that I could do all the midi using only one device.
A Touché or a HotHand can generate several 100’s of events per second. I just checked a simple movement of the Touché in Reaper, I recorded over 200 events per beat at 120BPM , that’s 400/second and with only 4 of its 8 CC slots assigned. Well over the Pyramid’s 96ppqn resolution, but I could live with it. (Reaper’s default resolution is 960ppqn, 10 times as much as the Pyramid.)
But at that rate (96ppqn and with that sort of midi sources, the Pyramid will choke, and the memory limit will be hit after approx. 70 seconds.
Now I need to give it all a second thought… so it’s not “unlimited events” as advertised
If you feel strongly about the errors in the sales pitch, perhaps you should take that up with a lawyer.
I can relate kinda: i had data i wanted to import and purchased the Pyramid to specifically play MIDI data id already created. At that time, the Type 1 .mid import didnt work.
However, I’m glad you were able to discover the Pyramid will not work for you before you invested in one!
Good luck and hope you find a device that works for your application.
Hah! I’m not at all that kind of guy, and I discovered this before buying so there’s no case anyway…
I just need a second thought. This is not an inexpensive device. At 350-400€ I would say “oh well…” (even if that’s still a lot of money for me) but at 750€ I need to evaluate how far this will get me until I hit a wall. It was meant to be a problem-solving investment after all!
The limits are described in the specsheet at the bottom of https://squarp.net/pyramid, including:
● Maximum number of midi events (notes, CC, …) per project: >8000
It also confirms my thoughts about the intended meaning of “unlimited” in that context:
● Maximum number of notes per step (polyphony): unlimited
● Maximum number of CC automation per step: unlimited
● Maximum number of FX automation per step: unlimited
So while the specs are there, the front page advertisement of “unlimited notes” is misleading at best. Pyramid and “huge amount of data” don’t really go together, it’s no DAW replacement in that sense.
Well yeah. As often in France (I live here) there’s some wordplay going on. It’s correct that a cap of 8000 notes per step can be considered as “unlimited polyphony”, and given that there are only 128 CC numbers available in the Midi 1.0 specification, that’s true for CC’s as well, and that there’s nothing wrong with repeating the word “unlimited” as many times as possible. All that is true.
I think I might simply get a used MPC500 for a 100€ (100.000 events) for the time being and wait a bit to evaluate my real needs. I was already in love with the Pyramid but that 8000 events cap is really low for what I intended to do in the first place.
in fairness, its very clear on the spec sheet what the limits are, and thats where I always look for limitations when I buying things.
I agree with @pmatilai, this is kind of a ‘summary’ , it’d be pretty hard to succinctly add into that sentence, that their are limits like, midi only having 128 notes on one channel, and that you might have already exceeded the number of events etc- its an overview.
pretty similar to a DAW does not say it has limited polyphony (on a track) because you might exceed the RAM or processing power of your computer - that kind of thing belongs in specifications and requirements documentation - everything has limits … nothing is ‘unlimited’
I also originally thought about using the Pyramid for recording MPE data, but decided against it… partly due to resolution, and also concerns about memory.
but mainly because I realised it was not the strength of the pyramid.
even if you could record the data … you’d never be able to edit such dense data on the pyramid, and it’d be split over multiple tracks - which is dreadful to edit (Ive tried in older daws!)
in which case, if you’re not editing, you might as well just use a headless midi recorder. (e.g. a rPI).
thats not to say I dont like the looper functionality of the pyramid, I do … but just not sure its that applicable to MPE.
so yeah, if MPE or similar is your primary use, I agree the pyramid is not the machine for you.
(frankly, I doubt the MPC is either )
(*) admittedly for my expressive controllers, I generally don’t record mpe even in DAWs… I tend to just record everything as audio … the tools in some daws, cubase/bitwig are ok… but they are still a bit cumbersome for anything other than short mpe recordings - but I know some like to