7000 events limit per project?


#62

Only the Roli I use is MPE, and isn’t even the problem: I don’t use it in MPE mode on stage because I don’t own any MPE enabled hardware synths (Equator is a really cool softsynth but I don’t use it live). Editing on stage isn’t a requirement either. The main controllers that spit out serious amounts of data are the Touché and the HotHands.

I’m also reconsidering my ideas. That’s part of the creative process. If I really can’t live-record that much data, I might decide to decide against that idea, like you did, devise another technique and live with the limitations. So I don’t rule out the Pyramid altogether! Will give it a good night’s sleep!


#63

Forgive me if I’m a little of topic, but if I use the pyramid arpegiator to transform a 4notes bassline (over 8 mesure) into a more groovy/disco version of it ; I’m I still at 4events (if I don’t consolidate) ?


#64

yeah, the event limit we are talking about, are for events that need to be stored.
so thats things like the midi notes/cc on a track and any automation ‘data’ (e.g. if your automating an fx parameter that needs to be stored too)

anything that is calculated (e.g. and LFO/arp) does not use extra events (for storage) , it creates ‘events’ on the fly.
(as you correctly mention, consolidating turns these calculated events into stored events and so means that now are subject to the event limit)

note: of course, there are other limitations, like cpu (hence one reason we have limited # of fx slots) and the amount of data that can be sent over USB/midi din.

I think the event limit is mainly problematic when used with things creating a large number of continuous events or very large projects( with lots of notes, and large numbers of tracks (*) )


(*) i seem to remember some users doing this, as they want to have their entire live set as one project, so they could smoothly transition from one piece to the next as projects could not be loaded without disturbing the flow. (we have seen related feature requests for being able to ‘load projects on the fly’, ‘sequence projects without stopping’ etc )

its a very reasonable thing to want to do. but unfortunately, i think the pyramid was not really designed to do this - and is not really possible to retro fit.


#65

Was that functionality desoigned to save CPU cycles? Is there a limitation there as well? Obviously yes, but like, hmmm, one we could expect to hit?


#66

@thetechnobear

Thank you for your answer that’s pretty clear !

I bought the pyramid to play entire live sets too, and import older liveset via midi files but I knew about the loading issue before buying ;
So to overcome the “loading issue” I just put the pyramid in slave and stop it (my main drum machine is not sequenced by the pyramid in that regard so she plays alone while I load) ;

Every hardware have their limlits, sometimes you can mod the machine, but most of the time you just have to accept it, and love it for what it is, for both his strenghts, and weakness :hearts: :slight_smile:


#67

Consolidation— a few uses , like you might freeze a track on a daw

main uses (for me at least)

  • solidify a random idea
    So create a track with random elements then freeze it into a fixed idea , to be edited and refined.

  • free up fx slots
    say you want arps, but find it’s easier to enter/play chords , then use an arp fx - but after it’s ‘done’ you can freeze it. the advantage of an fx, is you can change their parameters but once you found what you like - you might consider it done.

  • Euclid track
    Variation of first point, but was often requested
    The Euclid track type has limitations, like you cannot change notes per step - but if you consolidate you can now change it to your hearts content.

Then of course there are combinations of the above.

This is an area I find the pyramid to be a really interesting creative tool.

But yeah consolidation is a trade off , since it usually means more events ( unless you using chance to remove events;))

Is there an fx overhead?
I’d assume so, but I suspect it’s one reason we are limited to 5 fx (incl quantization) per track, but generally I think the fx don’t cause much cpu overhead, they are pretty simple.

I’ve personally never seen evidence of fx causing timing issue ( which would be the consequence).


#68

Ok, so I gave it a second thought and ordered mine today!


#69

I was initially concerned about the limit, but in the couple of years I’ve been using it, have only hit the wall twice.


#70

@palm
Can I ask you put entire live set into one project ? And if so, how long was your live set and what kind of music do you make ?
Thanks a lot for your feedback :slight_smile:


#71

I have done a few sets within one project (1/2 hr to 1 hr), but I’m making improvised microtonal computer music. I compose live from midi controllers, and nothing is sequenced before I start. I set up empty tracks and then begin building from scratch in real time, often deleting tracks or simply creating a new empty pattern.

I realize that my use is pretty different than what most people are going for with the pyramid, but it’s a pretty open ended instrument (that’s what drew me to it).

I’ve only ever used the Sequence Mode in the studio. For live use, I only use tracks and patterns and build as I go. The Sequence section is too tedious to program in real-time, so I don’t bother with it.


#72

thank you for your feedback :slight_smile:


#73

A silent(?) OS update today, now the limit is 10000.

http://squarp.net/pyraos

pyraOS V3.22
august 27, 2019

Bug fixes

● Improved RAM memory space, now the maximum number of events is 10000


#74

good to see they’re working on it over multiple releases trying to do what they can to address concerns as best they can


#75

Well, now that’s great news! I’m still waiting for mine to arrive… that’s nearly a 50% increase (from 7000 to 10.000). That’s a major difference!


#76

This is great to hear! Personally, I would have been fine with 8k - 9k events if we could increase the number of sequences allowed from 32 to 64. That would actually mean that I’d use a lot fewer events because I could rely on the looping of chained sequences more than I can now. With only 32, i often end up having to make my sequences very long with no repeats so I can capture the progressions of various tracks coming in and out without going over the seq limit.

But if this forum is representative of the total population of Pyramid users, I get the feeling that the event limit is/was the issue that more people balked at. Personally it took me over 6 months before I ran up against the wall that the 32 sequence limit poses. Thats because it took me that long to be comfortable enough to attempt to program a full, complex song from start to finish rather than the general ideas and motifs that I would just jam and improvise with in track mode.

But I digress - this is definitely good news! Thanks Squarp!


#77

So I finally got mine, I cancelled my order for a new one because after 3/4 weeks my local dealer was still unable to get some reply form Squarp in Paris, and it happened that someone nearby had a MkI for sale so I got that one for 520€ after reading on the forum that it’s the exact same electronics in a newly designed case. (Hardware version says 133).

I messed around a bit with it tonight, quite easy to grasp and of course tested the memory limit. I recorded a single track of 16 bars at 110 BPM using the chord pads (hummm, I’d rather call these “switches”, they do not really qualify as “pads” IMHO), 1 chord/bar maximum, the rest being modulation generated from a Touché controller using 4 modulators (4 CC’s). This alone filled up half of the Pyramids memory.

So well yeah, I’m glad the memory space was upped to 10.000 events because when we use it that way (it’s what I bought it for in the first place!) we run into trouble as soon as we use more than 32 bars of that type of input. So I will need to calculate quite a bit to separate what I will need to record on the Pyramid, what I can play live and what I can sample in the Octatrack (for on-the-fly sampling of bits of the actual live performance) or the SP16 (sampling beforehand).

I am glad to have one, it looks like a cool device that can generate some interesting things due to it’s high resolution (compared to the Elektron step sequencers) but that memory issue is really deceptive and even for the price I paid it remains a hefty investment. Time will tell!


#78

Oh yeah, recording high resolution multi-CC modulation sweeps from something like a Touche is going to gobble up your events really quickly. But just deleting a couple of those CCs from the track you recorded will free them up quickly. If you want to pre-record modulation for playback later, it may be best to record it into Ableton or something first, so you can thin out the CC steps a bit.

Actually, that would be a cool MIDI FX Consolidate feature - delete every even event for a given CC lane to effectively cut the total in half. Of course, it would make the modulation more coarse and potentially audibly stepped, but it would help reclaim space dramatically in situations like yours.


#79

A nice optimization would be if the automation data could be stored as approximated lines and curves. A linear sweep of a parameter could be stored in much fewer bytes than a stream of discrete values.


#80

That’s an interesting idea: vectorized autmation :sunglasses:


#81

The LFO effect can be used to achieve that. To a degree at least - it has its own limitations of course.