[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Towards SC 4

> Speaking from the almost total ignorance. Could we not make a special kind of loop over the block size?
> audio = VerySpecialLoop.ar(in, { arg inBlock, i;
>     inBlock[i] = one sample.
>     ...
> });
> and translate the code within that special loop into a simple set of low level primitives for operations and buffers which could be efficiently implemented like shaders?
> (you asked crazy and groundless ideas right?)

This would be possible if there was an SC to LLVM intermediate code translator. Non-trivial, but if LLVM is the backend, perfectly possible. Andrew Sorenson has the most experience here for audio programming languages I know of, though there is nice stuff for luaAV too I believe. 

Anyway, I guess I'm certainly interested in an inherent multi-rate signal processing system for SC, and had been thinking along the same lines as Jonatan on different sections of the synthesis graph at different rates. This could also include a more flexible window overlap/feature-rate implementation for live analysis. 

Server separation has benefits, and whilst it has caused me angst in the past for machine listening systems, it is certainly possible to combine language decisions and audio response within the separated architecture (it works well for multi language frontend too). Perhaps scsynth3 could be kept for backwards compatibility even as sclanguage changes, and a parallelised multi-rate scsynth4 take on new workloads. 



sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/