Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] UDO local sr

Ah, brilliant!
I just saw the flurry of emails connected to the code submissions and it
said something about not allowing a-rate, but that was likely a
misinterpretation of mine.

I will try to build and test to see if my scenario seems to work as I hope.

Thank you!

Regards,
Anders


On Wed, Mar 20, 2024 at 10:51 AM Victor Lazzarini <[email protected]>
wrote:

> Hi Anders,
>
> There is now an undersample opcode to go along with the oversample. I am
> not sure what you mean about 2., it does allow
> a-rate opcodes.
>
> best
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 20 Mar 2024, at 08:55, Anders Genell <[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.
> > This is mainly for Victor Lazzarini,
> >
> > I saw you added code in a PR to implement local sample rate in UDOs
> which I think is absolutely fantastic.
> > It seems there are two limitations that I really hope could be addressed
> in the future:
> > 1. The code allows for upsampling but not for downsampling
> > 2. The code does not allow for a-rate opcodes
> >
> > The use case I am hoping will be possible in the future is when having a
> reasonably high global sr (say 48kHz or even 96kHz) where I would like to
> apply relatively narrow band filters with center frequencies at say 20Hz,
> 25Hz 32Hz or the like. Such filters tend to be somewhat unstable at such
> high SR if they also need to be reasonably steep, and by downsampling
> before filtering a better result is often achieved. This is commonly done
> in signal processing for analysis in e.g. Matlab or GNU octave.
> > The idea is e.g. to be able to manipulate individual bands, like in the
> pvs group of opcodes, and combining the individual bands back to one signal
> afterwords, so just docking global reduction of SR would not be a viable
> route, unless of course starting several instances of csound and using
> channel opcodes to combine everything in the end.
> >
> > Would this be a possibility in some future iteration of the newly
> implemented code?
> >
> > Regards,
> > Anders
>