PlanetZ forums - scopeusers.com

Hi,

I have not been using the DynVoicesOfParent that much in my devices, since it unable unload 100% of the DSP power - infact its more like 50%. Lets say I have a device with 6 algorithms, each using around 600 clock cycles - combined 3600 clock cycles and thats equals the power of 3 DSP 21065L. I have maybe 200 additional clock cycles for administration modules and if I choose to combine all the algorithms (so you could choose the algorithm you want within a single device) and use the DynVoicesOfParent for DSP optimization, I'll get the following :

(5 * 600) * 0.5 + 600 + 200 = 2300 clock cycles (2 DSP 21065L)

But if each algorithm was separate devices. I'll get the following :

600 + 200 = 800 clock cycles (0.67 DSP 21065L)

Does anyone know how to improve the DynVoicesOfParent module? Or another approach, maybe?

Kind regards
Martin

So what you're saying is that for your particular device, using DynVoicesOfParent needs 1500 CCs in overhead?

That's obviously a big waste.

I might have a suggestion. Posting an SDK question in another thread made me think about how Dynatube handles multiple cabinet choices.

In DT, you actually choose what module to load via a scroll-bar window. The workings of this is pretty much transparent to the user. I.e. there is actually a bypass device called "None.mdl" hidden in the SFP-system folders.

MAYBE such an approach could spare you the use of DVOP, or at least restrict it to handling a lower DSP-taxing module (i.e. not the whole device, just a device-handle)?

MAYBE this could be handled by the push of a button (or whatever) instead of the scroll-bar approach used by DT? Basically whatever would float your boat

If you are worried about other developers interfacing your various modules, then MAYBE you could use some technique related to "scopelock" (http://www.planetz.com/phpBB2/viewtopic.php?t=24430) to secure your host device exclusive access.

Warp69 wrote:I have not been using the DynVoicesOfParent that much in my devices, since it unable unload 100% of the DSP power - infact its more like 50%.

I've seen that behaviour here as well, where nowhere near as much as 100% is unloaded, but I've also been able to achieve the 100% unload with the DynVoicesOfParent module.

I've made several stereo effect insert devices that unload the right side from DSP when they're toggled to mono (MCCY has been doing that for ages). On those devices I'm getting about 95% unload on the RHS.

I'd like to know more about this subject.

From my experience it behaves like this :

- sync modules, which don't use the pci bus, are fully unloaded.
- sync modules, which use the pci bus aren't unloaded
- async modules beside controls are usually unloaded, but not always
- midi voice modules aren't unloaded

cheers,
Wolfgang

my rule is:
never use IFs!

although they are async they suck up the dsp load like hell.
I prevent them whereever i can.

just a little tip, which can make a drastic difference.

... but.. but.. what IF ?

if IF then......

IF it wasn't needed (at least for certain tasks), you wouldn't have it in your logic folder.

btw, there's a sync IF module available from Stecki or DSPDEV. I can't remember who made it, but I've got a feeling it was Stecki.

btw2, thanks for that info Wolf, it's very helpful.

I have checked out many of the "sync" DSPDEV atoms, but when checking them detailed you will realize that they are faulty to a certain degree.

you can check this out by attaching a wave editor while running scope sdk and backcheck the processing at sample rate offline, if it does what it is supposed to do.

IF I remember right the sync IF module isn't so light on DSP, but I'm sure it's got a use. Maybe for making a tight counter logic based sequencer circuit or something like that.

yeah i guess if you use one or two, you won`t run into bigger problems.

But I am working on a device that had around ~70 IFs inside, and at the end I wondered why the device was 3 times as heavy as before.
so I checked out every module loading it multiple times to see which atom caused the heavy dsp util. and on this particular device it was the IF module.

its a bit strange because the if shouldn`t affect sync dsp power. But actually it does. Most other async stuff doesn`t affect the dsp hit.

So I try to prevent using it as much as possible.
But everyone should decide for his own....

BTW I talk about the cw IF atom that can only be used with async stuff.



but regarding warps case, wolf have given the hint, that the host based memory stuff like delays don`t unload perfectly....(didn`t check this out) and a quality reverb is always build from many delays surely.
that may really be the cause in warps case.

Yep, seemingly some of the delay modules use dsp up to a certain delay time, then cpu via pci for anything above that delay time, which I didn't really lock onto until someone mentioned it off list. No doubt it's mentioned in an nfo file that I just forgot about (I read them all at one point).

wolf wrote:From my experience it behaves like this :

- sync modules, which don't use the pci bus, are fully unloaded.
- sync modules, which use the pci bus aren't unloaded
- async modules beside controls are usually unloaded, but not always
- midi voice modules aren't unloaded

cheers,
Wolfgang

Nice information, since Im using alot of modules that use the PCI bus - delay modules. That explains alot.

Cheers

<~Shroomz~> wrote:Yep, seemingly some of the delay modules use dsp up to a certain delay time, then cpu via pci for anything above that delay time, which I didn't really lock onto until someone mentioned it off list. No doubt it's mentioned in an nfo file that I just forgot about (I read them all at one point).

Thats correct Shroomz - You'll get a minimum delay of 194 samples with the PC delay modules, but if you combine that module with DLEXTM1 module it will ude the DSP memory for the first 194 samples and the PC memory via PCI bus for the rest.

Cheers

voidar wrote:So what you're saying is that for your particular device, using DynVoicesOfParent needs 1500 CCs in overhead?

That's obviously a big waste.

I might have a suggestion. Posting an SDK question in another thread made me think about how Dynatube handles multiple cabinet choices.

In DT, you actually choose what module to load via a scroll-bar window. The workings of this is pretty much transparent to the user. I.e. there is actually a bypass device called "None.mdl" hidden in the SFP-system folders.

MAYBE such an approach could spare you the use of DVOP, or at least restrict it to handling a lower DSP-taxing module (i.e. not the whole device, just a device-handle)?

MAYBE this could be handled by the push of a button (or whatever) instead of the scroll-bar approach used by DT? Basically whatever would float your boat

If you are worried about other developers interfacing your various modules, then MAYBE you could use some technique related to "scopelock" (http://www.planetz.com/phpBB2/viewtopic.php?t=24430) to secure your host device exclusive access.

Thank you - Im looking into it right now.

Cheers