you’ve said this a few times already; we’ve responded by pointing you at things like hardware teardowns, technical documentation, code repositories, anecdotes, and an entire forum full of thousands of people (including the device makers!) ready and willing to answer any specific questions you might have. i can’t agree that the function of “norns” is insufficiently explained by its product page ( which proceeds from poetic to highly specific in a couple of screenfuls, and includes data such as processor and codec model that is often missing for similar devices) or its official documentation page (which goes into more depth, links to more resources, and is about as dry as anyone could want. it’s also open-source…)
there is obviously some poetic language used around monome devices; that is because, like other musical instruments, these are aesthetic works and not just technical tools, so their description broadcasts the dreams and desires of their maker. clearly the language can have different effects on different people (another characteristic of aesthetic objects), but in the end there is also a goal of clarity and accessibliity that we work hard to deliver, in parallel. that’s why norns has an accessible scripting layer and web-based IDE, why it is open-source, why we spend so much time on studies and answering forum questions, and so on and on. of course it is not perfect and you probably have valid criticisms.
i’d be curious to know what you tried, and what didn’t work (apropos of finding information) so that we could maybe improve some aspect of that. but instead i’m hearing the same one-note criticism, which i can no longer take very seriously. you are annoyed by product hype in general and perhaps by monome’s website/language in particular; fine, but please consider your point amply made, and head over to the “norns on rasbpi” thread for a very active discussion on how to run the stack on $100 in DIY hardware, if you are interested in the functionality but are repelled by cost, branding, design and/or community. (or indeed, just stop thinking about it and buy a truly sick looper pedal instead - i recommend the boomerang III which will set you back about 5 hundo.)
anyways, moving on…
Eventide H9, Strymon Magneto,
microprocessors in my house
Teletype
ER-301
these are bare-metal devices. developers take advantage of more-or-less high-level frameworks to ease development, and some of these devices are hackable, but in general they aren’t designed to have their core functionality drastically altered in the field.
Nebulae
this is a computer running linux and is more what i’m talking about. (IIRC it literally has an Rpi board hanging off the bottom, HDMI ports and everything.)
microprocessors have been ubiquitous for a long time. we tried a hackable bare-metal audio hardware platform (aleph) but it didn’t work out too well - largely due to my failings as a part-time SDK architect. but fundamentally it’s also hard to deliver an environment that is efficient enough to run on a stripped-down processor, and also accessible enough for people to customize. aleph audio side was way too far in the low-level direction. architecting a great abstraction layer that is usable is a ton of work and necessarily quite opinionated, so it really has to be a passion project. (some great examples in recent memry include peter blasser’s Shinth and the ER-301.)
(but man, i still really like the aleph architecture. blackfin is a great processor and it really does feel different than even a stripped-down linux - boot to making sound in a few milliseconds, 1-sample latency - and i think it was/is a good idea to have a second small processor on there to allow easier hacking in the musical-logic domain. finally i thought it was neat that aleph could contain an arbitrary number of DSP firmwares and hot-load them at runtime. if strymon did that…! [well… they would have fewer products i guess.] it’s just too freakin hard to develop functionality for it in one’s so-called spare time.)
there’s a relatively recent thing going on, where people actually are using full-blown OS stacks (linux - like, debian linux) to perform domain-specific tasks in more-or-less customized hardware. there are obvious benefits for both users and developers, compared to e.g. working on SHARC code like Strymon does - and there are definite disadvantages. it’s an interesting phenomenon b/c the devices don’t need to be functionally contstrained to the extent that they are by hardware - your Nebulae could be a perfectly good network router, media center, edge computing node, or whatever, if it weren’t stuck in its box. the overhead of linux also tends to shave some efficiency off the design. so it really does raise a lot of hard questions (for me) about efficiency and footprint.
but when considering effciency, you can’t ignore economies of scale. it would be great if we could pick and choose the components and peripherals we need to be populated for a specific project, with no operational overhead - e.g. environmental impact of capacitors is not insignificant. [btw, i’ve recently seen some interesting work in the direction of “modular silicon,” mostly for rapid proto but also for product.] but, there is at least some benefit to standardization as well. so it makes some sense to me to base designs of off rpi compute module, teensy, feather, &c - not just because this allows smaller-scale development, but because development cycles have their own material / human / energy costs.
