Also quite glad to see this! This has become one of my favorite threads of the forum. It covers a lot of ground, and it's great to see your hard work and perseverance payoff here. Cheers too you, nau!

@nau said:

The BJT gains are bound to my 'signal amplitude policy' : input file or audio source and output should never clip. These gains can be seen as follows : the first one (before the clipper) adjust 'how early' distortion occurs, and the second one gives the distorted signal a boost in order to give similar subjective level than dry signal.
The values were found empirically.

This might be where I have the biggest issue, though the article doesn't make it so clear, either. In the article, it shows the frequency response of the BJT stage as having about a 36 dB boost in the pass band. That amounts to multiplying the signal by about 63. And, if you want to get really technical, the waveshaper in the article clips at +/- .6, so you'd have to add about another 4.5 dB to make up for that. You're using much lower values. This is what I was talking about earlier when I said you should really crank the input to [tanh~] to get some serious distortion, and the DS-1 isn't a baby's distortion pedal.

Now, the article also says that the second BJT stage is really to boost the signal back up for the subsequent load. Since we're not sending this into other circuits here, I think the dB boost of the second BJT should be ignored. Also, you don't need to calculate the boost into the filter coefficients. That's only useful for plotting. You can just use [*~] before or after the filter do accomplish it.

So basically what I'm saying is, there should be a boost of about 40 dB ([*~ 100]) as part of the first BJT stage, and no boost for the last one. Then you can really break some teeth with this distortion.

• when switching between upsampled or not upsampled processing, the difference is barely noticeable (maybe the upsampled one has more highs, but that is the exact contrary of what I would expect). Does someone see what I am doing wrong, if this is the cause of this perceptual draw ?

As mod said, it's not so much more highs as less lows, and those lows are a result of aliasing. To my ears, the upsampled version sounds less muddy. (By the way, in your upsampled portion, you have a different argument for the second [DS1-bjt_stage~]. Making them equal makes the difference even less noticeable, and draws more attention to the mud than the highs.)

• the transfer curves can be seen in the patches, but are always slightly different than the one showed in the article. But I have been very careful when calculating coefficients and I don't really think they are wrong. Would there persist a difference between [filterplot.mmb] and traditional Matlab-like graphs ?

Yes, there is a difference, but it's not a Matlab thing. It's the choice of the logarithmic scaling in the x-axis. The article uses powers-of-ten as equal distances. Mine uses [mtof] for the scaling, so that a semitone, octave, or whatever musical interval is the same distance. Also, I made an adjustment so that everything between 0 and about 20 Hz (at 44.1k) gets squashed in the leftmost 10% of the graph. If I didn't to that, then about half the plot would be taken up with frequencies below the audible range.

• The DS1-tone_stage helpfile has been written by Maelstorm, and the response curve shows no gain value above 0db. Nevertheless the tone knob, when pushed, can lead to signal amplitude beyond [-1 1]... I can't figure out how a signal can have all its discretised frequencies pulled down and still exhibit peaking. Should I read more about the subject (is there a name for this symptom ?), or is there an error in my patch ?

This has nothing to do with your tone stage. It's because of the passband ripple in the Chebychev filters. The IEM Chebychev filters have a 1 dB ripple, though I don't actually know if that means +/- 1 dB or +/- .5 dB. Either way, it's creating a boost at some frequencies, and pushing the output down by 1 dB should keep it below [-1, 1]. This could also be contributing to the highs, as the ripple is typically more pronounced near the cutoff frequency.

• is my 'signal policy' perfectible ? I want the output signal never to clip, so I multiply the output by 0.4 in such a way that when Tone and Dist are full right but Level is medium the signal never clips.

The output from [tanh~] will never clip, so as long as you make up for the ripple and don't boost the second BJT stage, you should be fine.

Just one more thing to add for now, and that is you're doing too much in the upsampled portion. The only thing that needs to be in there is the non-linear function ([tanh~]) and the anti-aliasing filters. Everything else is linear and doesn't benefit from upsampling, so it's just creating more computational load. So it should look more like this:

[*~ 100]
|
[DS1-bjt_stage~ 1]
|
[DS1-opamp_gain~]
|
[*~ 8]
|
[pd upsample]
|
[DS1-tone_stage~]
|
[DS1-bjt_stage~ 1]
|
[*~ .891] <-- 1 dB cut

And [pd upsample] should look like this:

[inlet~]
|
[lp10_cheb~ 18000] [block~ 64 1 8]
|
[tanh~]
|
[lp10_cheb~ 18000]
|
[outlet~]

Okay, that turned out to be more words than I expected. But we're getting into DETAILS here! Again, nice work, nau.

...but don't forget, there is a "point" (or frequency or refresh-rate) at which calculations via (audio)-signals are faster than the data-wise calculations...

I wonder when this exactly is the case. I have no Mac so I can't directly measure the CPU-load... but using audio often helped to reduce dropouts.

...ANd why or how?! Well, I don't know since I'm not into C-programming or whatever.. But I guess there must be any kind of pre- or post-message sticking to the data-signal (apart from all those "bang", "float" or "list" ) which roughly is left out at audio-signals.
If there is nothing like "audio" for audio-signals (like "bang" for "data-bang"), then the usual premessages like "float", "list"... would suffice.

So in general (looking at just one action like one value of the audio-signal-vector or one "banged data-action") there is more going on at data-signals then at audio-signals.
So they are calculated faster if the data-refresh-rate exceeds a certain frequency. Any other theories?!

Flipp

this is old... BUT

when I try to open this I get this error:

spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
wahwah~: an audio wahwah, version 0.1 (ydegoyon@free.fr)
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
 spigot~
... couldn't create
expr, expr~, fexpr~ version 0.4 under GNU General Public License 
[makesymbol] part of zexy-2.2.1 (compiled: Jul 21 2008)
    Copyright (l) 1999-2007 IOhannes m zmölnig, forum::für::umläute & IEM
[msgfile] part of zexy-2.2.1 (compiled: Jul 21 2008)
    Copyright (l) 1999-2007 IOhannes m zmölnig, forum::für::umläute & IEM
[list2symbol] part of zexy-2.2.1 (compiled: Jul 21 2008)
    Copyright (l) 1999-2007 IOhannes m zmölnig, forum::für::umläute & IEM
[folder_list] $Revision: 1.12 $
    written by Hans-Christoph Steiner <hans@at.or.at>
    compiled on Jul 21 2008 at 06:08:28 
setting pattern to default: C:/Users/Cody/Desktop/ma4u/*
error: signal outlet connect to nonsignal inlet (ignored)
... you might be able to track this down from the Find menu.
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
error: signal outlet connect to nonsignal inlet (ignored)
expr divide by zero detected

whats up?

[*~ ] just multiplies the signal by a number or fraction. so, if you multiply by 0.5, the volume of that signal will be half.

then, a basic eq would have stuff like this:

a) lowpass

[lop~ 500]

midpass

[hip~ 500]
|
[lop~ 2000]

c) highpass

[hip~ 2000]

for ease of drawing here, let's use a send/receive pair to show what happens to the signal in a simple one channel eq:

[inlet~]
|
[s~ my-signal]

[r~ my-signal]
|
| [0 ....-> 1]
| |
[*~ ]
|
[lop~ 500]
|
[throw~ eqd-signal]

there's the lowpass section. we just multiply the signal by a fraction between 0 and 1 to decide how much of the signal goes through the lowpass section.

here's the mid eq:

[r~ my-signal]
|
| [0 ....-> 1]
| |
[*~ ]
|
[hip~ 500]
|
[lop~ 2000]
|
[throw~ eqd-signal]

again, we just multiply the signal's amplitude to decide how much will go through the mid-eq section.

and finally the high end:

[r~ my-signal]
|
| [0 ....-> 1]
| |
[*~ ]
|
[hip~ 2000]
|
[throw~ eqd-signal]

then...we just catch~ all the signals at the end, and output to our speakers, or headphones or whatever:

[catch~ eqd-signal]
|
[dac~]

so, if you were to multiply that into 120 subpatches, every subpatch would contain 3 amplitude multiplications [*~ ] , and then 3 sets of filters.

however, because the 3 filter sections will be the same in every subpatch, you can just multiply the amplitudes (very cheap on cpu) and then output all 120 signals to one group of filters before going to the output.

if you look at the eq i posted as a patch, the aplitude multiplication occurs AFTER the filters. so it would be like:

[inlet~ ]
|
[lop~]
|
[*~ ]
|
[outlet~]

but, you can switch the order and have the same result:

[inlet~ ]
|
[*~ ]
|
[lop~ ]
|
[outlet~]

Hi,

I'm just getting started with Pd on Fedora Core 3; installation was pretty painless thanks to the CCRMA repositories, but I've run into an issue when I first tried to make some sounds with Pd. I recreated Miller Puckette's example of a constant amplitude scaler. When I start the audio, the signal seems to take a few seconds to 'settle' into a constant frequency; I get a few seconds of static that eventually turns into the sine wave I was expecting. When I click the DIO errors button, I get a bunch of A/D/A sync errors, as follows:

audio I/O error history:
seconds ago error type
0.73 A/D/A sync
0.73 A/D/A sync
0.75 A/D/A sync
0.94 A/D/A sync
0.94 A/D/A sync
0.95 A/D/A sync
1.01 A/D/A sync
1.01 A/D/A sync
1.10 A/D/A sync
1.10 A/D/A sync
1.11 A/D/A sync
1.11 A/D/A sync
1.17 A/D/A sync
1.17 A/D/A sync
1.17 A/D/A sync
1.17 A/D/A sync
1.27 A/D/A sync
1.31 A/D/A sync
1.31 A/D/A sync
1.36 A/D/A sync

If I let the steady sine wave tone continue, eventually there's a bit of a 'hiccup' in the sound, and then I get the following errors:

audio I/O error history:
seconds ago error type
1.25 DAC blocked
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late

Can anyone help me out in diagnosing this problem and fixing it? Where should I start looking to fix this?

Thanks!

The only problem i have so far (and it is a big one) is that it isn't reading the example files (bells, voice, and voice2) because it says they have malformed headers or something. I hope its just the files and not the program itself,

Unfortunately this is very likely a problem with the program. Different processors expect different alignment of words in memory. For example, if you declare a C data structure of { int32, int8, int32 } and one processor A expects int32's to be on 16bit boundaries and another processor Bexpects int32's to be on 32bit boundaries, the C data structure will be represented in memory differently:

A: { int32, int8, pad8, int32 }
B: { int32, int8, pad8, pad8, pad8, int32 }

The padding is just empty space to align the data on the correct word boundaries.

The problem occurs when the program's assumptions of data layout in memory do not match what the compiler does, and instead of reading a file format word by word and populating the data structure, reads a chunk of data and assumes that it matches the data format in memory.

Compare this with problems transferring data between big-endian and little-endian machines - you have to translate to and from the file format, not assume that the data in the file will match the data in memory for all architectures.

as said in the title i apologize cause it's in french . But if people found it revelant , someone will translate it huh?

in pd format:

[url=http://pure-data.iem.at/Members/mobil12/patchs-working/structure-help-01-FR.pd ]http://pure-data.iem.at/Members/mobil12/patchs-working/structure-help- 01-FR.pd

in pdf format

http://pure-data.iem.at/Members/mobil12/patchs-working/structure-help- 01-FR.pdf