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

Re: [sc-dev] Towards SC 4

Forgot to add - in the mentioned MIDI data performance problem, it was NOT obviously caused by any VM or language related things, apart from possibly function call overhead (which would not be greatly improved by using LLVM anyway).

On Wed, Dec 4, 2013 at 12:39 PM, Scott Carver <scott@xxxxxxxxxxxxx> wrote:
A few notes - 

The last time I did any serious profiling of the sclang VM, the biggest costs were not necessarily in places that would obviously be improved by LLVM or doing JIT tracing type things. If SC performance is an issue, it would be interesting to know WHERE/WHY it's an issue, and then look at targeted optimization of those specific cases. I think SC as a whole would get much more by simply (1) teaching folks some basics of profiling tools, (2) compiling a big, sorted, and voted-on list of bad-performance cases, and (3) slowly and boringly working down the list. The magic bullet solution is tempting but, for example, the only real sclang performance problem I've had in recent projects was related to 32 channels of uber-high resolution MIDI.

My 2¢ on sc4, in priority order:

- real debugger (this is doable currently, maybe two person-weeks of work on the VM, and a similar amount of work on the IDE to support)

- build SOLID interprocess communication between server/lang/ide (chrome runs every tab and plugin in a separate process, and it's completely transparent and performant)

- Server introspection (I should be able to programmatically query ins/outs of all ugens in a synth, view detailed CPU usage, etc. 90% of my (and probably everyones) sc problems are related to synths not doing expected things / blowing up / using too much cpu. Let's make those problems go away.

- Taking the CV class (and maybe the most recent Responder refactoring) as a basis, and build a robust general signals solution for connecting UI, synths, buses, data. Connecting UI/controls to synths easily and elegantly is one of the hardest and most annoying things for new users I think, and doesn't really get much more elegant if you know what you're doing.

- Proper npm-style package manager. Ach. (Been working on this for ages)


On Tue, Nov 12, 2013 at 4:38 PM, Nick Collins <clicksonnil@xxxxxxxxx> wrote:
> 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/