yea that’s kinda my take too. Honestly I’ve never had an issue getting squarp to fix bugs. Maybe that’s changed since hapax (i mean i haven’t found any bugs i want to fix in a while so what do i know).
And yea - pyramid is a different workflow, which i prefer too. Also, the foot print of the pyramid works better for my setup lol. I do hope that improvements to the workflow will come for those asking for them - I think Pyramid definitely has a market even if hapax is the cool new kid on the block. I’d really encourage folks to write them a letter and be as thorough as possible (and kind, they’re really nice folks).
I sorta want a mk4 some day personally with more better processing/memory and a few things myself. I know, my dream is probably the most ridiculous but I’ll keep dreaming. Maybe some day there will be a like online community of custom pyramids like cars or something. lol, ‘customized sequencer conventions’ - its gonna be a thing haha.
I think the pyramid still has its niche (compared to the Hapax), smaller/compact, and also they way it handles polyrythms/polymeters is still unique.
as an open source developer (Im active on few music related projects, as well as my own), Im obviously an advocate for open source.
however, we do have to remember it is not a ‘right’ - rather a choice by the developer… they wrote the code, they own it, and many feel its a risk of to their IP.
in the case of the Squarp Pyramid , we have to remember, whilst the code base for the newest product (Hapax ) has no doubt moved on/progressed, for sure some heritage remains… so yeah, its unlikely something that they’d want to share (reasonably)
also lets remember, open sourcing is no panacea… there are few developers with the skills to take on such a complex product/code base (without introducing bugs ;)) … and from experience, they already have many other projects to work on
Yeah, agreeing with @thetechnobear, you have to think about how many ‘unsupported’ products (both hardware and software) ever do go open source. I am also a big fan of it (although it is not without its limitations - see the ridiculous log4j vulnerability recently [obviously more on the software side], but also how development completely stops on certain products with great potential that just remain buggy and unfinished [looking at you, Seq24, and looking at you Open Electribe Editor - not to disparage either product, they both are amazing, just unfinished])
But also it’s up to the developers of the original product to do it. Code is intellectual property, and to give that up is a huge deal. Very few ‘closed source’ products move to open source, and for good reason. Even if none of that code is used in further products or projects, it’s still intellectual property, and that means something.
There is an argument (and probably a valid one, from my point of view) that intellectual property, such as code, should be limited, like it is for intellectual property for characters and stories, and musical copyright, etc, etc. So that 50/70 years after its created, it becomes public domain. However, not a lot of code is 50 or even 70 years old yet, so that’s more of a pie in the sky argument, I guess.
From my mind, the closest analogy to what people actually are thinking about for the Pyramid is the (in)famous JJOS for the MPC. But remember that not only is that not actually open source (think the technical phrase is “Free as in beer, not as in speech”) and it was also completely written from the ground up by the developer, without input or help from Akai.
So someone needs to reverse engineer the Pyramid, work out how it ticks, then programme something from scratch.
I couldn’t tell you how Squarp would feel about that, but it would be more likely than them doing full open source from their code.
I basically agree with the principles of “right to repair” and I think they apply here. I own a device, it is broken in some way, and I want to repair it. The manufacturer should be obligated to facilitate that to some extent. (In my ideal world, that is; I’m not making any legal claims.)
Reverse engineering could be an option but that feels rather too much like working “against” the developers, when in principle, our incentives should be aligned (i.e. we both want a properly functioning device!). Besides that it would obviously be a hell of a task to try and fix some subtle bugs by poking around in disassembled firmware code…
afaik, right to repair, only covers hardware… and even then is quite specific (in legal requirements)
I simply don’t think its the same at all… being not able to replace a phones screen due to a company requiring special tools. is not the same as demanding a copy of the source code to fix (what they think) is a bug.
(I don’t think hardware manufactures are required to provide schematics… which would be kind of similar)
hardware breaks because it ‘wears’ out, or can be physically broken (dropped etc) , software cannot break this way.
I can only (off-hand) think one area where software (commonly) ’ breaks’ , thats due to outside influence e.g. OS dependancies.
say, a piece of (outdated) hardware has OS integration, and a new OS breaks it (Windows 15)
under this scenario, one could question that it has now been ‘broken’. that said… probably the hardware said it works with (e.g) Window 10… so its presumable still working with that… so its still within specification.
of course, software is subject to ‘reasonable use’ , so a bug that rendered something unusable, can be returned.
anyway, I highly doubt this would become law…
basically, it’d open the door, for demanding all software to be open sourced, and that would have many unintended consequences…even as an advocate, Im not sure Id want this.
I will say rather we should work with companies, and also try to get to a position where :
a) they see the benefits of open source
b) consider open sourcing, when the IP is not a significant risk
(b) covers lots of scenarios, e.g. a product being discontinued and no successor is using its firmware… or newer products have more sufficiently far along that its not a risk for them.
but again, this should be the developers choice , I respect this is the ‘creators’ decision, and respect there are many reasons why companies choose not to do it (as well as why some do)
but we should probably get back on topic, since as far as I know, there are no plans for open sourcing the firmware…nor any legal requirement for it to happen.
The issue is that Pyramid has been put in the back burner since Hapax. I understand that Hapax is now a revenue driver for Squarp. Still, there are lots of people who for months/years loyally advocated and defended in many forums Pyramid against competition (Korg, Oxi, even Cirklon, etc.). So to see the Pyramid status at Squarp more or less of a moribund to make way for a new flasgship product, is a letdown, and the kind of behavior expected from large capitalistic outfits, not a smallish boutique one.
As important, I’d be just as disappointed if a “Pyramid 4” were to be released, meaning again that all the existing Pyramids would be relegated to obsolescence, the closet or even the trash bin. Which is morally and environmentally dubious.
Please Squarp, clean the existing PyraOS, and maybe with all the smarts working in your company find a way to add/improve some features with the existing hardware. Free to you after that to openly declare the peaceful and dignified retirement of Pyramid.
Genuinely don’t understand how something that still works as a MIDI sequencer is somehow obsolete now there is a newer MIDI sequencer out there.
My phone is from 2016. But it still does phone calls, google maps, whatsapp, texts, and I can read the news on it. But there are loads of newer, better, faster phones out there. But my phone still works as it was intended. Not obsolete (although will probably be soon once apps stop working on it, but that won’t happen with Pyramid)
This is only true if your reason for owning a Pyramid is to have the newest thing. If your reason for owning a Pyramid is to make music with it, you can still do that just as you’ve always done no matter what gets released in the mean time.
We can move on with the confidence that this point has been made and adequately discussed. Some of us expect the Pyramid to get more new feature development, while some of us consider the product essentially done.
I still don’t see a clear case presented here of a bug in a documented feature that hasn’t been addressed. A bug, if it exists, is more likely to be fixed if the reporter provides: 1. Concise steps to reproduce it; 2. A description of the expected behavior per the documentation; 3. A description of the actual behavior (bug). If the expected behavior is not a documented feature, then the bar would be quite high to show that the actual behavior is broken vs. a preference.
I’d like to see bugs reported in this forum as one thread per bug so that each can be discussed and made more visible to Squarp. As it stands, I think this thread has exhausted its usefulness.
That is exactly what I did, and in response to those bug reports came the message that Pyramid is on the back burner right now (besides a confirmation of having reproduced the issue and added it to the ticket list ). In my opinion it is important to separate clearly the two different issues of “developing new features”, and “fixing bugs”, especially since some now seem to use arguments against requesting new features as arguments against requesting that outstanding bugs be fixed, or at least conflate these issues to such an extent that the distinction gets lost.
I will paste my two bug reports below for the benefit of anyone who is curious, both are applicable to firmware 4.02. I’m putting them here to illustrate that kindly requesting a fix of something that is clearly an error, is totally different from feeling entitled to shiny new features for years after a product came out.
Incorrect note offsets after save/load
To reproduce:
Create a new project
Set the track properties as follows: time signature: 9/8, zoom: x1, length: 12 bars
In step mode, go to the last page and put a note on every step there with the pads
Save the project
Load the project
Observe: the notes that were placed previously now have a variety of random timing offsets, such as 9% or 13%.
and
Incorrect velocity after note release with eq effect
I encountered the following bug when using the “equalizer” midi effect together with “env out assign” set to “velocity”. Directly after releasing a note, the env cv output reverts to the value it would have without the eq midi effect. This makes the eq rather useless for playing a cv synth with any kind of release stage.
indeed, this is important from both sides of the ‘argument’ here.
Squarp have stated they will fix bugs, but its unlikely the Pyramid will get new features.
(this has been true for years, well before the hapax was released!)
so yes, they have committed to bug fixing.
(k, sometimes there is a grey line here… feature vs bug, but lets ignore that complication ;))
as for specific bugs, these should be reported on via the contact form.
Squarp are a small team, so priorities have to be assigned accordingly.
all bugs are annoying to users… if a bug affects you , and you cannot find a way around, of course, you think it has to have a high priority … thats completely natural.
however, as a developer, you have to look at the bigger picture…how many users does a particular bug/issue affect? user expectations? maturity of products?
this is why its important to report bugs via the contact form… so Squarp get a complete picture.
but, unfortunately, this is why I suspect, the pyramid is on the back-burner for bug fixing.
the pyramid firmware has not been updated recently (b4 hapax iirc),
so these are not new bugs and some may not even be new to the latest firmware release.
so its likely they are not affecting that many users.
whilst, with the hapax, lots of new users, lots of new features… is a recipe for a lot of bug reports, and users with expectations that this needs priority.
I am NOT saying this makes pyramid bugs less important, thats clearly NOT the case…
but resource allocation is based on priorities (amongst other things (*) )
so yeah, its on the back-burner… and only Squarp know when they are likely to have time work on these issues, so your best bet, is to ping them (contact form) … and ask if they can give a timeframe, but again, understand they have others asking the same of various hapax bugs/features etc.
but none of this means its ‘unsupported’ , afaik, its still being sold (subject to component availability), and as I mentioned above, I think is still a bit different to hapax, rather than totally superceeded (my opinion)
and as I pointed out before, Rample and Hermod received updates in the summer (so post Hapax) , so they are working on things other than Hapax, as priorities and resources allow.
anyway, just my take… the only one that matters is Squarp’s , and that you’ll get via the contact form.
(*) e.g. its possible the bugs mentioned may have been ‘looked at’ and may not be a trivial fix, and so require more time.
Please don’t act as an apologist for Squarp; it shuts down conversation. People have a right to voice criticisms of their products, and it doesn’t help resolve those problems if people jump on them for raising those concerns.
Part of the problem is that many of the currently existing features work in unexpected ways, and the “manual” is really more of a quick-start guide than a well-organized reference so it is difficult to identify and anticipate that things will not work as expected before purchasing the device. For instance, two advertised features of the device are the midi looper and the MULTI-mode, which assigns track 01A-16A to midi channels 1-16 and lets you record to all of these channels at once from different midi devices. That’s a pretty powerful feature, except it turns out that when in MULTI-mode, the looper will only work for the currently selected track, and this is only mentioned in passing in the manual. (MULTI-mode is explained in the Quickstart section on page 9 where it states, “This option allows you to record multi-channel events as a MIDI looper”. The looper is explained on page 14 in the section on the live mode with no reference to MULTI-mode. And actually, I can’t even find the spot anymore where the behavior is explained for how these things interact.)
In practice, suppose your default track length is set to 1 bar and track 03A is selected. You start recording a loop using a midi device on channels 3 and 4. Track 04A will start looping immediately after 1 bar since it’s not selected, but track 03A will wait until you hit play to start looping. That’s confusing AF, and when I first encountered this problem and posted about it on this forum, I got nothing from the company or the user base. Crickets. I had to pour over the manual multiple times and troubleshoot the problem for days. That’s inexcusable for a device that costs over 600 euros and is still being sold new on the company’s website. I own plenty of hardware synths/sequencers from smaller companies that do a much better job responding to their users’ questions.
The way I expected the looping to work is that it would dynamically set the same length on all tracks when in MULTI-mode. If I’m recording on tracks 03A and 04A, and I restart the loop after 7 bars then both tracks should be set to a 7-bar loop. If I ask Squarp to make this (expected) behavior an option then I’m told by people on this forum that, “No one should ever buy any product (of any sort from any company) unless they’re happy with what it is at the time of purchase at the price asked.” But it’s quite difficult from the shoddy manual to really understand what the product is at the time of purchase. From my perspective, I’m not asking for a new feature; I’m asking for basic functionality that I was led to believe the device had when I gave the company hundreds of euros for it.
Sounds like you bought some gear that doesn’t work the way you’d like it to. I’ve been there a lot, and tried a lot of different approaches to deal with it. By far the best has been to sell it and move on, so that’s the advice I offer you as well.
please don’t issue personal attacks… this is a discussion forum, we all have the right to express our opinions and perspectives, as long as its done politely and without prejudice.
you are welcome to disagree with my (and others) comments, and to have a discussion around them if you wish (or not, and you can also ignore) - but personal attacks (against any other user) are strictly against the ToC of this forum.
@pyra , It’s a pity you started an otherwise detailed and well-explained post with a personal attack against one of our most helpful contributors. I hope you recognize that you only made people less receptive to your points by being so rude.
I edited my post accordingly, but I do not find this contributor’s posts helpful; I find them to be dismissive. It frustrates me to no avail that anytime someone raises a concern about the product on these forums, there are people who rush in to defend Squarp. Like I’ve posted questions about how certain things work, and instead of answering those questions, people tell me why it’s not Squarp’s fault that those things don’t work and how we should give them a break because they are a small company. If people don’t have an answer for the question then they should just not post an answer. Telling users that it’s their fault for not doing enough research before they purchased the product or that they should lower their expectations is in no way helpful.
Fair advice. My point though is that Squarp basically advertises that the gear works one way when in fact it works another. That’s a problem, and I think it’s reasonable for users to be upset when they then abandon support for that product (which they are still selling new on their website.)
I think when many of us see statements like “I don’t like thing!” we read it as a question: “Why does thing work this way?”
In that light, we do not see this sort of response as “rushing to defend Squarp”, but rather as explaining why a thing is happening the way it is. Some of us find that helpful.
But the sense I’m getting from you (please correct me if I’m wrong) is that you don’t care about explanations or whys. You just want it to work different.
That’s certainly a very valid point of view! The only problem is this isn’t really the place for it. None of us here can change the way something works. But we know the boxes really well, so we can usually explain what’s going on. As a result, this is a totally “explanations and whys” kind of place.
The only people who actually have the power to change the way something works (namely Squarp employees) may occasionally poke in, but are not monitoring every post. The best place to get direct support or to advocate for a change to firmware is where it will be guaranteed to be seen by the people who can do something about it. That’s the contact form.
If you’ve reached out via the contact form and were not satisfied with the response, then again you have two options: force yourself to use gear you have an ever-growing resentment for, or sell it and move on. I’ve personally found the latter to be best for my mental health.
I understand your take, here. But I have to be honest, I read the manual a bunch before getting my Pyramid and never came away from it expecting multimode and the looper to interact the way you describe. So when you come in saying “many of the currently existing features work in unexpected ways” I kind of have to say “Hmm. No. I don’t agree.”
If, on the other hand, you simply said “This would work so much better for me if looping and muti behaved like… Would that be useful to anyone else?” I think you’d get a lot of support. Then you’re not asking people to think they way you do (because none of us really think the same) but instead are asking them to imagine new uses for gear. Which let’s be honest, we’re all here for.
Anyway, just some more unsolicited tips that have improved my forum interactions over the years. And a reminder that, even if everyone agrees and you have 1,000 hearts on a post proposing the best squencer feature ever, that doesn’t mean Squarp will see it. The contact form is your friend.
I have to say, your description of this forum really runs counter to my own experiences of it. I have asked the community multiple times for help understanding why something was not working, and I have never gotten a response that was even remotely helpful. For instance,
or
Even when you ask a question about Pyramid, people often respond with answers about Hapax. For instance:
Right now, as I am posting this response, only 1 of the 14 threads updated in the last two days was about Pyramid, and that was this thread right here asking if Pyramid is still supported with the release of Hapax. I think it’s very telling that this thread has so many responses, and the rare threads where people are asking for “explanations and whys” have so few responses.
From a Pyramid-user point of view, I have found this space to be like shouting questions into an empty field. There is just no one around and the people who are around want to talk about something else (Hapax) or they do not want to spend time helping others learn how to use the device.
Because of that, I think it is a really valid question to ask whether or not, with the release of Hapax, Pyramid is still supported. I felt seen when 909_State posted their question, and conversely, I felt very alienated and turned off by the responses they received for asking that question. The very first comment is super dismissive, suggesting that they should not have used the phrase “abandon-ware” and then literally changing the title for them to make it less “confrontational”. Then, there is another individual who felt the need to lecture them on the fact that “No one should ever buy any product (of any sort from any company) unless they’re happy with what it is at the time of purchase at the price asked.”
All of this feels really dismissive and judgemental. I found those responses much more frustrating than the fact that Pyramid doesn’t do exactly what I want it to do. It kind of made me not want to come back here.
The point of my post was not to say, “hey, I just want this thing to work differently”; it was to say, “hey, some of you might want to reconsider how you responded to the original poster’s question.” The documentation for Pyramid is organized more like a quick-start guide than a comprehensive reference manual, and this forum is pretty much the only other place on the internet where one can search for answers about how the device works … but everyone on this forum is talking about Hapax, not Pyramid. As a result, it is a super valid question to ask if the device is still supported. Rather than censuring the user or lecturing them on what their expectations should have been for the device, maybe just say, “Hey, I hear your frustration. I don’t have an answer but you could ask Squarp directly through the contact form” and then move on.
). In my opinion it is important to separate clearly the two different issues of “developing new features”, and “fixing bugs”, especially since some now seem to use arguments against requesting new features as arguments against requesting that outstanding bugs be fixed, or at least conflate these issues to such an extent that the distinction gets lost.