[Csnd] Problem with linsegr when writing audio to table

[ST_Music]

I have an instr being triggered that uses linsegr. When output directly from that instr the notes can overlap & sustain. When I wrote that same audio output to an ftable then the notes cutoff & linsegr has no effect, it sounds pretty bad. Am I doing something wrong here?

This is a simplified ex. If played as is this sounds ok. If line 27 is commented out (outs aSig, aSig) and the line for instr 2 in the score is uncommented the problem becomes obvious (there will be a 3 sec delay).

<CsoundSynthesizer>
<CsOptions>
-odac
</CsOptions>
<CsInstruments>
sr = 44100
ksmps = 10
nchnls = 2
0dbfs = 1

gaNdx init 0
giFt ftgen 0, 0, -3*sr, 2, 0

  instr trig
iNote[] fillarray 60, 67
gaNdx = phasor(1/3)
kTrig = metro(2)
kNote = int(trandom(kTrig, 0, 1.99))
schedkwhen kTrig, 0, 0, 1, 0, .3, iNote[kNote]
  endin

  instr 1
kEnv = linsegr(0, .002, .6, p3, .6, 3, 0)
aSig = wgpluck2(.7, kEnv, cpsmidinn(p4), .2, .3)
        tablew(aSig, gaNdx, giFt, 1)
        // comment out below
        outs aSig, aSig
  endin

  instr 2
aFwd = phasor(1/3)
a1 table3 aFwd, giFt, 1
        outs a1, a1
  endin

</CsInstruments>
<CsScore>
i"trig" 0 32.2
// uncomment below
;i 2 3 32.2
</CsScore>
</CsoundSynthesizer>

Any ideas appreciated,
Scott

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        Issues · csound/csound · GitHub
Discussions of bugs and features can be posted here

[eduardomoguillansky]

Just skimming through the code. The main difference is that "outs" will mix the given signal, while "tablew" overrites the contents. You need to read, mix and write yourself in order to emulate what "outs" is doing

[Michael_Gogins]

I’m not sure I really understand what you are trying to do here, but when I uncomment the “i 2” line I do hear clicks. There’s a way to start getting a picture of what’s going on by using a sound editor.

I ran your example (actually, I modified your example by starting the notes at time 1 instead of time 0) and edited the resulting soundfile in Audacity, using options to show both a waveform view and a spectral view for each channel. Screen shot:

Zooming in on the anomalous section starting at 4 seconds (3 seconds in your original example):

The vertical lines in the spectral view correspond to clicks on the waveform. Zooming in even further:

Perhaps by looking at this you can figure out what is going on. There is one sample roughly in the middle of this view (at exactly 4 seconds, 3 seconds for your original example) that is discontinuous and is definitely what is heard as a click.

There is another click later showing another quite discontinuous sample:

If I run your example with ksmps=1 there are still clicks, so I don’t think they come from using a krate envelope.

Regards,
Mike

[ST_Music]

Hi Michael. Thanks for looking at this.

Yes, a good approach/suggestion, anytime I have these types of issues I use an audio editing program (I’ve posted many images here :)). That’s how I was able to determine the exact time clicks were occuring.

First, I apologize, I probably should have written a better “solved” post. As mentioned in another post, the issue with the initial code is that unlike linseg, linsegr is not properly recognized by tablew inside the same instr.

So when you were testing I’m assuming the clicks were caused due to the fact notes were being triggered two times per sec and the env release time was 3 sec (I purposely made it unnecessarily long). However, as tablew seemingly doesn’t recognize the release time there is no overlap from release time, the amplitude shifts instantly from one note to another causing a click.

The solution was moving the tablew to a seperate instrument & sending the audio to it. In that case, for whatever reason, the release time is then properly recognized. This approach seems to solve the problem(no clicks, linsegr release times recognized):

-odac ; -o/sdcard/click_test.wav sr = 44100 ksmps = 10 nchnls = 2 0dbfs = 1

gaNdx init 0
giFt ftgen 0, 0, -3*sr, 2, 0
gaSend init

instr trig
iNote[] fillarray 60, 67
gaNdx = phasor(1/3)
kTrig = metro(2)
kNote = int(trandom(kTrig, 0, 1.99))
schedkwhen kTrig, 0, .1, “preplay”, 0, .3, iNote[kNote]
endin

instr preplay
aEnv = linsegr:a(0, .002, .6, p3, .6, 1, 0)
aSig = wgpluck2(.7, 1, cpsmidinn(p4), .2, .3)
gaSend += aSig * aEnv
endin

instr write
aNdx = phasor(1/3)
tablew(gaSend, aNdx, giFt, 1)
clear gaSend
endin

instr read, play
aNdx = phasor(1/3)
aSig = table3:a(aNdx, giFt, 1)
outs aSig, aSig
endin

i"trig" 0 8.1 i"write" 0 9.4 i"read" .1 9.4

I shortened the start time of instr “read” but in the finished instr there had to be a full 3 sec delay in start times, that was the whole put in bothering to write to tables. Hopefully I can post an audio example of that later tonight that makes it clear why.

A quick note to others who may read: I have seen examples of people using a-rate env with functional syntax (myself included), presumably to avoid k-rate clicks. However the rules when using function(al) syntax are different.

This does not work:
aEnv = linsegr(0, .002, .6, p3, .6, 1, 0)

This will produce clicks (although depending on the osc/audio may not always be distinct), the env is still operating at k-rate.
https://www.dropbox.com/s/mel0ao51vzjhel1/click.jpg?dl=0

Running an a-rate env this way appears to be useless.

This will work:
aEnv = linsegr:a(0, .002, .6, p3, .6, 1, 0)

or without functional syntax:

aEnv linsegr 0, .002, .6, p3, .6, 1, 0

I mention this as I’ve learned the hard way, it occasionally plagued me till yesterday. It may have been obvious to all but me, but just in case. I know ambiguities are mentioned in the short Function Syntax section of the Canonical but the particulars weren’t clear to myself.

Best,

Scott

ST Music
https://soundcloud.com/st-csound
https://soundcloud.com/stoons-1

https://youtube.com/channel/UCGhwmkS1uWmX6mhTIQ0IDsg

[Michael_Gogins]

Thanks for the explanation!

Best,
Mike