I prefer to have customer expectations low before purchase and then exceeded after delivery. The first step towards that goal is properly worded product copy and documentation that does not exaggerate or mislead. However, my interpretations are not always commonly shared. So if you see anything in any of my writings that caused you to expect more than what was delivered could you please share here. As usual, feel free to be picky but also be open to disagreement/multiple viewpoints.
I would be very grateful!
I’ll go first with a question:
Grain Stretch and Clocked Stretch units. I would say that these two units implement time stretching. Is that misleading?
Nope! “Stretch” in audio instinctively relates to time. A user isn’t going to stretch dynamics or stretch eq as an example. Stretching Audio? Feels time related from the get go.
And you’ve always been very clear on the main page that the 301 is under constant development.
Curious, have you received customer kickback?
Yes but not recently. I keep a list of “things to do when I have more emotional distance”. This was one of those things. That and I’m about to go on a documentation refresh/rampage.
That would cause you to expect less right? I’m ok with that. jk
I think the fact that your product page for the ER-301 prominently displays a video showing off firmware 0.1.x qualifies as understated.
I will keep an eye out when I’m in the docs and such for anything that could be construed as a potential oversell, but I think you’ve always done a good job with representing its current capabilities and including caveats.
Getting to 100% satisfaction might be an unrealistic goal with a niche product like a Eurorack module. We’ve probably all bought a module that we ended up not liking so much - not because it was a bad module or oversold, but simply because it turned out to not be a good workflow fit, or whatever.
My opinion based on what I’ve observed from forum posts is that if someone is going to be disappointed with the ER-301, it most likely won’t be due to exaggerated product copy, but more likely because:
a) they underestimated the learning curve required to get the results they wanted to get
b) they were hoping a particular feature would be higher priority in the development pipeline than it is or was
That sounds like a great idea!
And definitely one of those things that will help with customer expectations. In every respect: the functionality of the module AND expectations related to learning curve.
I’ve always been very happy with all things er301!!!
But I’ll keep an eye out.
I wonder if understatement from your side while the module is in lively use in the world combined with the work in progress disclaimer and the lack of an manual also could lead to some kind of myth around the 301 with the impression that everything one dreams of is possible and might be implemented soon. Refined documentation could then in fact clear that up and prevent from unrealistic expectations.
The basics of communication essentially mean that no matter how much you stress about something being clear, there will ALWAYS be someone who does not understand or interprets it as was intended.
Now don’t get me wrong, I think improving the documentation to improve the documentation is great. But don’t do it under the impression that you’ll be able to prevent disappointment from misunderstands. With the amount of info on the internet about the 301, the onus is on the customer as you have more than done your part.
Just be sure that it’s clear they both implement granular time-stretching – I believe there is a difference?
My impression of the ER-301 is that it is just hugely powerful: assuming the CPU capacity doesn’t get the user down. Not to sound like a fanboi, but what can it not do out the box / with accents? I’m just intrigued what people have stumbled over.
You may want to clarify ‘scope’.
And you may want to explain your own [the designer’s] concept of live workflow etc. – I mean how you see the er-301 being used, and what it was, essentially, designed for.
I just bought it for time-stretch, panning, and sample playback, but its switching capacity is going to really help [those two extra outs]. I was never really going to be disappointed with the module, given that – unless the manual grains unit defeated me and I could not stretch.
Incidentally, please do clarify the difference between clocked and grain stretch, in your documentation.
I mean, bugs could be an issue… if I were you, I’d concentrate any apologetics for that Cheers.
Also, add a comment on the capacity / ideas to emulate existing sound modules such as Clouds.
It’s already clarified I thought
Are you saying I should apologize more for bugs???
I will absolutely not do this. Never.
I did not see that then… I wasn’t even sure what documentation you meant in the OP. Apologies.
I should apologize more for bugs???
No, I phrased that badly… I just mean that new users SHOULD be aware that there are bugs. It doesn’t bother me hardly at all; however, it’s the sort of thing that customers can hate.
I will absolutely not do this. Never.
What do you mean? I’m not suggesting you talk about specific modules: only say whether the er-301 was designed with emulation in mind [I guess the answer is a resounding ‘no’?]… make sense??
Phew! I thought you were suggesting talking about specific modules. I realize that some users are interested in creating emulations which is totally awesome. I just don’t feel right having it as a selling point in my copy or documentation.
As for listing the capabilities of the ER-301, I want to describe them honestly and succinctly to the prospective buyer but I’m still trying to figure out even how to do that. Not only has it been a moving target but it’s so context dependent and even kind of risky. Take the simple question of how many samples can you playback simultaneously. I could quote a number based on how many Raw Players you can have running but then I would need to include caveats about sample rates, how you can’t change the playback rate except in integer multiples, you will need to leave some overhead for whatever control structures, mixing and filtering you might need and so on. So it is not trivial and not at all clear that it will be any better than just looking at what existing users have been able to accomplish.
Oh, there’s a thought: How about showcasing user creations (both units and patches) in your advertising? And then with these examples you can list how much CPU is consumed. It would make for a much more natural explanation of processing power.
At the risk of going slightly OT and possibly laying some perfectly unreasonable expectations at Brian’s feet , my hope for the ER-301 as the firmware approaches 1.0 is that it will be regarded as a fantastic platform for creating new modular instruments and effects. Or, if you’re not into building instruments, then a platform where you can experience unique creations - both from O|D and the community, and use them to create music.
I don’t think that’s ever been stated as a design goal, but I do see it as being on a solid trajectory to achieve this purpose, with many things already possible and demonstrated by the excellent builtins as well as some of the cool and unique custom units people have uploaded - even before the firmware reaches 0.5.
One of the neatest aspects to me is the multi-level paradigm. You can just take an existing unit and use it to make some music. Or you can combine multiple units in the UI layer to achieve something new and different. If you like, you can dip into the Middle Layer for direct patching of DSP objects and even deeper customization. And hopefully someday, the most ambitious will be able to create new DSP algorithms with the SDK that will be used for new Units and in turn new unit presets and chains.
Framing it up that way, I think emulation could be looked at as more of a path to learning about DSP and how the ER-301 works rather than some kind of reason for buying the module.
OK, I guess that’s really just me rambling/musing. Maybe there’s a spark for some kind of market positioning in there somewhere. Or not.
I definitely agree here, for me it is a real positive if there’s a balance between sufficient factory-supplied / default units and functions, for those who want to patch their own visions from pre-supplied tools, and the ability to dive deeper for those who wish to code.
It would be great if those in the former group could benefit from those in the latter (who wish to share) as well. I think this would mean making it a little simpler to transfer custom units together with any required resources (eg samples) somehow. I’ve got lost on how to do this as we’ve gone from 3.x to more recent 4.x firmwares, so have some catching up to do.
I’m probably in the group of users that generally wants to patch and make units out of factory units, and try out others’ creations. While I can code a little, it’s not what I bought the ER301 for. From my perspective, I do think a few more factory units would be useful to more casual users (I do note that many of the units I think would be useful are already on the feature request list I think).
that’s interesting Joe. I mean, I see it more like a mini modular system in a computer that a. you can feed cv. b. is hardware, and c. very advanced users can program in C+
Creating new modular instruments / effects, then, would be the wrong from of mind without learning code