Software (plugin) based G3 possibility

[BobTheDog]

So what do you guys think the market for a plugin based G3 would be?

Basically like the G2 demo but more efficient, running as a plugin with sampling and other new features added.

[jksuperstar]

I think it's difficult to truly pull off, keeping a 96kHz sample rate, and allow for single sample tricks like feedback. Maybe if they had some damn good coders that could push a multi-core CPU, and ensure the threads get a dedicated core (or two) to themselves. They'd need to be able to lock down a chunk of the cache to act like memory to maintain any sense of predictability and dependability.

[BobTheDog]

[jksuperstar]

[BobTheDog]

Ok, split to a new thread for discussion.

[BobTheDog]

Locking the cache in any direct way running under a normal OS would cause lots of problems I would say, also most intel processors do not let you do this anyway, some allow you to prefetch data with instructions rather than touching it in yourself.

I must admit I have no experience of implementing audio code with a single sample feedback and the high performance work I have done in the past was all based on large sets of single core processors and divvying up work between them, feedback in these systems tends to be in the 2-5ms range so it was fairly simple just make sure each processor has calculated its stuff in within the time-slice and written the results to shared memory.


My knowledge of the internals of the G2 are limited I must admit, is it something like this:

Each slot runs on 1 dsp for the unexpanded version and 2 dsps for the expanded version.

Each voice is processed separately for that slot

There is some sort of directed graph set up from the module connections, this graph is processed for each voice for each sample time-slice. Samples are propagated through this graph with each module doing its stuff before passing and output samples on.

A sample that is fed to a module that has already been processed is saved away for the next time-slice.

Is this about right?

Cheers

Andy

[Blue Hell]

Andy, its best to think in patch parts ... which can be either in VA or FX area, and for a part being in VA it gets duplicated for each aditional voice. The the parts can be packed into DSPs, providing the sum of resources is <= 100% . So when you have one patch, with 25% in VA and 25% in FX and 3 voices active all four parts would fit on one DSP.

For the calculation ... I think there is a memory location associated with each output; all modules that need input pick it from such a memory location and all modules pruducing output store it into such a location.

I think that that for the G2 modules are executed top to bottom, then left to right (for the NM Classic it was rather arbitrary, based on which module was placed first (in time) (and with editing gaps would come up to be filled with modules placed later) making it nearly impossible to predict execution order).

[jksuperstar]

By "lock" I mean: don't allow the data to be removed from cache. So it's a difficult process that's fully up to the programmer: balancing instruction and data sizes, address of data (so related data happens to fall in the same cache line where possible), minimizing stack pushes & pops, and generally keeping unnecessary access to RAM (including debug portions of the code) out of the way.

The real problem to me, is that in the context of a general purpose computer, it becomes so difficult to ensure the resources needed are available on time.

But I've been looking at what could be possible, and came across some great sites with benchmark results, and info on L1,2,3 cache speeds.
http://homepage.virgin.net/roy.longbottom/cpuspeed.htm

More thought required...

[Antimon]

My personal guess on how the sound-making stuff in a G2 is implemented: each patch part is recompiled when you change something crucial (add a cable in a critical place or add a module), hence the moments of silence every now and then when you edit a patch. This means that Clavia will have been able to adjust the code after a user edit, so that feedback loops and similar stuff are handled optimally when and only when they are needed. I don't know how this may have been done... what I'm getting at is I think that the structure of the DSP code generating sound doesn't need to correspond exactly to the modules you see in the editor, and that all manners of tricks may be running in the background, fixing whatever timing problems occur.

Not that this means that you can do the same thing in an application on a general purpose modern OS.

It might be a good idea to preserve the notion of slots or patch parts in a G3 softsynth. All of a patch part or voice of such may be running on one processor, and the patch parts uses the likes of the NM's buses to communicate with each other (different patch parts possibly running on different processors). I am guessing that the timing on e.g. the inter-slot buses on the G2 is less tight than connections inside a slot.

ChucK manages to run many sound-making things in a modularized fashion, adding things on the fly (granted, using up a lot of power for just a dozen or two of oscillators and filters). Why shouldn't a G2 softsynth be able to do the same?

/Stefan

[BobTheDog]

Hi Guys,

JK : I understand what cache locking is, I just don't believe this would be a good idea in an os that can preempt your thread.

To be quite honest I don't see why you would need to do anything with the cache over letting the system itself sort it out.

Andy