7000 events limit per project?

hm… actually I believe joosep hasn’t talked about a new hardware version…
I did. :blush:
personally, I agree with you on the fact that these specs are low; (and I agree with all the arguments you have listed)
but if we don’t have the opportunity to talk about software evolutions from now on, what can be said about “physical limits”?!..

I have never seen a device with this kind of issue (CPU/RAM ressources limit) being fixed with a “patch” or something like that

like I said above, if your suggestion of a workaround by use of streaming can be a solution it will be very welcomed
but if not, we cannot do very much I’m afraid… : (

1 Like

You may very well be correct that it can’t be fixed, or that it isn’t worth Squarp’s time to try (they are a business after all). But I’d like to hear some sort of statement from Squarp on the subject, since they are the only ones who would really know. Even just a “no” from them would be better than silence.

(Or maybe they’ll just release the source code and let us try to fix it :stuck_out_tongue_winking_eye:)

1 Like

I don’t believe so.
It is a too important point to be ignored… I think if they can do something about it, they will.

I think their silence means they’re working hard on the Hermod
(and not on the Pyramid I’m afraid …)
but maybe I’m wrong and we will see a PyraOS update soon … :slight_smile:

1 Like

Oh man if I spotted this topic earlier, I wouldn’t have bought a Pyramid…

But I am curious after all: did anyone experience what happens when you hit the max? And did anyone have to deal with it in one of their projects, without trying to reach the max on purpose?

No crash. You simply can’t add an event when you have reached the limit. That’s it.
I’m just trying to not have too much automation curves (that’s what principally causes the problem in my case)

1 Like

I experiment that with notes ! I copy patterns on same track, with large amont of bars, and then quickly meet the roof. Bad experience. The behaviour is simple : a “!” appeared on the screen and no more copy or additional operations where possible.
First reaction was : why propose so great bars possibilities if we reach so rapidly the max ? Deception folowed.
Now I change my way of working. I do really like the Pyramid and it’s abilities. A nice piece of gear that have its limitations, like all gear. Even if we can consider that 7000 events brings us back to early 90’s.
I joint a Cirklon to it. With the two friends, I have the Best sequencer of the world :wink:

Haven’t reached the limit.

1 Like

The ability to draw automation with the touchpad does indeed feel like more like a tease than the awesome feature it is because you always need to mind the total event limit.

It’d help a lot if there was a way to control/limit the resolution of what gets recorded from the touchpad, for example record only one step per current zoom level. For many things one value per 1/8 or 1/4 is plenty, but tedious to enter manually when there’s the tempting option of just drawing it…

1 Like

interpolations in the automation step mode could be a solution

Yes but it would also make automation less precise…

Well, sometimes you need the precision, sometimes you’d need those precious events for something else. Which is why you should be able to decide. Me, I’d take lower precision for freedom to use it for more things almost every time.

1 Like

When I was a kid I owned a little Yamaha QY70 portable sequencer. It had a 32,000 event limit and interpolation (thinning) of MIDI data that worked very well. Even so I would hit the limit sometimes. I found the UI on the Yamaha to be tedious, so I eventually sold it.

I understood when I bought the Pyramid that it wasn’t as powerful as that sequencer, but I have found interesting ways to use the Pyramid in my set-up. It’s not the DAW replacer I dream of, though.

4 Likes

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…

1 Like

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:

1 Like

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

6 Likes

@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

1 Like