Clarifying statement on Aeros firmware updates

Aeros Loop Studio
1

Received an email that said Aeros firmware updates will continue through 2023 and pointed to a statement on the Aeros product page, https://singularsound.com/product/aeros-loop-studio/. Note that the BeatBuddy says lifetime support.

I certainly don’t expect a lifetime of feature enhancements and would expect this to naturally slow down as the product matures and becomes feature complete. Bug fixes are slightly different. It’s hard for us to understand what the end state of the device will be especially as the pace of development is somewhat slow and hard to predict. Is there a set of features and types of issues that SS expects to complete? There’s a lot of untapped potential (and unused hardware) in this device that many of us bought into…

@DavidPackouz Can you clarify this and put us at ease? Is there a reason you made this statement now?

This is a bit disturbing as SS uses a kickstarter model and develops features and fixes significant issues after selling/releasing the product (and at a somewhat slow pace). This is a very expensive device as well. Not sure if it would have been better to make no public statement of this policy (which can be viewed as positive or negative).

3 Likes
2

Apologies for the confusion regarding these statements - I’ll work on clarifying the marketing jargon shortly to make it clearer.

TL;DR: Firmware updates won’t end in 2023, they’re guaranteed to last at least through 2023. Given that we’ve been developing the BeatBuddy for 7+ years now, there’s no reason to think the Aeros will be dropped off suddenly.

Full transparency here - that statement is written the way it is on the page because I ran an A/B test and we found that visitors converted more with that statement present. The A/B test included the number of years we made the commitment for and we found that 2023 was the most effective variation. So the timeframe isn’t so much based on real constraints, but rather what we found most effective from a marketing perspective.

Internally we’ve always been committed to the long term development of our products. That hasn’t changed. If anything, this statement should be read as a slight reassurance because we’re now publicly committed to development through at least 2023. I think it’s reasonable to expect that if we can squeeze more out of the Aeros’ hardware in a future firmware update we’ll continue to do so.

Additionally, even when we eventually decide to no longer add new features, we’d never want to leave a product with a bug where possible. So a lack of feature development wouldn’t mean a lack of support for the product in the form of bug fixes. Speaking of support…

The original intent of the lifetime support statement on the BeatBuddy was not in regards to firmware development, but rather our support staff offering troubleshooting via email. Officially, we’ve never made a time length commitment for the development of the BeatBuddy, but we have made specific promises for features (like autopilot) which we continue to work hard on.

Even after 7+ years, we have no plans to stop firmware development on the BeatBuddy. Not even after those promised features are implemented. That’s saying a lot in an industry where many others release a pedal and never update it.

3 Likes
3

Thanks. Appreciate the clarification. Makes sense. As we get closer to 2023, this may perform worse…

(My personal reaction is that the new statement raises a concern rather than alleviates it.)

FYI, the old text for the Aeros page says:

image
image1186×148 11.9 KB

4

Thanks. Appreciate the clarification. Makes sense. As we get closer to 2023, this may perform worse…

Agreed, I’ll be retesting as we grow closer to that date. :slight_smile:

And thanks for the feedback! The deletion of Lifetime Support was an error more than anything, was in a meeting so I couldn’t fix it right away, but the page reads like this now:

image

2 Likes
5

Thank you for the assurance and clarification.

6

Hopefully I’ll get better midi implementation, reverse and speed options and decay options before 2023… /end sarcasm :laughing:

2 Likes
7

I wonder if you ever considered adopting the open source model and getting a sharp increase in development speed free of charge. Seems to be pretty safe commercially, as the software is useless without the hardware, and also open source does not imply unrestricted license. The community would get all the long awaited features in no time, while SS role would shift significantly towards code reviews and official version management. The device features exceptionally capable platform with all the imaginable communication interfaces. But the product still misses quite basic features, like midi out, desktop configurator app, midi commands matching foot switch options to name a few.

3 Likes
8

I am thinking along the lines of what @AlexBoston is proposing.

Just to introduce myself, I have a 30+ year history of Open Source development, including firmware for embedded devices. Deployments range from projects that only have hundreds of niche devices all the way to millions of consumer electronics devices, such as STBs and PVRs.

To paint a fuller picture, Open Sourcing the firmware for a product rarely lessens the workload or somehow absolves a manufacturer from ongoing development. However, having the full firmware source code and build system out there on the Internet will allow a few motivated individuals to roll up their sleeves and get involved. It’s often the case that one or two people (who engage with the Open Source project out of the blue) will bring a new perspective and shine a new light on problems that allow the internal development team to make progress after they’ve been stuck.

On the flip side, if the company redirects their resources towards other projects (say BeatBuddy2), and can not stretch their resources to maintain the older products, the Open Source community can pick up the slack and keep the product alive. The company then only needs to provide minimal support for the Open Source projects and commission manufacturing runs as required to keep up the hardware stock and reap recurring revenue. Of course, this depends on the product being good enough and having a following of capable fans, but I’m pretty sure that Singular Sound is in a good place when it comes to BeatBuddy and Aeros. Perhaps not the BeatBuddy Mini and Mini 2, given their limitations.

My recommendation would be to:

  • Open Source as much of the BeatBuddy and Aeros firmware as possible and provide the necessary build infrastructure for third parties to build alternate firmware. Potential contributors should be able to build and install development firmware on their devices.
  • Encourage potential contributors to build their own firmware and thoroughly test their improvements, even share these with like minded individuals who are willing to experiment.
  • Review the contributions and provide constructive feedback and if appropriate.
  • Merge the contributions into beta firmware and eventually into production releases.

As I mentioned above, I have a lot of experience with such projects. There are no guarantees of success. Open Sourcing a project is only a way of opening doors that can lead to opportunities. But if those doors are not open, the opportunities will not materialise.

5 Likes
9

Appreciate your experience-based input.

As an interested observer of the BeatBuddy open source process, I can only offer that it doesn’t seem to have produced anything useable. This might be because SS wanted to curate the process. Now that the curator seems to have moved on, the process is in hibernation. If SS were to follow the same path for the Aeros and the Maestro, would it be reasonable to expect the same outcome?

1 Like
10

Open Source contributions can be unpredictable. However, there are some patterns that can be observed repeatedly. One of my colleagues has published a number of papers (including a PhD.) on Open Source development and the dynamics involved. In a nutshell, the trick is to leave enough fertile ground so that a contributor can start thriving, then nurture the contributors until they prove themselves and can stand on their own.

Just dumping existing source code to GitHub is not enough most of the time. Sure, there are some of us that have such strong urges to fix broken things that we will pick up dump-and-run source code, create forks and maintain our own alternative firmware, but in the long run this approach produces no winners. The company is not getting value in return because they are not engaging with the potential value-add from contributors. The contributors become disengaged because they receive no recognition - they go as far as solving their own problems, but no further. The wide customer base sees no benefit because there are no new official firmware releases that deliver the desired improvements.

A successful Open Source project requires long term commitment with no expectations. Internally, the best way to view an Open Sourced project is to treat it as a historical record / resume / journal of your achievements.

First step is to accept that the code you are publishing may be far from perfect and there may be kludges in there that you are not proud of. Many people become stuck at this point. They may feel like they need to “clean up” the code before publishing. My advice is “don’t worry about it”, if it almost works, that’s good enough; if it’s very broken, someone will fix it; and if it is somewhere in between, it will get attention in due time. Or to view it from another angle - if it was good enough to ship to thousands of customers in binary form, it’s good enough to publish the source code to a handful of coders. Coders who could potentially help with those tricky parts.

The second step is to realise that turning the source code into something that people can run and test is extremely important. Providing build and deployment instructions is often the difference between an Open Source project getting traction and flopping. The first thing that a contributor wants to do is to download/clone the source code, build it without modifications, deploy the results and test that it works. That’s before they change a single line of code. If they can not achieve this goal before frustration sets in, your project has lost a potential contributor.

Successful engagement with Open Source projects is a common problem for many companies. Amazingly, the solution is often very easy and very cost effective, but it does fly in the face of the usual “bean counter” approach to management. I worked with/for companies who successfully engage with the Open Source communities and they range from two-man-show businesses to the giants the size of Intel. The landscape is changing though. Many companies now recognise the value of engaging with their customers through various social media channels. Open Source communities are very similar, but they are more (technically) mature and require a different set of skills. At the end of the day, successful Open Source engagement is just another point of differentiation / advantage for a company - it’s not the ultimate answer to all the problems, rather it is just one facet of a successful and thriving company.

4 Likes
11

SS poorly managed the open sourcing of the BB Editor. Another open source effort could do better (or worse).

SS never provided source that would build for me and documentation of the build environment was incomplete and glossed over details. If a new developer cannot quickly get to the point where they can build the code and make changes, you lose their goodwill and the project is challenged. I also recall, SS kept most of their changes private. They also had a rotating door of remote, contract developer to work on the project that was not responsive.

2 Likes
12

That’s exactly the type of hurdles that I refer to in my previous post. On most of my projects, this problem has been solved by either providing build and configuration scripts with instructions or step by step instructions (including copy/paste command line incantations) that are tested to get a user from zero to a testable binary. This is also accompanied by contact information and an invitation to get in touch to get help if/when stuck.

Sometimes users need a fair bit of help to get going. I recall one time a developer tried to use an old MacBook to run the Linux build environment in a virtual machine. The build kept on crashing for him for no obvious reason. Eventually we tracked the problem down to the fact that the ancient CPU in his old Mac did not have support for some Intel CPU instructions that the toolchain was trying to use. The fix was to change the way the cross-compiler was built, which required me to update the entire SDK for several platforms. A couple of days of rebuilds and 12GB of SDK and firmware uploads later, the new developer was up and running. This was time well invested, as this developer has contributed thousands of code changes to the project over the years. His contributions have improved the products in significant ways and he enjoys a lot of respect and admiration from the entire user community. He has outlasted the paid staff from four ODM companies that worked on the projects. Companies that employed a closed source development model internally and only reluctantly obliged to my client’s request for source code releases of core components. But that’s a long story that is best told over many good beers… :beers: :wink:

The amount of effort that potential contributors will go through to get started on an Open Source project varies. Some will give up after less than half an hour, some will persist for a whole day. However, in most cases, if a developer can not get the project off the ground and start making changes in one night, they will walk away.

Managing the code contributions and developing in the open are the next two pieces of the puzzle.

A long time ago I made it a policy that all firmware releases that I manage (including first production and pre-production factory runs for new models of hardware), must be built from source code published in public repositories on GitHub/BitBucket. There are mechanisms to switch out various packages to developer’s own forks of the public repositories, but those private builds are never used for public releases. I work on the premise that if I was going to be run over by a cruise ship tonight, then tomorrow someone should be able to fork the code repositories, rebuild the firmware and keep going. (Or as it happened on a previous project, the company had liquidators appointed and all staff were locked out at 10am on a Friday morning and all services were shut down. By Sunday night, customers had alternate firmware images and new software feeds available thanks to the Open Source community. If it was not set up this way, customers would have bricked devices, because the liquidator would not spend any money on keeping the existing customer base operational as it was not bringing in additional revenue. Again, :beer: :wink:) The current firmware images I maintain have over 10,000 packages, including full Linux kernel builds, third party device drivers and online repositories of optional plugins. Most of the product related contributions that I receive from the community are actually only affecting about four or five packages/repositories. Most of the other updates tend to be pulling patches and security fixes from upstream feeds.

Anyway, long story, but the crux is that Open Source development can provide great value, however it needs support from the top level management of the company. It is a long term commitment and it is challenging to quantify/justify doing so if the management takes a narrow minded traditional approach that only focuses on balance sheets and stock price using the models that have been entrenched for so long. The tide is slowly turning. Open Source, social responsibility and the scrutiny of social media that leads to public perception all affect the value of a company and it’s ability to attract and keep customers. Companies are now realising that to do well, they need to pay attention to these aspect too. My perception is that Singular Sound are very likely to have the right philosophy at the core. Managing Open Source engagement may not be their forte just yet, but if they commit some resources to it and bring in someone experienced they could do really well. If nothing else, it would improve their internal processes and make it easier to be agile and bring in extra talent as required.

4 Likes
13

Ridiculous statement … for what I paid for Aeros I had never even considered that I could end up with an

orphan device in 2023. Until now. So now I must begin deliberations if I should keep it.

And with software development in disarray, I wonder if you’ll make it to 2023.

14

That is exactly the interpretation that @DavidPackouz dispelled … and the reason for the original post.

It’s a guarantee of providing feature updates through a date and was intended as a marketing benefit. The opposite (updates stop in 2023) is not true. I agree it’s too easy to take this message in the most negative way.

They intend to update features as long as it is feasible and will continue to fix bugs when that doesn’t make sense. To date, slowly but surely we’re getting the right features and issues resolved. It can ty your patience if there’s one thing you really need. Loopers are long tail on unique features. I think your investment in the device is safe and many (but perhaps not all) of your pet features will come.

3 Likes
15

Dispelled? I don’t think so. Not only is it a real possibility that SS will cease to exist before 2023, given its track record over the past 5 years on delivering quality products, but the fact that the only thing they seem to do well (marketing) used an “A/B” test to determine the best language for their advertising and this was the best option they came up with! Do we even want to hear what the ridiculous losing option was? How about doing A/B/C/D/E/F/G testing, or hiring people with real experience doing any of the things you have “ideas” about creating (e.g., software development, hardware development, customer service). I think I speak for a large majority of users here that we feel duped into buying a tech product from a couple of musicians that thought an idea was enough to create and sell a real product, not just a $400 beta toy that gets thrown in the corner after frustration. Leave it to the real pedal developers to eventually take and execute on BB’s vision.

16

Respectfully, this is a baseless claim. Singular Sound just had one of our best years ever and we’re in a very strong position as a company right now. Obviously the future is never certain, but Singular Sound ceasing to exist would be incredibly surprising to say the least.

I almost always run multi-variant tests, I just call them A/B tests cause it’s shorter to type and I didn’t think anyone would care about the distinction. My apologies, and I’ll be sure to make that distinction going forward. The development statement test had 4 variants, and the “losing version” was just the default “lifetime support” text. The winning version (including the 2023 commitment) had a statistically significant impact on the number of new Aeros orders.

Which was the intent of that messaging. It was to attract new customers, who overwhelmingly view it positively. As a company, we have always been and continue to be committed to creating lasting products and improving them over time. BeatBuddy is getting an update this week, 7 years after being released, and the Aeros is receiving updates with a 1-2 month frequency.

That being said, I sympathize with your frustration. The users on this forum are our most devoted and often the most advanced users of our gear. Many of you are more skilled or technically apt musicians than us! As a result, you often use our products in ways we never anticipated, and have feature requests that are similarly unanticipated. The Aeros Development for example has gone in a completely different direction than we originally planned, because we’ve been listening to you all and focusing on your needs.

Just know that we’re here to stay. We’re committed to all of our product lineup and you. And we’re working to be better. Speaking of…

We’re always working to optimize our development process. That includes bringing on new developers and attempting different organizations of the teams. As has been noted in this thread, we did try Open Source with the BeatBuddy manager, but it didn’t yield in the results that we or the community were hoping for.

We’re not opposed to trying it again in the future, but we’ve got a few optimizations we’re making in other realms of the development team and process that we’re going to work on first.

4 Likes
17

I really don’t know where you get that kind of data from because everything I get pedal wise usually has many updates. Line 6 helix products for instance over 5 yrs of having a few updates a year, my empress zoia gets updates off and on my morningstar midi controller gets updates off and on and plenty of other pedals and synthesizers and other hardware devices I’ve had or used to have does / did as well.

Not trying to sound rude here so please don’t take it the wrong way but I’ve seen this from 2 SS employees now boasting the same thing when it’s really not a true statement and pretty bold to say because other companies are indeed releasing free updates as well that I’ve been associated with.

18

Definitely not rude - we value the input and your experiences there. Perhaps we do need to walk back that statement. It’s based mostly on our individual experiences as musicians within the company more than anything else.

I know I was for sure making the statement based on my own personally experiences vs anything concrete. Maybe I’m using the wrong pedals! Not enough GAS perhaps. :smiley:

1 Like
19

There is a company out there… they probably sell the most looper pedals globally. They tend not to update almost ever and only listen to customers for designing “next years” pedals. That said usually they don’t have glaring limitations or defects in their clunky software upon release. While I was massively disappointed in the state of the Aeros software when I received it, I can see SS is really working at fulfilling promises of the unit. Thats comforting. I am looking forward to looping on it for years to come (that is once auto-Q and beat detection and silent clear all, are there and the unit will fit my type of work flow, because right now I am working with other company’s 300 due to my workflow and song styles. I am sitting on a really expensive and beautiful pedal that I don’t trust to use live. Please hurry)

2 Likes
20

Rhymes with floss and starts with a B?

1 Like