Hi Qu-Bit! I’ve been doing some homework in advance of potentially buying a Bloom and wanted to ask some questions about the future of the module. On its surface it seems like a pretty awesome sweet-spot melodic sequencer - it can split the difference between “programmed” and “generative” in a way that feels really unique and appealing to me. From the research I’ve done, there are a couple things about how it works that I feel might cause me some frustration, some which seem like they might be fixable with firmware updates, and some that might need a v2 of the module because they’re require different hardware or labeling:
Maybe possible with firmware update
true ratcheting rather than note repeat
some way to change, at minimum, per-step gate length, but potentially other per-step functions, without stopping the sequencer from playing, for use during live performance where you can’t really afford to stop your sequencer
Would probably require new version of the module or some kind of configuration utility plus the ability to ignore what’s actually labeled on the faceplate
Different (or configurable) CV inputs (e.g. gate length, slew, div/mult, ratcheting, scale) rather than or in addition to the ones currently provided
Are there any future firmware updates anticipated that will add this kind of functionality, and/or is a Bloom v2 in development/consideration/etc.?
My main two things would be: true ratcheting and a way to reign in the randomness. The latter one is that very often bloom goes way too high in pitch away from the core sequence. It just sounds wacky and stands out way too much. A lot of folks have been complaining about this on the MW forum, and it’s really the thing that causes me to not use it as much as I’d like. I’d love to be able to just reduce the range that bloom can go up to.
The ratcheting one is just a no brainer and was a very odd design decision. I know they’ve explained the reason for it elsewhere (consistency of terminology with an older module) but it’s just confusing to new users and much less useful than true ratcheting.
That makes sense. One of the trickiest things about generative/random IMO is how to rein in how random it is. I really like how MI Marbles allows you to affect the spread of notes and where the clustering of them occurs across the pitch range. I think that kind of nuanced control is really helpful when working with randomization. I like how Bloom can send you down different branches but I’m curious about whether the deeper variations further along the tree really feel like derivative variations of the original sequence or whether they are so varied by that point that the human ear wouldn’t detect the connection—especially if you’re also making cv-related modifications to them. That’s one reason I think cv control over elements besides e.g branches might be more useful to me; working within one or two branches but using cv to modify slew, gate length, etc (or note range like you say) would I think create variation that i’d find more compositionally usable than zipping around between different branches.
Yeah totally agree. It’s rare that bloom generates sequences that sound connected to the original. I’d love to have it generate sequences where only a handful of notes have changed or perhaps it just uses the existing notes in different orders. Currently it’s just completely untamed and therefore far less musical useful.
I’d happily ditch the mutate control, which I don’t think I’ve ever used and, again, is much less musically useful.
I’d be pretty happy, if an update manages to recofigure the Note-Ties by long gates: Up until now, the Gatelength can stretch over all steps available but only if each single step on the way is activated and additionally it picks up every pitch per step. - It would be nice, if the gate stretches over several notes without the need for them to be switched on (or it automatically switches them on) and/ or the pitches in the notes successing would be overridden by by the pitch of the starting-note.
I have also noticed when skipping a step, then re-enabling it, the gate is reset minimum length. It would be nice if the step remembered its gate length. It would allow some creative real-time use when working with each step.
Oh… also. I love the [note] option that plays the CV per step when tuning (makes setting up much easier), but when tuning it would be nice if a gate was generated with each tick. I worked around this by temporarily patching to the clock output.
Do QuBit actually respond to any of these requests, I get the feeling they are done with Bloom regarding updates? About to sell mine (and probably surface) now due to zero support, life is too short!
Many of these are definitely on our hit list for an update.
The only reason we have not released an update for the Bloom is that due to the chip shortage, there are many different versions of the hardware which may end up requiring making 3-4 different versions of the firmware, and certain versions are more difficult to update the firmware than others.
Unless we can find an elegant solution to that problem, the update would be almost impossible to accomplish due to managing firmware creation, and bug tracking etc. for each separate version of hardware.
I hope this sheds some clarity!
We are very interested in ongoing support for our products.
This is actually one of the reasons we started basing all new designs on the Daisy platform for easy updating, and backwards compatible firmware.
That makes a ton of sense, and thanks for sharing.
(For what it’s worth, I definitely perceive the commitment to support and continued updates. The new Data Bender firmware is fantastic, and that module remains one of my absolute favorites - a total “this is why you get into Eurorack”-level module. LEGEND!)
what about releasing a firmware for the latest version and then offering existing older version module owners a paid path to swap the chips on their module to enable the firmware update along with future updates? Similar to how synthstrom deluge allowed the oled screen swap. They let customers get in line and perform a certain number of swaps each month, each swap is a paid upgrade.
It seems like users have a lot of love for the potential of this sequencer but the current state of features and firmware is holding it back.
Echo this EM - seems like QuBit are saying, sorry Bloom is now stuck in the past, sorry about that, we might release a Bloom II and of course we expect you to pay for that in full …
Is there an update on this situation? Has this proven impossible? Someone had suggested an upgrade path to the Daisy chip for owners with older versions.
I would feel a little cheated, as a newer owner, that QuBit would make a Daisy version just to abandon it and start working on what I would guess is a Bloom 2? The radio silence on even discussing updates on this thread is troubling =\
@Jaimison the situation has not changed since our last update.
We are more than willing to create a FW update for the Bloom to improve the feature set, but it is especially problematic since the module was not originally designed to be updated in the field, and we now have two completely different sets of hardware due to the chip shortage.
We are still examining if it makes sense to do an update and how we can accomplish that without leaving half the user base in the dust.
In response to the suggestion by @ekkomouse this is not viable because the circuit board uses two completely different layouts for the MCU / Daisy. It is not possible to provide any upgrade path from the old hardware to the new hardware.
(my opinion; YMMV) While I welcome/celebrate New Firmware Day, I don’t think any company owes new firmware to their users except in cases of:
Bug fixes
Features that were promised at launch but remain undelivered
A module described and sold as a “platform” with continued updates coming indefinitely (so, kind of #2 again).
If users are paying a subscription or ongoing fee.
And especially not in cases where unpredictable supply chain issues have impacts on hardware availability and increase the complexity of making and distributing new firmwares. Love when companies do it (Erica Black Sequencer just got a fresh update despite Erica having newer products on the market; Mutable Instruments dropping Plaits v1.2 on Emilie’s way out; the Data Bender firmware mentioned in this very thread) but IMO it’s a great bonus when it happens.
While I understand the business decisions made about bloom hardware during a difficult time period, I have to agree with others… this consequence had to have been considered and owners should NOT be abandoned because of this.
Bloom is an amazing product and it would be a shame for people to be stuck like this. It has so much potential.
Qu-bit- there has to be a solution to this problem. It might to you need to invest in what you have created. People who want to upgrade may have to deal with the complexities depending on hardware, but you should continue to support your customers. Maybe you release code as open source and solicit great developers to enhance bloom… please move forward. Being stuck like this really sucks.
Yeah you’re right but number 2 on your list is a feature promised and not delivered
The module does not ratchet in the true sense of the word
At this stage the module is relatively old in eurorack terms and it certainly wasn’t a cheap module either
Qu-bit could:
Open source the code, make it available to those who would like to develop it further
They could develop the code anyways - it’s hardly the consumers fault they decided the build the different runs of the module on different chips and boards
Seems like it’s a bit iffy that we get any firmware updates to Bloom, but thought I might as well throw a few cents in here anyway. Purchased a new bloom a few months ago, and I do love the concept/form of it but I agree with a lot of the gripes shared here (+1 on subdividing ratchets if it were possible). I did have an idea though-
I think it would be great and maybe simple if we could toggle to exclude parameters from the branches/mutation. Maybe hold shift+hold parameter knob for 3 seconds type of thing (is that already used?). Perhaps like others have said, ability to scale the depth of potential change on parameters (like pitch so it doesn’t jump so many octaves within any new branch). A value of 0 would exclude the parameter from changing in branches.
For example, my main pain point with bloom is really the gate lengths being changed so drastically across branches. It makes using gate length ties pretty fruitless if you plan to add branches as they become so scrambled and chaotic even on the second branch which breaks whatever rhythm you set up for.
I’m using Bloom usually to sequence long-sweeping chord pads (with Qu-Bit Chord) so I generally set %80-90 gates for my ASDR gen, and would like to tie notes together (even with pitch changes, hooray for slew!) but in the subsequent branches the ties/gate lengths just go haywire and I have to settle for no ties and accept a pretty standard divided rhythm.
Sorry for the essay first post… Just wanted to share thoughts and celebrate Bloom as I think it’s a powerhouse for generative synth, kind of a dream marriage of sequencer and shift-register but could be a bit better in holding musicality through branches. I for one think the mutation function works pretty great as it is, but the branches seem to be too wild for me but I like that it all returns to the trunk which helps hold a theme.
I’d love to have the ability to update my scales on Bloom, just intonation is the most important for me but, some other options wouldn’t hurt either. You guys could make the code available for some of us to make some mods.
first post… Just wanted to share thoughts and celebrate Bloom as I think it’s a powerhouse for generative synth, kind of a dream marriage of sequencer and shift-register but could be a bit better in holding musicality through branches. I for one think the mutation function works pretty great as it is, but the branches seem to be too wild for me but I like that it all returns to the trunk which helps hold a theme.
