Good evening/day,
I am attempting to use a modified version of a sampler abstraction that originally read a file repeatedly in two instances with fade-ins/-outs so that the sound continued indefinitely. I modified it for use with live-input, and it works. However, there are always unwanted clicks whenever the array is resized. The array is immediately set to 10 sec. when the input starts,and ,after the input ends, is reduced to the length of the input (there is more noise during the second resizing).

The strange thing about this is that these clicks happen, even when there is no audio going into or out of the abstraction (as long as some kind of audio is being processed elsewhere in the patch). Apparently, Pure Data is so disturbed by these resizes that it needs to make these unwanted clicking sounds.

Is this normal? Am I over-looking something?

The patch is a little complicated, but the resizing happens right at the top. The first two arguments are only to distinguish one instance of the patch from other instances. The third and fourth are for the points of the array within which it should be read. (eg. .12 and .91 would give you most of the array, but not the very beginning and end).

If you cannot see what the problem is, I would also appreciate any alternative abstraction-suggestions which might get the job done. Thanks for your time.

Best Regards,
Stephan

http://www.pdpatchrepo.info/hurleur/livesampler~.pd

Good evening/day,
I am attempting to use a modified version of a sampler abstraction that originally read a file repeatedly in two instances with fade-ins/-outs so that the sound continued indefinitely. I modified it for use with live-input, and it works. However, there are always unwanted clicks whenever the array is resized. The array is immediately set to 10 sec. when the input starts,and ,after the input ends, is reduced to the length of the input (there is more noise during the second resizing).

The strange thing about this is that these clicks happen, even when there is no audio going into or out of the abstraction (as long as some kind of audio is being processed elsewhere in the patch). Apparently, Pure Data is so disturbed by these resizes that it needs to make these unwanted clicking sounds.

Is this normal? Am I over-looking something?

The patch is a little complicated, but the resizing happens right at the top. The first two arguments are only to distinguish one instance of the patch from other instances. The third and fourth are for the points of the array within which it should be read. (eg. .12 and .91 would give you most of the array, but not the very beginning and end).

If you cannot see what the problem is, I would also appreciate any alternative abstraction-suggestions which might get the job done. Thanks for your time.

Best Regards,
Stephan

http://www.pdpatchrepo.info/hurleur/livesampler~.pd

Hello,
With pure sine-wave-based Frequency Modulation, one always hears the base pitch if the carrier-frequency is the same as the modulator-frequency. Raising the index will add harmonics and change their strength, but the base tonality will stay very clear. However, with this audio sample of a clarinet, it would seem that actual audio, when FM is applied to it, is much more complicated. Having the modulator-frequency approximately equal the base-frequency of the clarinet produces a sound with said frequency, but only at certain Indexes. I assume this is due to the obvious complications of audio: 1) No pitch-tracker is perfect and 2) unlike a sinus-tone, an actual acoustic sound contains a whole harmonic series of frequencies, all of which are modulated.
I am wondering if anyone here has experience with this phenomenon. I would like to know if there is some way of calculating which Index will contribute to the pureness of a same-frequency carrier-modulator relationship. Or is this impossible and dependent on the individuality of each instrument and each sound produced?

Many Thanks.

P.S. [transpositiontest2] is the main patch.

http://www.pdpatchrepo.info/hurleur/transpositiontest2.pd

Hello,
With pure sine-wave-based Frequency Modulation, one always hears the base pitch if the carrier-frequency is the same as the modulator-frequency. Raising the index will add harmonics and change their strength, but the base tonality will stay very clear. However, with this audio sample of a clarinet, it would seem that actual audio, when FM is applied to it, is much more complicated. Having the modulator-frequency approximately equal the base-frequency of the clarinet produces a sound with said frequency, but only at certain Indexes. I assume this is due to the obvious complications of audio: 1) No pitch-tracker is perfect and 2) unlike a sinus-tone, an actual acoustic sound contains a whole harmonic series of frequencies, all of which are modulated.
I am wondering if anyone here has experience with this phenomenon. I would like to know if there is some way of calculating which Index will contribute to the pureness of a same-frequency carrier-modulator relationship. Or is this impossible and dependent on the individuality of each instrument and each sound produced?

Many Thanks.

P.S. [transpositiontest2] is the main patch.

http://www.pdpatchrepo.info/hurleur/transpositiontest2.pd

Hello,
With pure sine-wave-based Frequency Modulation, one always hears the base pitch if the carrier-frequency is the same as the modulator-frequency. Raising the index will add harmonics and change their strength, but the base tonality will stay very clear. However, with this audio sample of a clarinet, it would seem that actual audio, when FM is applied to it, is much more complicated. Having the modulator-frequency approximately equal the base-frequency of the clarinet produces a sound with said frequency, but only at certain Indexes. I assume this is due to the obvious complications of audio: 1) No pitch-tracker is perfect and 2) unlike a sinus-tone, an actual acoustic sound contains a whole harmonic series of frequencies, all of which are modulated.
I am wondering if anyone here has experience with this phenomenon. I would like to know if there is some way of calculating which Index will contribute to the pureness of a same-frequency carrier-modulator relationship. Or is this impossible and dependent on the individuality of each instrument and each sound produced?

Many Thanks.

P.S. [transpositiontest2] is the main patch.

http://www.pdpatchrepo.info/hurleur/transpositiontest2.pd

Hello,
With pure sine-wave-based Frequency Modulation, one always hears the base pitch if the carrier-frequency is the same as the modulator-frequency. Raising the index will add harmonics and change their strength, but the base tonality will stay very clear. However, with this audio sample of a clarinet, it would seem that actual audio, when FM is applied to it, is much more complicated. Having the modulator-frequency approximately equal the base-frequency of the clarinet produces a sound with said frequency, but only at certain Indexes. I assume this is due to the obvious complications of audio: 1) No pitch-tracker is perfect and 2) unlike a sinus-tone, an actual acoustic sound contains a whole harmonic series of frequencies, all of which are modulated.
I am wondering if anyone here has experience with this phenomenon. I would like to know if there is some way of calculating which Index will contribute to the pureness of a same-frequency carrier-modulator relationship. Or is this impossible and dependent on the individuality of each instrument and each sound produced?

Many Thanks.

P.S. [transpositiontest2] is the main patch.

http://www.pdpatchrepo.info/hurleur/transpositiontest2.pd

Hello again,
First of all, thank you again for your recent help. I am getting a patch ready for a concert on the 21 and 22.6 so your advice is appreciated.
At the beginning of my piece, I filter [noise~] and and send random values for the q into [bp~], and even though I am using lines (of about 15 ms, because I want sudden changes) I am getting crackling sounds once the window of values becomes larger- I start with a window of 0 to 1 q with is gradually enlarged and shifted to a window of 500-1000 q (the amplitude is correspondingly changed with each alteration of the q, also with a [line~] of 15) -and I am not certain why. I spoke to one of my professors about it, and he suggested using a higher-tier filter like [biquad~]. However, neither he nor I understand the mathematical workings of this object's arguments. He uses MaxMSP, not PD, and says there is a graphical interface for [biquad~] in Max which allows for easy manipulation of the of the values to achieve a desired filtering; of course he doesn't know if anything like this exists for PD.
Any ideas?

Good afternoon,
I am using [fiddle~] to detect the dominant frequency of incoming instrumental sounds. This frequency is then used (after being but through [expr] ) to determine that of each level of modulation in a complex ring modulation. There are two problems here- well actually, one problem with two instances in which it is the most noticable:

This takes far too long. In order to avoid hearing the unmodulated instrumental attack before the modulation kicks in, I need to add a delay (with [delwrite~] and [vd~] ) of about 200 ms before the input goes into the modulators. This is not the worst issue, as a delay is called for on the modulated sounds for most of the composition anyway, but it is still not ideal.

The bigger issue is with shorter, articulated incoming sounds. When, between attacks, fiddle detects the rests, the outputted frequency is 0 which shuts off the modulators and then turns them back on at the next attack which, due to the aforementioned slowness, leads to incomplete modulations. And now that I think about it, a delay of 200 seconds to fix the first issue would lead to incorrect modulations here as well.

Are you familiar with such problems? Is there perhaps an abstraction that is very useful for such things? I am trying to get this taken care of as soon as possible, as the patch should be used in a concert on the 21st of June. I can try to upload an example patch if you wish. The actual patch is probably too large and complicated to post here...

Many thanks for your time,
Stephan

Edit: Ah, after having stripped away various components to put this example patch together (the main patch is [clarmod] ), I find that it seems to work much more quickly. It is probably still not good that the modulators constantly turn themselves on and off with the articulations, so any advice for this question is still appreciated. Otherwise, I need to look into what is slowing down the modulators in the actual patch.

Edit: Ah, a professor of mine just suggested using [sigmund~] instead of [fiddle~]. It seems to have more useful options.

http://www.pdpatchrepo.info/hurleur/clarinet1.wav

Good afternoon,
I am using [fiddle~] to detect the dominant frequency of incoming instrumental sounds. This frequency is then used (after being but through [expr] ) to determine that of each level of modulation in a complex ring modulation. There are two problems here- well actually, one problem with two instances in which it is the most noticable:

This takes far too long. In order to avoid hearing the unmodulated instrumental attack before the modulation kicks in, I need to add a delay (with [delwrite~] and [vd~] ) of about 200 ms before the input goes into the modulators. This is not the worst issue, as a delay is called for on the modulated sounds for most of the composition anyway, but it is still not ideal.

The bigger issue is with shorter, articulated incoming sounds. When, between attacks, fiddle detects the rests, the outputted frequency is 0 which shuts off the modulators and then turns them back on at the next attack which, due to the aforementioned slowness, leads to incomplete modulations. And now that I think about it, a delay of 200 seconds to fix the first issue would lead to incorrect modulations here as well.

Are you familiar with such problems? Is there perhaps an abstraction that is very useful for such things? I am trying to get this taken care of as soon as possible, as the patch should be used in a concert on the 21st of June. I can try to upload an example patch if you wish. The actual patch is probably too large and complicated to post here...

Many thanks for your time,
Stephan

Edit: Ah, after having stripped away various components to put this example patch together (the main patch is [clarmod] ), I find that it seems to work much more quickly. It is probably still not good that the modulators constantly turn themselves on and off with the articulations, so any advice for this question is still appreciated. Otherwise, I need to look into what is slowing down the modulators in the actual patch.

Edit: Ah, a professor of mine just suggested using [sigmund~] instead of [fiddle~]. It seems to have more useful options.

http://www.pdpatchrepo.info/hurleur/clarinet1.wav

Good afternoon,
I am using [fiddle~] to detect the dominant frequency of incoming instrumental sounds. This frequency is then used (after being but through [expr] ) to determine that of each level of modulation in a complex ring modulation. There are two problems here- well actually, one problem with two instances in which it is the most noticable:

This takes far too long. In order to avoid hearing the unmodulated instrumental attack before the modulation kicks in, I need to add a delay (with [delwrite~] and [vd~] ) of about 200 ms before the input goes into the modulators. This is not the worst issue, as a delay is called for on the modulated sounds for most of the composition anyway, but it is still not ideal.

The bigger issue is with shorter, articulated incoming sounds. When, between attacks, fiddle detects the rests, the outputted frequency is 0 which shuts off the modulators and then turns them back on at the next attack which, due to the aforementioned slowness, leads to incomplete modulations. And now that I think about it, a delay of 200 seconds to fix the first issue would lead to incorrect modulations here as well.

Are you familiar with such problems? Is there perhaps an abstraction that is very useful for such things? I am trying to get this taken care of as soon as possible, as the patch should be used in a concert on the 21st of June. I can try to upload an example patch if you wish. The actual patch is probably too large and complicated to post here...

Many thanks for your time,
Stephan

Edit: Ah, after having stripped away various components to put this example patch together (the main patch is [clarmod] ), I find that it seems to work much more quickly. It is probably still not good that the modulators constantly turn themselves on and off with the articulations, so any advice for this question is still appreciated. Otherwise, I need to look into what is slowing down the modulators in the actual patch.

Edit: Ah, a professor of mine just suggested using [sigmund~] instead of [fiddle~]. It seems to have more useful options.

http://www.pdpatchrepo.info/hurleur/clarinet1.wav