MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

DU-INO: The Ultimate Eurorack Arduino Shield
MUFF WIGGLER Forum Index -> Music Tech DIY  
Author DU-INO: The Ultimate Eurorack Arduino Shield
ezod
Something new from Detroit Underground I think might appeal to the DIY set. Help us get to production and be a part of our open source project by backing us on Kickstarter!

DU-INO: The Ultimate Eurorack Arduino Shield

We'll be demoing the prototypes at Knobcon this weekend. Hope to see some of you there!
mxmxmx
...looks nice. but what's the point of that "FAQ", i wonder?

it's kind of flattering (to us), but fairly misleading for most everyone else. looking at the schematic, i, for one, don't quite see how the "most significant technical difference" is the dev-board form factor. as it, the reference to o_C mainly serves to insinuate that "DU-INO" is essentially similar but somehow more "ultimate", though not "quite as precise" (despite the fact of "using precision ADC and DAC circuits"). that doesn't strike me as useful information.

either way, there's nothing particularly creative about putting a DAC, OLED, and a bunch of encoders all on the same board (Omnimod, Xaoc Zadar, µTune ...), so no reason to single out o_C. why not just put up the specs in plain language?
ezod
The FAQ is literally where I am answering frequently asked questions. smile

o_C is singled out because nobody's asked how it differs from Omnimod or Zadar. Maybe it isn't quite hitting the point, but at least some people seem to look at o_C less in that vein and more as a "Teensy shield for Eurorack with apps" (and isn't that a little bit true?), so when I describe DU-INO that way with s/Teensy/Arduino it is common for people to ask if it's just another o_C. I guess I can see how coming at the FAQ without already having made that mental link, it can look like it's trying to make it for you, but that certainly wasn't my intent: I'd prefer people look at them as apples and oranges, because if they're "essentially similar" then o_C, with its Teensy, dual encoders, and better CV specs, is obviously more "ultimate" at a similar price point. lol

For what it's worth, the way I described it all weekend at Knobcon was that o_C is focused more on CV generation and processing (and is a better tool for that job), and that DU-INO is more of a general-purpose tool for control and modulation. I just lifted the FAQ reply from a Reddit thread where the question was more around specific features than essence. I've updated the FAQ on the Kickstarter a bit based on that.

In any case, I want to offer an accurate picture. What would be most informative in your opinion?

    * Discussing more the differences in essence and intended purpose?
    * A direct spec comparison? (I was avoiding that to avoid insinuating that they are similar.)
    * Just removing the reference to o_C entirely?

Cheers for your great work on o_C, by the way. applause
j450nn014n
Regardless of all that. I'm looking forward to it. I hope you get a few more supporters to make it happen. Good luck!
chysn
As a software developer with a hobbyist's interest in module firmware development, I keep close tabs on the state of this sort of module.

I'd say that your FAQ should be part of the sales pitch. We're interested in specifications, but maybe not comparative specifications. You're targeting a tiny niche of a tiny niche of a tiny niche of the musical instrument industry, so target us good.

I'm kind of surprised that people frequently ask about how DU-INO compares to Ornament and Crime. For reasons that, to me, defy explanation, a developer community hasn't emerged around Ornament and Crime. The original developers are generous with their knowledge, the codebase is well-organized, making the barrier to entry really low, and almost everybody has one. So you'd think that alternate firmware or new apps--or at least app extensions--would be piled up all over the place. But, no.

Why that gap? I think the big difference between DU-INO and O_C is that DU-INO is specifically marketed as a "do what thou wilt" sort of thing, rather than an existing system that happens to be open-source. Now that the hardware is done, and the funding is almost secured, I think that great effort needs to be put into cultivating a developer community.
pld
chysn wrote:
For reasons that, to me, defy explanation, a developer community hasn't emerged around Ornament and Crime.

Quote:
I think that great effort needs to be put into cultivating a developer community.

Methinks you're answering your own question -- building/maintaining a community takes effort, effort takes time/motivation/incentive/patience, etc. and will easily dwarf development. As you say, it's niches-within-niches, so having sustainable overlap between target audience skills and expectations, platform capabilities and platform developer interests, etc. isn't necessarily obvious. It was already a rare occurrence for a completely new firmware/project to emerge from the original one, and now there's Hemispheres, which probably already puts o_C in the upper percentile of OS projects in terms of reuse metrics...?

Specs -- what I like to know are things like latency, update/refresh rates, hard timing constraints or dependencies, FPU or none. Terms like "precision" are fairly meaningless without numbers (aren't the 328p's ADCs 10-bit?). In this case, it'd be useful to know whether the screen redraw affects the timing of other things, because that's where the rubber meets the road. But I'm not the target audience...
chysn
pld wrote:
Methinks you're answering your own question -- building/maintaining a community takes effort, effort takes time/motivation/incentive/patience, etc. and will easily dwarf development.


Sure, touché. Almost everybody who bought or built an O_C did so because of what it does do. The DU-INO needs to be sold on the basis of what it can do, and so the community goes from optional to critical.
guest
id like to add some personal experience here, as i think it might be helpful to the OP with their project. i released the microdec as my first product under openmusiclabs, as a reprogrammable effects box. it was kind of expensive for what it did, so i only ended up selling 100 of them, and i dont think anyone who bought one reprogrammed it. i even gave 5 of them out to audio coding friends of mine for free, and none of them did anything with it. in my case there were a number of things i did wrong. the biggest was writing all the examples in assembly (you almost have to, to get complicated DSP out of an 8b machine). you could write in C, and very quickly i came out with an arduino library for it, and added the arduino bootloader, but that still didnt bring any new developers. i guess id just like to echo what other have said, that audio dsp is a niche within a niche, and only 1 out of 1000 people will reprogram a thing. and those who really know what they are doing, will just build their own. things that make it more likely that someone will reprogram:

1. easy interface to program in (arduino level or easier).
2. clear and abundant documentation
3. a place to showcase new code
4. community support for questions and such

id say paul stoffregen has done the best job of this so far with his audio library for the teensy. the teensy also benefits from the fact that there are a lot of them sold, since they are cheap and can be used for any application. the worst example i can think of is the line6 tonecore development hardware. i was super excited when it came out, and then i looked at the toolchain and my eyes glazed over.
creativechaoscom
I've been doing product management and product marketing for small shops like Compaq, HP, IBM, and Microsoft for more years than I care to remember. The #1 tip I would offer you is to find someone who has a strong product marketing/ product management background and help you clearly define what it is you're doing for both yourself and your target audience which needs to be clearly defined and addressed.

Statements like "It's whatever you want it to be" aren't helpful. Don't assume that everybody else thinks like you and has the same level of imagination.

Product development is hard. That's why so few succeed at it. I wish you all the best, sounds like an interesting project.

Cheers,
Michael
robin87
Looks like a nice concept, but something in your description struck me as odd:

Quote:
...using precision ADC...


Quote:
...12-bit ADC hardware...


Sorry, but that doesn't sound right to me.. Maybe the schematic is outdated or I'm missing something, but passively offsetting and clamping the CV inputs before sending them straight into the arduinos ADC inputs is not what I'd call a "precision" circuit. And you won't get 12-Bit resolution either.

The frontpanel seems to suggests a -10 to +10V CV input range, so using the arduinos onboard ADC (which is 10-Bit) will leave you with a resolution of about 4,266 steps per semitone in V/Oct terms, which is about the opposite of "precision", I'm afraid.

I guess you should think about improving the CV inputs (lower input range, proper CV buffers, maybe some 12-Bit ADC like the MCP3208) or else adjust your product description accordingly. Right now it's a bit misleading, to be honest.

Anyway, I wish you the best of luck with your project.

cheers,
Robin
chysn
robin87 wrote:
using the arduinos onboard ADC (which is 10-Bit) will leave you with a resolution of about 4,266 steps per semitone in V/Oct terms


The bleary 0-five-hundred not-ready-for-math me thought 4,266 steps per semitone was pretty damn good. But for those of us in the U.S.A., that's 4.266 steps per semitone.
robin87
Oops, you're right of course. I still get that confused a lot. Funny how it's just the other way round for us over here.

Wouldn't have any complaints about that sort of ADC resolution though. smile
chysn
robin87 wrote:
Oops, you're right of course. I still get that confused a lot. Funny how it's just the other way round for us over here.


The world's pretty evenly split on this. I strongly suspect that the Space Alien Alliance would make first contact if only we'd come together on this... one... thing. I, for one, welcome our new decimal comma overlords!
j450nn014n
They've got 33 more hours to get a few more people signing up. I hope they get enough people. Here's the link again... https://www.kickstarter.com/projects/ezod/du-ino-the-ultimate-eurorack -arduino-shield
ezod
To those commenting on the ADCs: you're right, although it's the description that is out of date. I've corrected the 12-bit ADC reference (for which we originally had external hardware) to the 10-bit resolution of the internal ADCs on the AVR. This change was made early on to reduce cost -- even at the full CV range, the resolution and accuracy is fine for most applications involving digital CV reads (remember, you have the analog circuitry as well) -- and the description was not updated. Also note that you could just use one of the various Arduino or Arduino-compatible boards with 12-bit ADCs if you need the resolution.

I went with passive scaling and clamping rather than active buffering again to reduce cost: it's not quite as good, but the impedances are reasonably high everywhere and I can't really see it being an issue.

Frankly, in general, I see a lot of talk about CV precision in the Eurorack world, yet every device I've scoped has been wildly imprecise, and it seems like I've got scale and offset knobs on every input to compensate for it. I think I'll just stop using the word everywhere...
j450nn014n
ezod wrote:
Congrats on getting the DU-INO funded! Looking forward to it.
MUFF WIGGLER Forum Index -> Music Tech DIY  
Page 1 of 1
Powered by phpBB © phpBB Group