Question about gen~
I've been enjoying gen~ a lot
And that's mostly because there are alread high level modules available like phasor , cos , etc...
When you have a look at reakor core , there are only a handfull of basic modules and from these everything is build , from phasors to cosines to gorgeous sounding zdf filters
Different classes (core macros ) are provided for envelopes , trigonometry , higher level math functions etc...all build from these low level modules .
These are the fundamental lowest level classes : Math , Bitwise, Flow, memory , Scoped bus and Bundles
My question is , how come that gen already has these higher level modules like phasor ,cos, noise, etc .
Is it because these classes already exist in c++ ( which gen automatically translates to ) ?
the classes don't necessarily already exist in C++, where gen~ specific development was concerned, but Graham Wakefield, the creator of gen~ did choose C++ to develop it, for certain ways in which C++ suited the purpose ideally, which you can read about in this article a bit:
although, i'm sure C++ classes DO exist that can help someone like Graham, it's likely Graham took much of what can be learned from the general knowledge of DSP out there, in order to become an expert, himself. this knowledge base has been transforming collectively to go from elite institutions like Stanford:
and other 'advanced' sources of learning:
to public websites that collectively archive many techniques like musicdsp:
as well as the open-source code of environs like PD and SuperCollider.
it's likely that the developers at NativeInstruments are also just as savvy from this collective archive of general DSP knowledge.
in other words, yes, there are C++ classes to help, but it's likely Graham didn't just use one specific C++ library, but an entire lifetime's worth of experience in the field, in general:
reading the 'GO' book:
can also show how Graham has knowledge that can explain the math behind things well beyond any specific library/API. Although examples are specific to gen~, things are explained so that if you write externals or write lower-level code to extend environs such as SuperCollider or PD, or write VST/AU plugins, where you can have control, sample-by-sample over digitally processing audio(often delivered in 'blocks' of samples through what's called a 'performance routine' at the C or C++ level), you can easily translate the algorithms in the GO book, to those 'external/plugin-writing' APIs as well.