It’s my sincere hope that I don’t come across sounding like a jerk in this post, but I’d like to offer a perspective to my fellow users.
There has been a rash of recent posts about “faults” or “problems” with Beads (and other modules as well); some of these posts are quite valid, and have revealed issues that pinchenettes has been incredibly responsive to, with hours of testing and troubleshooting and new code being written for fixes. This level of customer and product support is unequaled in this space, in my experience, and it’s hugely appreciated.
However there have been more than a few posts where there is actually no fault present, and the module is performing correctly and the errant sound is nothing more than a less-than-pleasing sound which can be remedied by making a few adjustments in the settings of the module. With the range of parameters available in these great designs it is very possible to dial in something that sounds “wrong”, and our first response should not be to jump on the forum and suggest a fault in the module, but rather to go back to the manual, study our patch, understand the controls and try to see what is going on.
I would encourage folks to do more of this trouble-shooting on their own; check input levels, check your source material, check your settings; swap out to a different case or power supply, change a patch cable and re-read the manual and documentation. All of these are basic, first step trouble shooting techniques, and we should try to exhaust all these options before posting to the forum that we have discovered an “issue”. We are putting a lot of load on what is a single person operation, and a noticeable percent of these posts turn out to be “operator error” or no problem at all.
I would gently remind folks that one can create a wide range of sounds, both pleasing and horrible, using this kind of very flexible equipment, and I would hope that we could all look to our own patches and really try to understand how we are manipulating the sounds, before coming to the boards to report a problem where there isn’t, in fact, a problem. We are all learning how a new instrument works.
And again, I really hope I don’t come across as a jerk for suggesting this - I hope you can all take it in the spirit in which it is intended: with respect.
With more than 3 years having passed since Clouds was discontinued, the expectations for this module were insane. If it took so long, there had to be a reason for it, and this reason must have been that this thing absolutely has to be awesome and game-changing and go above everyone’s expectations. It took so long simply because there was a major design change, and I worked on it only part-time.
That so many modules reached so many customers in a matter of days is a first for me, and probably for any modular manufacturer. This “density” is an order of magnitude higher than for any previous release, which were more spread out over time and consisted of a smaller number of units.
Many people view Beads as “Clouds 2”, and thus expect the recipes or settings that worked with Clouds to work with Beads. In particular, it is expected that Beads will preserve the “mushiness” of Clouds. What made Clouds mushy (allpass filter bank, no grain-stealing, only symmetric envelopes, 32k, reverb partially activated in freeze mode) is either absent from Beads, or relegated to a narrow portion of the parameter space. The noisy, chaotic, percussive, formant-y, “grainy” areas are all new.
I could have done a better job with the testing phase. What happened, I think, is that each tester quickly figured out which tiny corner of the module (in terms of parameter ranges, patching strategies, quality mode…) worked best for their music, and stayed within that range. The use cases are large (much larger than, say, Plaits), the behavior of the module can also be very dependent on the source material. Maybe I should have involved four or five times more people in the testing. To my credit, it was extremely risky to give away such an expected release to untrusted people, and I’m not even sure more testers would have helped. There might be a kind of honeymoon effect too – where people are so happy to get, for free, something before everyone else, that they are not as demanding as they would be with something they have paid hard cash for
I shot myself in the foot with that 48k/stereo crackling bug (which truly is the least forgivable one). Once aware of it, people’s attitude towards the module shifted to “This thing is buggy anyway, if the output is strange it is yet another bug”. So far, the most common support request has been from users enabling the trigger output on the R channel, not understanding why it also came on the L channel (normalization!), and considering it a severe instance of the “L channel crackling bug”.
In other news, I’m searching today for one or two more optimizations that will make the module’s CPU endure the absolute worst case scenario (you need a special combinations of external CV to reach it), and then the only thing left is more testing before releasing a firmware update!
It’s the ultimate easter egg: a rare crackling bug that requires a special handshake of very specific settings, hidden in a module that is all about a notoriously crackly, glitchy, clicky type of synthesis.
Well said @ksparling . I’ve been feeling a bit fed up with the volume of ‘suggestions’ I’ve seen (not spcifically here or from any one user in particular) about how things could be ‘better’ and why they’d prefer that the module behaved differently. It feels like if someone spent years working on inventing the guitar and then a handful of people to buy it suggested that the strings were all in a different order and that they’d prefer a square body rather than a round one etc. ‘This is faulty because I can’t play polyphonic notes on the same string with multiple fingers’ etc. Give the creator a little credit eh? Plus, and this is a huge PLUS, it’s Mutable Instruments so the source code will come out and you will have every opportunity to ‘fix’ the bits of the module you think should have been done differently if you put the work in.
I think @pichenettes has done a bang up amazing job (like we’ve come to expect anything else?) in dealing with the shear volume of comments, queries, ‘bugs’ and suggestions both here and on Muffs (and possibly other places too).
I’m so happy just sitting back, enjoying and appreciating the fruits of a few years work by one of my genuine heroes and learning the quirks and intricacies of how to play this new instrument and the ways I can work with it to get the stuff that’s in my inside out.
This is a real thing; in the world of film we often do ‘test screenings’ to see how something is playing for an audience, but there are many of us who believe this is a mostly fruitless practice, since a significant number of participants are just excited to see the movie before anyone else (so they give it raves), or else they take it as their moment to suddenly become a film critic, or worse, a little director, (and hence give long lists of everything that should be changed or is not working). The useful feedback falls in a very narrow band, from only a subset of the viewers.
You have mentioned in the past that only a very few testers explore the outer fringes of a new module’s possibilities; it does take time to find those corners and apply them to our musical intentions.
As a beta tester, I try to be really thorough. Sure it’s thrilling to get to play with more gear but I know finding bugs and giving the best feedback you can is the whole point. I’m a software developer in my day job, so I really appreciate testers finding bugs before release, instead of users finding them after…
I did find a few issues early on. And I’m fairly sure that I thoroughly tested a wide variety of parameter ranges with a clean sine looking for glitches that weren’t easily explained as part of what granular does… in mono!
If I’d thought from the angle of “what if there are combinations that overload the CPU?” I would probably have gone right to the highest possible density/quality/stereo, with reverb and pitch shifting. I probably wouldn’t have guessed that the envelopes are more than just a simple linear or polynomial rise/fall, but the chances I’d have found this one would have been that much better.
After the first couple of weeks, and briefly after new firmware, I mostly switched over to using it in my music in the way that felt right to me… and yes, I definitely had a comfort zone with particular habits. For example: I really like the two “lowest” quality modes. I like triggering grains from a musical clock (thus not very much grain overlap), or using it as a voice (with a drone, captured buffer or the wavetable… again, not much grain overlap).
Realizing that I was using such a versatile tool in just a few ways, I re-read Curtis Roads’ Microsound and started to experiment more with actual granular synthesis – but while that meant firing off grains much faster and staying more in the highest quality mode, it also usually meant shorter grains and mono input, so it still didn’t lead me toward finding that particular bug.
I love that you have such an awesome mindset and creative method of building fresh new modules that are not just rehashes of the old versions! So far, I have really enjoyed Plaits, Rings, Marbles and other modules. Looking forward to Beads and Blades when I get more rack space.
I agree and in fact was able to figure out how to solve an issue that I had with my Marbles module t and Y buttons not illuminating on/off. I simply turned off the power to the case, unplugged Marbles, replugged it back in after checking the connection and powered the case back off. Now it works. I’ve had to do that a few times so it could be a short somewhere either in my case or the module causing this to happen. But I love troubleshooting so will do some more testing on my part without opening a support request for the time being.