Input buffer of type char*

[JonOsterman]

Hi,

I'm working on a VST plugin with an SDK which provides buffers of type char* as :

"]é òÞè–ñZéžòPê=óVëÆôºëõîë õ*ìöBîË÷ôð-ûõó¾þ‚öõ
Ç÷{›ö;(óx
Žðîþ¶ð¼þæð&þÇîQûì¬øÌéPöyç´ó’ æqò}çmó?çQôÖäÁòŽãxò9å‹ôcè÷©ëúŸí¢úþî²ú½ð‘ûò8û†óñû1õZüõXû
óªùWð ÷¥íÅõ�ë¨ôSëŸôPìIö‹ë*õ¼èaò¶æòð}æmðöçtñê`òeêáñkêvñ ìhòjîGôïaôï ô" (this is an example of buffer I can get)

which is first, completely weird and second, I don't know how to make it working with WDL-Ol's IPlug. Have you already seen something of this kind ? I would prefer not to rewrite the SDK haha

[Xenakios]

Well, doesn't the SDK say what kind of data is in the char* buffers? Obviously it's not text, as shown by your text dump of it. If I had to guess, it's 8 bit audio samples? (char being an 8 bit number type...)

[JonOsterman]

Originally Posted by Xenakios

Well, doesn't the SDK say what kind of data is in the char* buffers? Obviously it's not text, as shown by your text dump of it. If I had to guess, it's 8 bit audio samples? (char being an 8 bit number type...)

Yup that was it, an 8 bit audio sample, so I've made a DoubleToBuffer function and now it works like a charm.

[JonOsterman]

Well it works but it brings more problems than advantages, do you think that I could refactor WDL for char* buffers ?

[Xenakios]

Originally Posted by JonOsterman

Well it works but it brings more problems than advantages, do you think that I could refactor WDL for char* buffers ?

Plugins work with 32 or 64 bit floating point samples, so you are stuck with dealing with those. What are the problems you are having?

[JonOsterman]

Originally Posted by Xenakios

Plugins work with 32 or 64 bit floating point samples, so you are stuck with dealing with those. What are the problems you are having?

Thing is that I got my double *input;
Then I declare and malloc my char *out;

I call my convertDoubleToBuffer() which is

int AWM_VST_Plugin::convertDouble2Buffer(void* bufferIn, int sizeBufferIn, void *bufferOut)
{
int numBytes = 2; //BufferOut Nb bytes
long long int factorConversion_32 = ((long long int)1) << 31;
const int num_bits_conv_32_bits = 32 - numBytes * 8;
const float conv_32_bits = (float)(1 << num_bits_conv_32_bits);

for (int i = 0; i < sizeBufferIn; i++)
{
float val_float = (float)((float*)bufferIn)[i] * factorConversion_32 + 0.5f * conv_32_bits;
long long int val = (long long int)floor(val_float);

if (val >= factorConversion_32)
val = factorConversion_32 - 1;
else if (val <= -factorConversion_32)
val = (-factorConversion_32);

val >>= num_bits_conv_32_bits;//on 16 bits again.
((short*)bufferOut)[i] = (short)(val);
}
return 0;
}

(I've got another version for a 32bits output which doesn't work either)

And then even before using the sdk if I record my result in a wave file to test it I can hear my stream in the background and over it some random noise (and my file is twice as long as the stream I recorded originally)

[Xenakios]

Sorry, I am having a too hard time understanding what you are actually trying to do that I can't offer further advice. Maybe someone else can chime in...

[schwa]

Why is numbytes 2, if you are converting to 8 bits?

If I were converting a buffer of doubles to 8 bits, I'd just do this.

for (i=0; i < buflen; ++i)
{
  double v=dbuf[i];
  if (v < 0.0)
  {
    if (v < -1.0) v=-1.0;
    cbuf[i]=(char)(-v*SCHAR_MIN);
  }
  else if (v > 0.0)
  {
    if (v > 1.0) v=1.0;
    cbuf[i]=(char)(v*SCHAR_MAX);
  }
  else
  {
    cbuf[i]=0; // not necessary if memset(cbuf) upstream
  }
}

[JonOsterman]

Hi schwa,

I tried your loop but it gave me a Heap Corruption, so I might have misunderstood something :

- Can I assume that nFrames is the double buffer's size ?
- Maybe it's normal but nFrames takes values like 212, 33, 179 (which makes 212), 91, 121, 212, ... you got the point. Is it normal or could it be an ASIO problem or something else ?

EDIT : I solved the Heap Corruption, but my questions are still relevant if someone got the answers

[Xenakios]

Originally Posted by JonOsterman

- Maybe it's normal but nFrames takes values like 212, 33, 179 (which makes 212), 91, 121, 212, ... you see the idea. Is it normal or could be an ASIO problem or something else ?

nFrames is the number of 64 bit floating point sample "frames". The number of "frames" is the same no matter if the signal is mono or stereo etc.

What nFrames you get depends on the host. Some will always give you one number for that, some will mostly give you one number and occasionally something else and some hosts like FL Studio can give you very different numbers for that each time. You will just need to be prepared to deal with that. If your external algorithm uses buffer sizes that don't fit with the nFrames number you get in IPlug, you will need to yourself come up with some method to accommodate that. (Use a queue or ring buffer etc...)

[JonOsterman]

Originally Posted by Xenakios

nFrames is the number of 64 bit floating point sample "frames". The number of "frames" is the same no matter if the signal is mono or stereo etc.

What nFrames you get depends on the host. Some will always give you one number for that, some will mostly give you one number and occasionally something else and some hosts like FL Studio can give you very different numbers for that each time. You will just need to be prepared to deal with that. If your external algorithm uses buffer sizes that don't fit with the nFrames number you get in IPlug, you will need to yourself come up with some method to accommodate that. (Use a queue or ring buffer etc...)

Thanks, so it depends on how the hosts treat the data ? I'm working on that kind of solution at this very moment