Alex AB wrote:

> When I render to .wav, it seems as though the actual wav is riding on top
> of a DC voltage.

>From the image you provided, it does seem that way, but any *apparent*
DC is tiny with respect to the signal levels.

The other thing to note is that the vast majority of real world audio
signals are asymmetric across the zero value.

Honestly with what you have shown, you proably shouldn't worry about it.

Erik

hi alexandre -
after a quick look at your csd: can you try ksmps=32 instead of ksmps=4096?
not sure if this is related to your problem, but 4096 is certainly much
too large.
	joachim


Am 26.01.2012 00:05, schrieb Alex AB:
> Hello,
> I am working on a small piece and there are a couple of issues I don't
> understand with it.
> When I render to .wav, it seems as though the actual wav is riding on
> top of a DC voltage. My digital audio theory is poor, but this is how I
> interpret what I see when I look at the wave in Audacity. I build valve?
> amps, so I'm used to seeing audio riding on top of a DC signal on the
> scope, at the anode of a gain stage for instance, it looks the same, but
> the offset shifts from the positive phase of the signal to the negative
> phase at regular intervals. If I record the sound card's output to an
> other computer, no more "DC", the sound card's output is AC coupled so
> that seems reasonnable enough.
> I also use a high ksmps value (am I right in systematically using powers
> of 2 there?), as  I get some some high frequency noises if I go under,
> say, ksmps = 1024 or so.
> I'd really need some help to understand what is happening. The .csd and
> a screen shot of the wave in Audacity are attached. The piece was
> written in CsoundQT, but the issues are the same in WinXound and if I
> "run in terminal" from CsoundQT.
> 
> Is my code badly written?
> I'm new to csound and programming in general, so any remarks pertaining
> to the subject will be appreciated, relevant or not with the current issue.
> 
> Am I badly using the opcodes I have in the orchestra?
> The three instruments are built around the grain opcode, the third one
> uses a slightly modified version of the lorenz+spat3d opcodes example
> from the manual.
> The "DC" issue is in instr 11 and 22 while the high frequency noises
> come from instr 33 (specifically, the 2 long notes that mix the grain
> opcode's output to the lorenz/spat3D system's output).
> 
> Any help in solving the issue will be deeply appreciated.
> This is a work in progress, so please be indulgent with the music, as
> for me, you can shoot at will.
> 
> Thanks for your time.
> 
> Alexandre
> 


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

A high-pass filter will block DC every time in analog or digital 
domains. Looking at the waveform I don't see any DC offset, just low 
frequency stuff. I sometimes get the same-looking thing on an analog 
synth with the envelope set to a fast attack. Maybe changing the 
"attack" of the grain will help.

Martin

On 2012-01-26 07:56, Alex AB wrote:
> Hello, and thanks for the responses.
>
> I tried at lower ksmps values. I used the lpf18 opcode to tame the high
> frequency noises. I'm not sure whether they are artifacts or part of the
> sound, but they now are part of the music, so it's OK with me.
> However, the DC thing gets worse at lower ksmps, one can hear the moment
> when the DC moves from the positive side to the negative side. The
> effect changes slightly with ksmps values, 8 is all right, 16 is awful
> and 32 is somewhere in between.
>
> I'm pretty sure it's something in the way I wrote instr 11 (instr 22 is
> a modified copy of instr 11) that causes that effect, but I can't figure
> out what it is.
> Intuitive reasoning makes me think of either an issue with grain length
> or grain density, but when I change these parameters, I lose the
> feedback quality of the sound, which is what the instruments are
> supposed to do.
> I tried a high pass filter in series with the instr output, on the
> (very) far-stretched idea that it may block the DC component, as would a
> series capacitor in the analog domain. But, unsurprisingly, it didn't
> change anything.
>
> Using lower ksmps does change the quality of the sound, and with a few
> more tweaks, the piece will sound way better than it did at high ksmps,
> so that's good news.
> But I am at my wit's end with this DC offset issue.
> I have no idea how to implement a DC blocking element in the digital
> domain, and would rather understand where that DC comes from than just
> using a band aid solution to kill it, even though I'd benefit from the
> exercise.
>
> Alexandre.
>
> On 26 January 2012 00:27, joachim heintz  > wrote:
>
>     hi alexandre -
>     after a quick look at your csd: can you try ksmps=32 instead of
>     ksmps=4096?
>     not sure if this is related to your problem, but 4096 is certainly much
>     too large.
>             joachim
>
>
>     Am 26.01.2012 00:05, schrieb Alex AB:
>      > Hello,
>      > I am working on a small piece and there are a couple of issues I
>     don't
>      > understand with it.
>      > When I render to .wav, it seems as though the actual wav is riding on
>      > top of a DC voltage. My digital audio theory is poor, but this is
>     how I
>      > interpret what I see when I look at the wave in Audacity. I build
>     valve?
>      > amps, so I'm used to seeing audio riding on top of a DC signal on the
>      > scope, at the anode of a gain stage for instance, it looks the
>     same, but
>      > the offset shifts from the positive phase of the signal to the
>     negative
>      > phase at regular intervals. If I record the sound card's output to an
>      > other computer, no more "DC", the sound card's output is AC
>     coupled so
>      > that seems reasonnable enough.
>      > I also use a high ksmps value (am I right in systematically using
>     powers
>      > of 2 there?), as  I get some some high frequency noises if I go
>     under,
>      > say, ksmps = 1024 or so.
>      > I'd really need some help to understand what is happening. The
>     .csd and
>      > a screen shot of the wave in Audacity are attached. The piece was
>      > written in CsoundQT, but the issues are the same in WinXound and if I
>      > "run in terminal" from CsoundQT.
>      >
>      > Is my code badly written?
>      > I'm new to csound and programming in general, so any remarks
>     pertaining
>      > to the subject will be appreciated, relevant or not with the
>     current issue.
>      >
>      > Am I badly using the opcodes I have in the orchestra?
>      > The three instruments are built around the grain opcode, the
>     third one
>      > uses a slightly modified version of the lorenz+spat3d opcodes example
>      > from the manual.
>      > The "DC" issue is in instr 11 and 22 while the high frequency noises
>      > come from instr 33 (specifically, the 2 long notes that mix the grain
>      > opcode's output to the lorenz/spat3D system's output).
>      >
>      > Any help in solving the issue will be deeply appreciated.
>      > This is a work in progress, so please be indulgent with the music, as
>      > for me, you can shoot at will.
>      >
>      > Thanks for your time.
>      >
>      > Alexandre
>      >
>
>
>     Send bugs reports to the Sourceforge bug tracker
>     https://sourceforge.net/tracker/?group_id=81968&atid=564599
>     
>     Discussions of bugs and features can be posted here
>     To unsubscribe, send email sympa@lists.bath.ac.uk
>      with body "unsubscribe csound"
>
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Also, try using the dcblock opcode. I'm surprised no one has suggested this.

On 1/26/12, Martin Peach  wrote:
> A high-pass filter will block DC every time in analog or digital
> domains. Looking at the waveform I don't see any DC offset, just low
> frequency stuff. I sometimes get the same-looking thing on an analog
> synth with the envelope set to a fast attack. Maybe changing the
> "attack" of the grain will help.
>
> Martin
>
> On 2012-01-26 07:56, Alex AB wrote:
>> Hello, and thanks for the responses.
>>
>> I tried at lower ksmps values. I used the lpf18 opcode to tame the high
>> frequency noises. I'm not sure whether they are artifacts or part of the
>> sound, but they now are part of the music, so it's OK with me.
>> However, the DC thing gets worse at lower ksmps, one can hear the moment
>> when the DC moves from the positive side to the negative side. The
>> effect changes slightly with ksmps values, 8 is all right, 16 is awful
>> and 32 is somewhere in between.
>>
>> I'm pretty sure it's something in the way I wrote instr 11 (instr 22 is
>> a modified copy of instr 11) that causes that effect, but I can't figure
>> out what it is.
>> Intuitive reasoning makes me think of either an issue with grain length
>> or grain density, but when I change these parameters, I lose the
>> feedback quality of the sound, which is what the instruments are
>> supposed to do.
>> I tried a high pass filter in series with the instr output, on the
>> (very) far-stretched idea that it may block the DC component, as would a
>> series capacitor in the analog domain. But, unsurprisingly, it didn't
>> change anything.
>>
>> Using lower ksmps does change the quality of the sound, and with a few
>> more tweaks, the piece will sound way better than it did at high ksmps,
>> so that's good news.
>> But I am at my wit's end with this DC offset issue.
>> I have no idea how to implement a DC blocking element in the digital
>> domain, and would rather understand where that DC comes from than just
>> using a band aid solution to kill it, even though I'd benefit from the
>> exercise.
>>
>> Alexandre.
>>
>> On 26 January 2012 00:27, joachim heintz > > wrote:
>>
>>     hi alexandre -
>>     after a quick look at your csd: can you try ksmps=32 instead of
>>     ksmps=4096?
>>     not sure if this is related to your problem, but 4096 is certainly
>> much
>>     too large.
>>             joachim
>>
>>
>>     Am 26.01.2012 00:05, schrieb Alex AB:
>>      > Hello,
>>      > I am working on a small piece and there are a couple of issues I
>>     don't
>>      > understand with it.
>>      > When I render to .wav, it seems as though the actual wav is riding
>> on
>>      > top of a DC voltage. My digital audio theory is poor, but this is
>>     how I
>>      > interpret what I see when I look at the wave in Audacity. I build
>>     valve?
>>      > amps, so I'm used to seeing audio riding on top of a DC signal on
>> the
>>      > scope, at the anode of a gain stage for instance, it looks the
>>     same, but
>>      > the offset shifts from the positive phase of the signal to the
>>     negative
>>      > phase at regular intervals. If I record the sound card's output to
>> an
>>      > other computer, no more "DC", the sound card's output is AC
>>     coupled so
>>      > that seems reasonnable enough.
>>      > I also use a high ksmps value (am I right in systematically using
>>     powers
>>      > of 2 there?), as  I get some some high frequency noises if I go
>>     under,
>>      > say, ksmps = 1024 or so.
>>      > I'd really need some help to understand what is happening. The
>>     .csd and
>>      > a screen shot of the wave in Audacity are attached. The piece was
>>      > written in CsoundQT, but the issues are the same in WinXound and if
>> I
>>      > "run in terminal" from CsoundQT.
>>      >
>>      > Is my code badly written?
>>      > I'm new to csound and programming in general, so any remarks
>>     pertaining
>>      > to the subject will be appreciated, relevant or not with the
>>     current issue.
>>      >
>>      > Am I badly using the opcodes I have in the orchestra?
>>      > The three instruments are built around the grain opcode, the
>>     third one
>>      > uses a slightly modified version of the lorenz+spat3d opcodes
>> example
>>      > from the manual.
>>      > The "DC" issue is in instr 11 and 22 while the high frequency
>> noises
>>      > come from instr 33 (specifically, the 2 long notes that mix the
>> grain
>>      > opcode's output to the lorenz/spat3D system's output).
>>      >
>>      > Any help in solving the issue will be deeply appreciated.
>>      > This is a work in progress, so please be indulgent with the music,
>> as
>>      > for me, you can shoot at will.
>>      >
>>      > Thanks for your time.
>>      >
>>      > Alexandre
>>      >
>>
>>
>>     Send bugs reports to the Sourceforge bug tracker
>>     https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>     
>>     Discussions of bugs and features can be posted here
>>     To unsubscribe, send email sympa@lists.bath.ac.uk
>>      with body "unsubscribe csound"
>>
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

The first thing I notice is the line 'aDens = giBH'.  This is not doing what I think you think it is.  I am assuming that your intention is one of two things; either to have the grain density follow the curve of the BH window over the course of the note, or to have the density be a random value with the distribution of values being a BH curve.

Out of curiosity, why didn't dcblock work in this case?

On 1/27/12, Alex AB  wrote:
> Hello, and thank you for your very informative message.
> This had me to go through the thought process that initiated instr 11.
>
>
>> The first thing I notice is the line 'aDens = giBH'.  This is not doing
>> what I think you think it is.  I am assuming that your intention is one of
>> two things; either to have the grain density follow the curve of the BH
>> window over the course of the note, or to have the density be a random
>> value with the distribution of values being a BH curve.
>>
>
> The initial idea, was to generate a random grain density constrained within
> a distribution window. In my previous experiments with the grain opcode, I
> had a line envelope vary grain density and grain length and wasn't
> satisfied with the result as I always ended up with the same sort of sounds
> (instr 33 is derived from those tests).
> Thinking about it, to have the grain density follow the BH curve over the
> length of the note, I'd need something like a phasor sweeping through the
> BH table, and send the resulting values to aDens. This wasn't the original
> idea, but I shall try it anyway, as an exercise.
> To achieve the original idea, I'd need a random number generator, and
> multiply the result by the BH distribution table, like I'd do to modulate
> an amplitude with an envelope.
> Am I looking in the right direction?
>
> your envelopes all have different time lengths
>>
>
> The reason I did it that way comes from reading the manual. I wanted an
> amplitude envelope with an added release time so the loops in the score
> would overlap. Maybe M.Gogins' way of doing it in the Csound AC tutorials
> (toot3) is a better idea, I will try that out also.
> For the other envelopes, if the note was shorter than the envelope, the
> remainder would be ignored, and longer notes would sound a bit different
> than shorter ones.
> The idea was that, the evolution of sound as a function of time would
> always be the same, but not all notes would get to go through the complete
> pattern.
> From what I read in the manual, this is how the expseg or line opcodes
> work, ignoring whatever may be going on after the end of a note, and
> looping the envelope, should the note be longer than the envelope.
> aEnv2 ended up as an expsegr opcode from empirical listening to the result
> but was originally an expseg opcode.
>
> The big issue, which is causing the dc issue, is that in the arguments for
>> your 'grain' opcode, I think you have unintentionally switched the igfn
>> and
>> iwfn arguments.
>>
>
> The idea behind this was to have a sine wave inside the grain, with a
> bell-shaped amplitude envelope, so igfn would be giGauss or giBH and iwfn
> would be giSine. If I'm not mistaken, using the grain opcode, one has to
> define the grain envelope before the grain waveform. I did at a moment try
> to invert the two, as an other empirical test, but didn't like the sound
> too much. This does give me an important lead to investigate the issue.
>
> A few lessons learned: write down a flowchart of my ideas to see if the
> code is consistent with what I wanted. Think more about what the computer
> is doing with the instructions I give him.
>
> Following previous suggestions, I have tried various solutions, hi-pass
> filtering, and the dcblock opcodes, none of which cured the issue.
> From looking closer at the rendered waveform, the offset follows the timing
> of aEnv2, shifting from the positive phase to the negative phase at each
> breakpoint. I tried eliminating aEnv2 altogether last night but to no
> avail. I shall investigate further in the light of recent messages.
> I already have learned a lot thanks to your contributions.
>
> Alexandre
>
> On 27 January 2012 05:27, mark jamerson  wrote:
>
>>
>>    I took a look at your piece and I've noticed a few things that look a
>> little weird, and I think I have figured out what was causing your dc
>> issue.
>>
>>> The first thing I notice is the line 'aDens = giBH'.  This is not doing
>>> what I think you think it is.  I am assuming that your intention is one
>>> of
>>> two things; either to have the grain density follow the curve of the BH
>>> window over the course of the note, or to have the density be a random
>>> value with the distribution of values being a BH curve.  The code you
>>> have,
>>> however, does neither of these.  When I set aDens to a k-variable and use
>>> printk to display the value, it shows a repeated value of 104, therefore
>>> the grain density throughout the notes is staying at 104, which as a
>>> value
>>> doesn't even make sense because the BH window should put out values from
>>> o
>>> to 1. What that line of code is actually doing is giving the f-table
>>> number
>>> that the ftgen opcode has assigned to the table that you have generated.
>>>  If you changed the line to 'aDens = giGauss' it would give you a value
>>> of
>>> 105, as that's the next table in line.  There are ways to do what I think
>>> you are wanting to do, but I won't explain them at this time.  This issue
>>> most likely isn't contributing to the dc issue, but I figured you should
>>> know what going on with your code.
>>>
>> The second issue which is minor, but may give you problems is that your
>> envelopes all have different time lengths.  Your first envelope is
>> dependent on the length of the note, your second one has fixed length of
>> 23
>> secs, and your third has a length of 27 secs.  This may not be giving you
>> any problems in this instance, but it is something to keep an eye on in
>> the
>> future.
>>         The big issue, which is causing the dc issue, is that in the
>> arguments for your 'grain' opcode, I think you have unintentionally
>> switched the igfn and iwfn arguments.  Switching the order of these will
>> take out the dc issue, but of course will change the resultant sound.
>>         I hope I have explained this clearly enough. Let me know if you
>> have any questions.
>>
>>            Mark
>>
>>
>>   ------------------------------
>> *From:* Alex AB 
>> *To:* csound@lists.bath.ac.uk
>> *Sent:* Wednesday, January 25, 2012 5:05 PM
>> *Subject:* [Csnd] a couple of things I don't understand
>>
>> Hello,
>> I am working on a small piece and there are a couple of issues I don't
>> understand with it.
>> When I render to .wav, it seems as though the actual wav is riding on top
>> of a DC voltage. My digital audio theory is poor, but this is how I
>> interpret what I see when I look at the wave in Audacity. I build valve
>> amps, so I'm used to seeing audio riding on top of a DC signal on the
>> scope, at the anode of a gain stage for instance, it looks the same, but
>> the offset shifts from the positive phase of the signal to the negative
>> phase at regular intervals. If I record the sound card's output to an
>> other
>> computer, no more "DC", the sound card's output is AC coupled so that
>> seems
>> reasonnable enough.
>> I also use a high ksmps value (am I right in systematically using powers
>> of 2 there?), as  I get some some high frequency noises if I go under,
>> say,
>> ksmps = 1024 or so.
>> I'd really need some help to understand what is happening. The .csd and a
>> screen shot of the wave in Audacity are attached. The piece was written in
>> CsoundQT, but the issues are the same in WinXound and if I "run in
>> terminal" from CsoundQT.
>>
>> Is my code badly written?
>> I'm new to csound and programming in general, so any remarks pertaining to
>> the subject will be appreciated, relevant or not with the current issue.
>>
>> Am I badly using the opcodes I have in the orchestra?
>> The three instruments are built around the grain opcode, the third one
>> uses a slightly modified version of the lorenz+spat3d opcodes example from
>> the manual.
>> The "DC" issue is in instr 11 and 22 while the high frequency noises come
>> from instr 33 (specifically, the 2 long notes that mix the grain opcode's
>> output to the lorenz/spat3D system's output).
>>
>> Any help in solving the issue will be deeply appreciated.
>> This is a work in progress, so please be indulgent with the music, as for
>> me, you can shoot at will.
>>
>> Thanks for your time.
>>
>> Alexandre
>>
>>
>>
>>
>