3 ms·
I wasn't trying to belittle the complexity or versatility of audio software at all. For brevity's sake I didn't mention other input/output formats, because my p
by guscost 9y ago
I wasn't trying to belittle the complexity or versatility of audio software at all. For brevity's sake I didn't mention other input/output formats, because my point isn't that the domain is limited to "stereo" or "audio", but merely that it is a specialized domain.
> Ignoring evidence in front of your face
Do you have an example of a complex UI built entirely with Reaktor?
By the way it looks incredible, I've owned an old version for years but never tried it. Is it really that much better than SuperCollider once you get into experimental stuff? I'm really surprised to hear that it goes all-in on the interface and doesn't have any "write code mode" unlike like most graphical programming environments. Users are asking for that, of course:
https://www.native-instruments.com/forum/threads/my-requests-part-3-core-cell-programming-language.105833/ https://www.native-instruments.com/forum/threads/my-requests...
- anigbrowl 9y agoYou can download a play-only version of it I think, I'm not on my desktop to check rn. I too would like a code mode, but check out Flowstone and its earlier incarnation which was called synthMaker. Current version uses Ruby, previous version allowed code in C and assembler but I'm guessing that might have been hard to bulletproof. I'm certainly not against any code, it will always be important (I like assembler too believe it or not). But I think it's really important for IDEs to develop good structural tools. I think a lot of the resistance to flow-based programming is from IT people who kinda want to stay in their department, just like there was resistance to software from ASIC programmers, resistance to high level languages from low-level programming experts and so on. People are always wary of a new level of abstraction, partly because it involves a loss of control I think.
- guscost 9y agoCool thanks, I'll check out Flowstone! And I agree with all of your second paragraph. I'm probably still going to be skeptical of any "general purpose" flow-based IDE, but who knows, as programming matures over the next century we might eventually have a good grasp on the similarities between domains, and how to design better and/or visual tools that work in many domains. My theory could be totally wrong too.