Has anyone run into a problem because of the 7000 midi events per project limit?
I wonder about this, because CC automation could use up a lot of that in a relatively short time. (Perhaps this limit is why Pyramid doesn’t allow resampling of midi fx? Or recording of poly aftertouch?)
Or perhaps 7000 events is a typo on the specs sheet, and it’s really 70000? The Hermod, which has only 8 tracks, allows 40000 events per project. So it seems strange that the Pyramid with 8 times the tracks would have 1/5 the event capacity, even if it is an older product.
Can anyone confirm what the Pyramid event limit really is?
CPU speed and complexity shouldn’t limit storage size. I’d hazard a guess that the Hermod has a higher event count per project due to it’s lower track count.
CPU speed will surely play roll in the fact that Hermod has 8 FX tracks and Squarp has 4.
I am quite sure Hermod also has a more powerful RAM chip, but I dont have that exact data, so I did not include that in my last post. I believe the 7000 event limit is due to memory.
When you have a project going in the Pyramid you can view the free memory.
To check this I recorded one bar of music with 1/4 note chords, a mod wheel sweep, and a bit of pitch bend into my old sequencer, and then went into list edit and counted the number of events. It was over 150.
7000 / 150 = 47 bars before memory would run out. That’s 47 bars divided between all the tracks in the project!
Granted, the mod wheel sweep was like 75% of that. But take that out (no mod sweeps, ever) and you’re still only up to 200 or so bars of music, or 400 seconds / 60 = 6.7 minutes at 120 BPM, divided between up to 64 tracks.
Memory is cheap (we’re talking about kilobytes here - a midi note event is 3 bytes long), so I cannot understand why Squarp did this.
(And, every MIDI sequencer going back to the MMT-8, which is 30 years old now, had more memory than this).
Squarp Pyramid is a great machine but memory in board is a big problem ! Try to load midi files with many tracks with a lot of midi events ! I don’t know why SQUARP designer didn’t put more memory. the machine still costs more than 700 euros. I like the concept of live machine, but also to work midifiles and on this point there is a problem
It would be cool that they find a solution to recover the ram of the SD card as they have already optimized the firmware for it.
It would be cool that they find a solution to recover the ram of the SD card as they have already optimized the firmware for it.
That’s an excellent idea. Midi is very low bandwidth (like a text file) so I wouldn’t tend to think that streaming files from the card would be an issue. (Disclaimer - I’m not an ARM Cortex developer).
Another help would be seamless loading of projects, so they could be switched mid-set without a break.
Indeed, ain’t there any way to change songs mid-set and stay synced to the master midi clock that’s coming into the squarp?
The way I try to have it work now: recording max 4 quite short loop-tracks and 1 or 2 CC tracks for each synth (3 of them) on each song of our set. I do this on bank A only, so I have access to those loops all the time and mute / unmute them on the fly while we’re playing.
Due to bank / track / memory limitation I need to make a new project for each song, while my buddy has already started the next song (sending mtc already).
It would be nice if changing songs could go easier and keep the songs synced
It would be cool that they find a solution to recover the ram of the SD card as they have already optimized the firmware for it.
how they could possibly do that?
I agree with you guys
but my guess is that we have to wait for another hardware version for that… unfortunately…
we can call it unofficially “mk3”
(please Squarp, don’t call it “Pyramid II” )
and in addition of a more powerful board, it may also be an opportunity to have a slightly larger screen (High Resolution Color OLED? like the ones on Teenage OP-1, Push, Machine etc.) and RGB leds
so it will be a perfect upgraded version imo
and PyraOS could go further! I would pay for this !!
in the meantime, they could implement the possibility to chain projects, yes,
it would help
Everything that “should have been there” actually was there. They have never lied about what the Pyramid could do. Any further development is extra bonus for us. Mmmmmmmmm…
By streaming to/from the card. Like I said, the bandwidth is very low.
The concept is the same as disk cacheing. Effectively that’s using the card as RAM.
you have an example of this on an hardware unit?
I don’t think that ROM can replace RAM as easily
plus, midi datas are very light, ok, but streaming multitrack I/O on a SD card (pretty slow device)… I don’t know…
the Squarp Team seems pretty good to find names : )
and I’d prefer a new name so “Pyramid” units can live without having the impression they have been replaced…
I hate numbers on devices !
it reminds me the software world… :-/ with the marketing principle to number each version which makes the previous one obsolete…
I believe they avoided this with the mk2 where the mention “mk2” appears nowhere on the unit…? (if someone can confirm this, because I have a mk1)
which is a very good thing !
so I hope they will continue like this
(…or that they will find another name, indeed )
I’m claiming that a hardware sequencer in 2017 should have at least as much memory as an ASQ10 or RM1X, both of which are over 20 years old.
Or is it OK to need workarounds to run a decently long live set?
Honestly I feel ambushed by this. It did not occur to me to check this before buying, for the same reason that I would not ask at the dealer if a passenger car can hold more than a gallon of gas in the tank. EVERY mainstream hardware midi sequencer going back to the mid 1980s that I’m aware of had more, and for good reason. The pyramid can do tracks up to 384 bars long, but doesn’t have the memory to effectively use the space!
I’m not 100% sure if it’s possible to do. But if the Octatrack can stream 8 tracks of stereo audio (from a different device), shouldn’t midi be possible?
If it can’t work both ways, it might still be possible to load a project in the background and switch seamlessly. But again, not being a dev for this I can’t say for sure.
But it’s a problem. They could at least look into it and see if it’s feasible.
I do, it is very doable. I own two Zoom multitrackers, the R16 and R24. Both of them use SD media to record directly to and playback from. And that is the original SD standard, not any of the successors such as SDHC.
yeah but what about the MIDI FXs? any parameter can change at any time, this is real time, and it is a big part of a Pyramid project
(maybe with a “consolidate” feature…?..)
I think there is a reason why a project is loaded into the RAM… all their code must be thought this way… but I guess only the Squarp Team can answer this question : )
)
)