4 ms·

I didn't expect this comment to get this much discussion, I should have been clearer. In the context of automation, the "robotic revolution" has already happen

I didn't expect this comment to get this much discussion, I should have been clearer. In the context of automation, the "robotic revolution" has already happened between the 4 industrial revolutions - basically, robots exist en masse already, we just don't call them robots. The majority of manufacturing and processing is already hyper optimized to only needing a few overseers to make sure the machines are running smoothly. When talking about the automation revolution, I think it's important to make the distinction between robotic tooling and autonomous robotic systems, even though they evolve from each other. The difference is when humans interface and at what abstraction humans can operate it on. Generally, tooling is constrained to an individual's output. Robotic augmentation is in it's own category as well (human activities being enhanced by machinery). Tooling is extremely useful, still has a lot of future potential and I don't mean to undermine work on new tooling. Just - usually when we look at robots, especially with the buzz around deep learning, we set the bar for problem solving at the level of autonomous construction because we assume, sometimes incorrectly, that optimizing our current tooling yields little efficiency benefits relative to the former.

megameter 5y ago
An example I know of that resembles the bricklayer problem is synthesis of human singing vocals into MIDI sequence data. There is now a history of products around that check off the boxes - one (Vochlea Dubler) debuted just last year - and every time, it demos well but the potential audience ends up rejecting it, because it does not really add what they thought it would add to their workflow. Even if the results themselves come out usable(already a wicked problem since the DSP has to deal with a multitude of recording scenarios while achieving low latency), users discover that they need to be talented at "singing like an instrument" if they want to play instruments by singing, which is a technical barrier, not an assistance to spontaneous creation. Practically speaking, they're better served creatively by button input tools that work top-down(e.g. pick a scale, then the keyboard only plays notes within that scale) since those define down the medium and therefore perform a creatively assistive function with a legible design paradigm(different scale = different sound).

megameter 5y ago

An example I know of that resembles the bricklayer problem is synthesis of human singing vocals into MIDI sequence data. There is now a history of products around that check off the boxes - one (Vochlea Dubler) debuted just last year - and every time, it demos well but the potential audience ends up rejecting it, because it does not really add what they thought it would add to their workflow. Even if the results themselves come out usable(already a wicked problem since the DSP has to deal with a multitude of recording scenarios while achieving low latency), users discover that they need to be talented at "singing like an instrument" if they want to play instruments by singing, which is a technical barrier, not an assistance to spontaneous creation. Practically speaking, they're better served creatively by button input tools that work top-down(e.g. pick a scale, then the keyboard only plays notes within that scale) since those define down the medium and therefore perform a creatively assistive function with a legible design paradigm(different scale = different sound).