7000 events limit per project?


same here
but without this “events limit” and with a few adjustments (maybe for 3.0) it could be this one…
it’s a pity
so frustrating…


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

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”! :smiley:
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) :wink:


actually midi cant do anything ‘simultaneously’ - its a serial protocol :wink:
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 :wink:
  • 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 :wink:


@thetechnobear thanks for this detailed (and more accurate! ) post :wink:
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