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).