Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] More Daisy help

yes, I would be surprised if that UDO pushes the Daisy.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 15 Sep 2025, at 20:08, Dave Seidel <[email protected]> wrote:


I commented out the pitchamdf statement and set the variable to the actual cps of the source signal, but unfortunately it still sounded terrible. It's hard to believe that the remaining code is over-taxing the Daisy. (My original code using the pv opcodes run just fine on the Nebulae -- but it may be an unfair comparison since the Nebulae runs Csound on a Raspberry Pi 3.) I'm going to play around a bit with your working examples and see how far I can push it.

On Sun, Sep 14, 2025 at 4:22 PM Dave Seidel <[email protected]<mailto:[email protected]>> wrote:
Thanks, I will try these things.

On Sun, Sep 14, 2025, 4:12 PM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
Ok, so I suspect that you'll get the pitch shifter working alright. I wonder if the pitchamdf is draining cpu cycles, it's a bit expensive.

Try running the pitchshifter without pitch tracking, just setting the delay time fixed to some small value like 50ms and see if it works.
In other words, keep the UDO but simplify the instrument, get the audio in, put it into the UDO and send it out, without any extra processing.

best
Prof. Victor Lazzarini
Maynooth University
Ireland

On 14 Sep 2025, at 19:48, Dave Seidel <[email protected]<mailto:[email protected]>> wrote:


Ah yes, sorry. I tried both the processing example and generative example and they worked on the Versio.

On Sun, Sep 14, 2025 at 2:43 PM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
What I was asking is whether the Daisy Csound processing example works in your system. If it doesn't then there is something else needed there. The example was tested and ran ok in the Daisy Pod.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 14 Sep 2025, at 19:29, Dave Seidel <[email protected]<mailto:[email protected]>> wrote:


Yes, the book example works fine on my RPi. On  the Versio/Daisy it is noisy, similar to the result I got from my original code. This is why I am now thinking that possibly something needs to change in the C code to work properly on this particular Daisy platform. So I will study the published Versio example (which is entirely C) and see if I can spot the difference(s). We may need different boilerplate code for Csound on Versio.

On Sun, Sep 14, 2025 at 2:22 PM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
and the Csound processing example, how does that do in your setup? Does it work well.

The delay line shifter code is fairly low in cost, so I would think it should run well. It should even allow for small ksmps/blocksize. I had a variable delay code running here with ksmps=8, and audio block size set to ksmps.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 14 Sep 2025, at 19:07, Dave Seidel <[email protected]<mailto:[email protected]>> wrote:


Identical to DaisyCsoundProcess, the only difference being the name of the file and the name of the included header.

On Sun, Sep 14, 2025 at 1:25 PM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
And the C program you used?
Prof. Victor Lazzarini
Maynooth University
Ireland

On 14 Sep 2025, at 18:18, Dave Seidel <[email protected]<mailto:[email protected]>> wrote:


Still haven't found my book, but I do have a (purchased) PDF of the Springer Csound book by Victor et al. This contains the same pitchshifter code along with the explanation.

(BTW, the window used in the book is a triangle. Any reason to prefer Hanningh over triangle?)

In any case, this pitchy shifter code doesn't work well on my Daisy either -- still a lot of noise overlaying the generated output. But this is a Versio, so perhaps it requires something different in the setup/initialization? Next step, I guess, is to compare the code in the Versio example in DaisyExamples to the boilerplate C++ code used in the DaisyCsound examples.

I've attached my header file with the Csound code in it. The same Csound code works just fine on my Raspberry Pi.


On Fri, Sep 12, 2025 at 4:19 PM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
I think the second pvsynth in this code might be pushing it
Prof. Victor Lazzarini
Maynooth University
Ireland

On 12 Sep 2025, at 20:18, Dave Seidel <[email protected]<mailto:[email protected]>> wrote:


Rory, this was running in Daisy?

On Fri, Sep 12, 2025 at 3:13 PM Rory Walsh <[email protected]<mailto:[email protected]>> wrote:
I've used ksmps=256 and fftsize=1024 and it's worked Ok for me. I've been using pvsmooth and pvsynth. Not very heavy stuff, but nice results all the same.

On Fri, 12 Sept 2025 at 20:11, Dave Seidel <[email protected]<mailto:[email protected]>> wrote:
Great, thanks very much! Still looking for the book... :-)

On Fri, Sep 12, 2025 at 1:56 PM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
Essentially this
https://github.com/csound/book/blob/master/part4/chapter13/13.12.csd

Prof. Victor Lazzarini
Maynooth University
Ireland

On 12 Sep 2025, at 18:41, Dave Seidel <[email protected]<mailto:[email protected]>> wrote:


Thanks, Victor. I'll try those things, though I already tried ksmps=256 and FFT size 1024 -- didn't work, but it did reduce the noise somewhat, so I think that reinforces your theory.

The delay-based approach might be fine, thanks for the suggestion. I know I have the book around somewhere, I just need to find it....

On Fri, Sep 12, 2025 at 1:17 PM Victor Lazzarini <[email protected]<mailto:[email protected]>> wrote:
Hi Dave,

this is probably because the Daisy can't compute audio in time for the interrupt.
It could be that the FFTs are too much for it.
There's a few things you could try:

increase ksmps to 256
decrease FFT size to 1024

keep ksmps at 128
decrease FFT size to 512

I have not yet tested spectral processing to see what the limits are. I can't do any testing at the moment because my Daisy seed is faulty, I'm waiting on a replacement.

An alternative to doing pvs-based pitch shifting is to use a delay line pitch shifter, which might just work ok in your case. Russell Pinkston's chapter in the Csound Book has an example you could use.

Otherwise I can send you some code.

best
Prof. Victor Lazzarini
Maynooth University
Ireland

On 12 Sep 2025, at 16:38, Dave Seidel <[email protected]<mailto:[email protected]>> 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.

Hi Victor,

I have a tiny project that essentially duplicates the DaisyCsoundProcess example, the only differences in the code being the changes names and the contents of csdText.

Here's the UDO I'm using, which works fine with standalone Csound. It takes an input signal and turns it into a stereo output  signal with a binaural beat. When it's executed on the Daisy, I can sort of hear the output, but it's very noisy. Is there anything in this code that you would not expect to work on the Daisy?

    opcode binauralize, aa, ak
      ain,kdiff xin

      ; take it apart
      fsig pvsanal ain, 2048, 2048/4, 2048, 1

      ; determine pitches
      ; kcent, kamp pvspitch fsig, 0.1
      kcent pvscent fsig

      if (kcent > 0) && (kdiff > 0) then
        kdiff /= 2
        krat1 = (kcent + kdiff) / kcent
        krat2 = (kcent - kdiff) / kcent
      else
        krat1 = 1
        krat2 = 1
      endif

      ; create derived streams with shifted pitches
      fsig2 = fsig
      fbinL pvscale fsig,  krat1, 0
      fbinR pvscale fsig2, krat2, 0

      ; put it back together
      aoutL pvsynth fbinL
      aoutR pvsynth fbinR

      xout aoutL, aoutR
    endop
<daisyCsoundVersio.h>