i've just started exploring gen~ more deeply and take a look at code export.
if i'll build a gen patcher using reference to buffer~ objects should i implement on my own the relative buffers in the exported C++ code?
For the near future, the use of buffers is something which you will need to be responsible for. In the coming months, we might find time to point developers to some resources for how they might consider sound file and buffer integration with code export, but we're considering that your responsibility for the time being.
My advise to use 64-bit Data operators instead of referencing buffers for the tasks of generating wavetables for example. To read/write from buffers Cycling '74 should implement interpolated playback functions inside of gen first of all.
yes, @DAVEYC, see the 'data' op in gen~(or look up the delay i made here in my gen~/sharing-is-for-asswipe series for an example of usage), it can work like an array of memory internal to gen~ with no external buffer~ required... (but Ruslan must have no clue about the 'sample' op in gen~, among others, because it does the interpolated-playback he's talking about, just fine, and cycling74 have already added it :p)
This missing buffer~ code-export was to be expected. If c74 helped you export code for buffer~, that would mean access to waveform viewing, different-file conversions, so much more than anyone here using gen~ probably could handle on their own, but also so much more than is worth handing out in a free code export, muahahahahaha! >;D
just trying to scare everyone who wants to do less work, into thinking they'll have to do more. i bet c74 are actually thinking about this... don't mind-me/worry :)
Thanks RAJA for the tip, I haven't noticed this sample operator, maybe the reason for this I wasn't too much into interpolated sample playback.
DAVEYC the tip with data operators inside gen works just fine. You can implement 'for' loops to write into the wavetables using GenExpr.