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

*localsr* branch, that is

On Wed, Mar 20, 2024 at 5:03 PM Anders Genell <[email protected]>
wrote:

> Just checked out locals branch and got a cmake error:
>
> "CMake Error at CMakeLists.txt:1093 (add_library):
>   Target "csound64" links to target "Intl::Intl" but the target was not
>   found.  Perhaps a find_package() call is missing for an IMPORTED target,
> or
>   an ALIAS target is missing?"
>
> I suppose I'm doing something wrong, the first of which may very well be
> the fact that I am building on the Windows Subsystem for Linux - that's
> just because I'm at work doing ordinary work stuff on my work computer - I
> can build on an ordinary linux system later...
>
> Regards,
> Anders
>
> On Wed, Mar 20, 2024 at 2:12 PM Anders Genell <[email protected]>
> wrote:
>
>> Ah, it was just arrays that were limited. Great!
>>
>> I'll be sure to install libsamplerate and will see what I can do with
>> regards to testing
>>
>> Readers,
>> ANders
>>
>> On Wed, Mar 20, 2024 at 2:10 PM Victor Lazzarini <[email protected]>
>> wrote:
>>
>>> Make sure you have libsamplerate for the best quality conversion.
>>> There’s a simple fallback converter, but Secret Rabbit Code is better.
>>>
>>> The limitations are:
>>>
>>> - can’t setksmps alongside it
>>> - can’t use a-rate or k-rate arrays (that may be possibly changed in the
>>> future).
>>> - if you use global arrays or bus channels it won’t work either. All
>>> access has to be
>>> through xin and xout, because that’s where the conversion happens.
>>>
>>> Testing is helpful, thanks for that.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>> > On 20 Mar 2024, at 11:27, Anders Genell <[email protected]>
>>> wrote:
>>> >
>>> > 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
>>>
>>>