You could share your method with the community.

Thanks, it is on scholar.google.com just search for Ruslan Yusipov. There will be a paper Compositor - the bottom-up approach.

What I would like to add to a subject for those who are using exportcode and would like to produce a paid android app for example is that it is first needed to compile using bionic linker/loader because it is licensed by BSD and not GPL as original gcc library. Another solution to the problem of abscence of main() function is android_main for this regard. The discretizator is a part of a shared library I produced and I need to set a task of counting with 45 MHz speed as a sub routine of a device processor. So the main loader should consist of function for counting at 45 MHz as a multiple of main processor speed. That is not the best solution, but the only solution for app on the phone. If I will have a clock device running at 45 MHz on the board I will produce the needed result without any subroutines, just by using device clock count variable as I know this. The difficulty is to find out the prebuilt board with such specifications and clocks running. Another problem is to have signal downsampled to a audio device rate for audio playback (if needed) after main algorithm counted all discretization bands at 45 MHz.

There is no main() in the exported code because it is expected that the code will be embedded within another project, which could be an application (providing its own main()) or a library (such as an AU/VST plugin, whose loader will have a main()).

Graham, as you see my problem insists that I use quantum interpolation discretization method named in aforementioned paper. I don't need to use FFT. I need direct access to processor cycle per second count speed and apply my method of discretization using v12 engine. This way all 12 pipes will work instead of one pipe, which is crucial for fast speed mechanics operation.

Could you, please, post an example of main() function code for this task and variables adjustment?

In addition, I would tell that v12 engine according to my research is an open-circuit and according to an estimation all other engines other than v1 is impracticle without quantum interpolation.

Moreover, if you wish to know a complete truth in this paper I also found a method for quantum approximation. And this could be implemented in Gen~ by a common good will for operation of Gen~ module without DAC~ completely. (I mean that it is a replacement and a fast approach for FFT) and if you wish to market it you should name my credentials named in aforementioned paper.

I'm not really sure what you are asking, but generally what you would need to do is write a simple program that can connect your audio hardware to the code generated by gen~. Perhaps using the RtAudio or portaudio libraries, for example.

Your paper is intriguing but I admit I can't understand the logarithmic spiral for spectral analysis, nor the quantum interpolation/approximation. I'm not sure where FFT fits in, I'm having a hard time understanding what you are asking, sorry.

Hi Graham,

The spiral is used for stochastic sonogram writing in my software Compositor Pro v2. All technologies in the paper are already implemented in current software builds. What I'm trying to achieve is to lock the parameter operation not to audio hardware but to main CPU cycle per second speed. I see that in Linux the maximum speed one can achieve with clocks is about 1MHz, which is not sufficient for my operation. I really need to implement it on hardware with 4GHz clock speed, instead of regular FFT of maximum 192kHz sample rate. So for this I need to operate on a UNIX level rather than Linux one. But I suspect there will be no possibility to compile C++ gen~ exported code for use with UNIX, because as far as I know C language was written specially for it and C++ is a higher level hierarchy.