That could be the case, I don't know off the top of my head. You should do what works for you in Max, and disregard the Pd code.

On 4 Mar 2022, at 01:21, Iain Duncan <iainduncanlists@GMAIL.COM> wrote:

*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

This is really one for Victor, but I figure it should be on the lists. I'm not sure whether I've found an oversight in csound~ for Pd, or I'm misunderstanding something. It looks to me like in the perform routine, csoundPerformKsmps is called before the values from the Pd in channels get written to the csin buffers. Wouldn't this introduce a delay of one vector? Or am I missing some reason this is not so? 

I just got audio input working in my max version writing to the csound input buffers before the csoundPerformKsmps call and this seems to be working fine. But I am using csoundSetSpinSample and csoundGetSpoutSample so maybe there is a difference there?

Thanks!

iain

I don't think it is, but I will check.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 4 Mar 2022, at 14:58, Iain Duncan <iainduncanlists@gmail.com> wrote:



Thanks Victor. I was more wondering whether this was a bug for the Pd version that I should fix. 

iain

On Fri, Mar 4, 2022 at 3:23 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

That could be the case, I don't know off the top of my head. You should do what works for you in Max, and disregard the Pd code.

On 4 Mar 2022, at 01:21, Iain Duncan <iainduncanlists@GMAIL.COM> wrote:

*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

This is really one for Victor, but I figure it should be on the lists. I'm not sure whether I've found an oversight in csound~ for Pd, or I'm misunderstanding something. It looks to me like in the perform routine, csoundPerformKsmps is called before the values from the Pd in channels get written to the csin buffers. Wouldn't this introduce a delay of one vector? Or am I missing some reason this is not so? 

I just got audio input working in my max version writing to the csound input buffers before the csoundPerformKsmps call and this seems to be working fine. But I am using csoundSetSpinSample and csoundGetSpoutSample so maybe there is a difference there?

Thanks!

iain

it's just the way it's implemented, buffering ksmps in as it outputs the last block of ksmps. The actual placement of performKsmps() does not matter in this case as you are buffering in and out, rather than waiting to to fill the spin before you empty spout.

As by default ksmps is different to the pd blocksize and don't even divide it wholly, this is the most generic/straightforward way to implement it, at the penalty of a ksmps block latency (not the pd blocksize).

I guess it is possible to implement it differently if ksmps <= blocksize by having two separate input and output loops inside a loop over the blocksize (incremented by ksmps)

for(n = 0; n < size;  n += ksmps) {

  for(k = 0; k < ksmps; k+=nchnls)

   // copy input

  csoundProcessKsmps();

     for(k = 0; k < ksmps; k+=nchnls)

      // copy output

}

but this only works if ksmps divides blocksize in whole parts, otherwise the code above will need to be modified to take account that spin/spout are only partly full/emptied when the dsp method exits.

Not wanting to go there, and also have to entertain the case of ksmps > blocksize, the current generic buffering implementation is a compromise. 

That's why I said you can just implement whichever scheme you prefer in your maxmsp object.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 4 Mar 2022, at 17:09, Iain Duncan <iainduncanlists@gmail.com> wrote:



Ok great, I'd be interested in hearing the answer. I believe if I'm understanding it correctly (and it is a bug) there should be an extra 64 sample delay of audio input.

At any rate, audio input is working now in the Max version, so that's something! Finally I have time to hack at it again.

iain

On Fri, Mar 4, 2022 at 8:29 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I don't think it is, but I will check.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 4 Mar 2022, at 14:58, Iain Duncan <iainduncanlists@gmail.com> wrote:



Thanks Victor. I was more wondering whether this was a bug for the Pd version that I should fix. 

iain

On Fri, Mar 4, 2022 at 3:23 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

That could be the case, I don't know off the top of my head. You should do what works for you in Max, and disregard the Pd code.

On 4 Mar 2022, at 01:21, Iain Duncan <iainduncanlists@GMAIL.COM> wrote:

*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

This is really one for Victor, but I figure it should be on the lists. I'm not sure whether I've found an oversight in csound~ for Pd, or I'm misunderstanding something. It looks to me like in the perform routine, csoundPerformKsmps is called before the values from the Pd in channels get written to the csin buffers. Wouldn't this introduce a delay of one vector? Or am I missing some reason this is not so? 

I just got audio input working in my max version writing to the csound input buffers before the csoundPerformKsmps call and this seems to be working fine. But I am using csoundSetSpinSample and csoundGetSpoutSample so maybe there is a difference there?

Thanks!

iain