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

I pulled and built and had no errors in performance, so thank you for the
quick mending.
Now on to my original idea for a use case - I'll report back if/when I get
to the testing phase.

Regards,
Anders


On Sat, Mar 23, 2024 at 7:39 PM Victor Lazzarini <[email protected]>
wrote:

> ah, thanks for this. I hadn’t tried with more than one instance and you
> caught a bug in
> the deletion of the converters.
>
> Fixed now.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 23 Mar 2024, at 16:24, Anders Genell <[email protected]> wrote:
> >
> > I ended up compiling with gettext disabled as I couldn't figure out what
> package to install to fulfil the dependency...
> >
> > So I modified an example csd with an UDO containing an undersample
> command. It ran for the first instance in the score but then it aborted...
> >
> > <CsoundSynthesizer>
> > <CsOptions>
> > ; Select audio/midi flags here according to platform
> > -odac  ;;;realtime audio out
> > ; -iadc    ;;;uncomment -iadc if real audio input is needed too
> > ; For Non-realtime ouput leave only the line below:
> > ; -o sr.wav -W ;;; for file output any platform
> > </CsOptions>
> > <CsInstruments>
> >
> > sr = 48000
> > ksmps = 32
> > nchnls = 2
> > 0dbfs  = 1
> >
> >
> >         opcode Resample, a, a
> >
> >         undersample 4
> >
> > ain     xin                     ; read input parmeter
> > aout    init 0                  ; initialize output
> > aout    =  ain                  ; simple tone-like filter
> >         xout aout               ; write output
> >
> >         endop
> >
> >
> > instr 1
> >
> > ihar    = int(sr/2/p4)          ; maximum possible number of harmonics
> w/o aliasing
> > prints  "maximum number of harmonics = %d \\n", ihar
> > kenv    linen .5, 1, p3, .2     ; envelope
> > asig    buzz  kenv, p4, ihar, 1
> >
> >
> > aout Resample asig
> >
> >         outs  aout, aout
> >
> >
> > endin
> > </CsInstruments>
> > <CsScore>
> > f1 0 4096 10 1  ;sine wave
> >
> > i 1 0 3 100     ;different frequencies
> > i 1 + 3 1000
> > i 1 + 3 10000
> > e
> > </CsScore>
> > </CsoundSynthesizer>
> >
> > UnifiedCSD:  testlocalsr.csd
> > Elapsed time at end of orchestra compile: real: 0.000s, CPU: 0.000s
> > sorting score ...
> >         ... done
> > Elapsed time at end of score sort: real: 0.000s, CPU: 0.000s
> > --Csound version 7.0 (double samples) Mar 23 2024
> > [commit: 4ac0d3eb4a1c771deaba9f681dc48e5732935806]
> > libsndfile-1.0.28
> > displays suppressed
> > sr = 48000.0, kr = 1500.000, ksmps = 32
> > 0dBFS level = 1.0, A4 tuning = 440.0
> > orch now loaded
> > audio buffered in 256 sample-frame blocks
> > ALSA output: total buffer size: 1024, period size: 256
> > writing 512 sample blks of 64-bit floats to dac
> > SECTION 1:
> > ftable 1:
> > new alloc for instr 1:
> > maximum number of harmonics = 240
> > B  0.000 ..  3.000 T  3.000 TT  3.000 M:  0.44296  0.44296
> > maximum number of harmonics = 24
> > free(): double free detected in tcache 2
> >
> > csound command: Aborted
> >
> >
> > On Wed, Mar 20, 2024 at 10:06 PM Anders Genell <[email protected]>
> wrote:
> > Thanks, I’ll install libintl and see if things clear up.
> >
> > Regards,
> > Anders
> >
> >> 20 mars 2024 kl. 19:41 skrev Stephen Kyne <[email protected]>:
> >>
> >>  WSL should work. I use the ubuntu image to test linux builds. You
> need to either install libintl or else disable it's usage via USE_GETTEXT=0.
> >>
> >> It shouldn't really be failing as we have code to test if it's found
> but it seems to be a bug that was introduced in the last few months. I'll
> try and take a further look.
> >>
> >> Stephen
> >> From: Csound-developers <[email protected]> on behalf of
> Victor Lazzarini <[email protected]>
> >> Sent: Wednesday 20 March 2024 17:08
> >> To: [email protected] <[email protected]>
> >> Subject: Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] UDO local sr   I really
> don't know, this branch was started off develop last Saturday. There has
> been a lot of change in the build system and it might have broken people's
> builds. OTOH the CI builds are passing.
> >>
> >> Stephen, do you have a suggestion?
> >>
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >>
> >>> On 20 Mar 2024, at 16:04, Anders Genell <[email protected]>
> wrote:
> >>>
> >>>  *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
> >>>
>
>