@whale-av Hi, finally I got some time So, first of all I deleted this dumb line, which was breaking my code, making the pipe useless.

I thought this would fix everything, but since a fast transition to 0 is necessary, I still get the puff mentioned in the original problem of my first post. This is the mechanism I used to solve the clicks:

The idea is: whenever I press my custom Stop button, immediately pause the [line~] reading the array (with the [stop( message) and send a [0 fade_time( message to the [line~] responsible for the volume, but don't go to the beginning of the array immediately, wait fade_time (which is what the [pipe] is doing, in this example with fade_time = 500). Also, I just added a delay object to make the volume come back to where it was before.

Except for the send/receive design (and the state of the overall volume), I could only spot one difference comparing your patch and mine: when the Stop button is pressed, you don't [stop( it immediately like me, but you wait fade_time and only then you pause the [line~] and go to the beginning of the array. However, the [stop( message doesn't introduce a click, so I still don't know why your patch works flawlessly and not mine, am I missing something?

In my case, it's just because it looks like a project that every pd student should do. The way I made the patch is just the way I solved the problems with my limited knowledge and tried to stay as vanilla as possible. Also, it's nice to have a whole work just of your own I'll check the abstraction and the corrections as soon as I have some time.

@whale-av So, while playing with your patch I don't think I get any clicks. I'm uploading my patch here, it's a one shot sampler with line~. I'll still implement L/R boundaries and speed change, but the main part is done. When I Pause and then press Stop (or Play) there is a click and the part that I thought would fix this is around "Trying to fix click" (at least just for the Stop). Also, maybe it's a bit messy, any tips on that are appreciated too
Sampler.pd
unsig~.pd

@whale-av I put the array it in a [table array] and I still get the clicks. The array is already fully loaded with read -> soundfiler before any manipulation. I don't get the clicks in your patch with readsf~ when pause/resuming and neither pause/stopping, which are the problems in my original patch in progress.

@ddw_music Nice demonstration, that seems exactly what I'm facing. I'll try the sinusoidal envelope.

@seb-harmonik.ar The slider goes from 0 to 1 and apparently the size of the array doesn't matter, according to some tests. I tried some values from 500 to 100.000 samples.

@bocanegra That's true, but I made my tests here when there was no buzzing sound. The situation here is different, the click just happens when the volume changes abruptly (clicking the message or the slider).

Hi, I thought I could stick forever with a message going to line~ with aproximately 30ms and my clicking troubles would be gone, but I found out a situation where I can still hear a click (actually it's more like a "puff"). I'm constructing a sampler with play, stop and pause buttons and that's where this situation appeared. I was trying to find out the origin of this quick "puff" sound when I click the stop and I got this minimum patch that still exhibits the behavior. Even with high values of 300ms, the click/puff is still audible. Is this an extreme example in some sense or the line~ modus operandi is far from perfect and should be replaced by something better?

I'm not so sure, but some hypotheses: Is ofFloatColor unavailable since it's not present here - https://github.com/cuinjune/Ofelia/blob/master/ofelia/classesAndGlobalFunctions.txt ? And also, would the second error be related do this issue - https://forum.pdpatchrepo.info/topic/12181/ofelia-expected-float-got-number ?

Hi, I'm trying to use another color schemes other than RGB in [0, 255] and I'm unable to use ofFloatColor which would let me define the RGB with floats in [0, 1] and also fromHsb (although I can use color:setHsb normally). Maybe it's some silly syntax issue, but with the following declarations:

local green = ofFloatColor(0.1, 0.9, 0.1);
local orange = ofColor:fromHsb(15, 255, 255);

when I use ofSetColor(green) and ofSetColor(orange) I get the following errors for each of my previous two attempts:

ofelia: [string "package.preload['_.x4081390.c'] = nil packag..."]:4: Error in ofSetColor (arg 1), expected 'int' got 'ofDefaultColorType *|ofColor< float > *|ofFloatColor *'

ofelia: [string "package.preload['_.x4081e10.c'] = nil packag..."]:4: Error in ofColor< unsigned char >::fromHsb (arg 1), expected 'float' got 'table'

It`s strange that the noise just occurred with the DC offset "sound", not all the time the soundcard was turned on. Well, a new day, a power off / power on ... and the noise is gone, definitely some hardware issue here, tks for the answers.

Oh my ... indeed a spectrum analyzer doesn't reveal any artifact. The noise exists in the headphone and also the speakers. It looks like the notebook soundcard doesn't exhibit it, so my main m-audio soundcard indeed seems to be the problem

I uploaded a sound file with the noise and the sine wave played in it: noise.wav

Tabread4~ doesn't change the noise, however the noise disappears with tabplay~ (which makes sense because it doesn't read all the time, just when banged, right?).

The DC offset seems to be the right problem, because a hip~ 5 after the tabread~ eliminates the humming noise. This leaves me with another question: if tabread~ is outputing all the time, what is it exactly reading? The first value of the array, since you mention the start? If that's the case I should read some level in the VU meter (which I do), but not hear any kind of noise, after all it's a constant, right? I also tested it with constant signs, and indeed I get the same noise whenever the constant is not 0.

Also, no help pages were opened in the background

What could be the reason that this results in a strange noise with a low volume (all the time, without even clicking the message)? The array is made with tabwrite~ and has a simple osc with 44100 samples. The buzzing sound comes from the tabread~ . Everything can be deleted, if there's the tabread~ connected to the output and this array exists, there is a buzz.

@bocanegra Thanks, but the actual mapping between midi notes and frequency is not the original issue, which turned out to be just a matter of scaling. The question was solved by ddw_music, which is a particular case of the general formula in the stack link I sent (if you take x_0=0 and x_1=1 there you recover ddw_music formulas and more, you can take log(y) as any function f(y))

By the way, one related question regarding the implementation: are there performance differences between implementations with lots of [f ], [+ ], [t b f], etc ... and a simple [expr] or [expr~] ? Is one way preferable?

Of course, just inverting the mtof, neat solution!

@bocanegra I agree, my mistake, actually what I made was the logarithmic one (the one the advances linearly in the frequency space) and I needed the linear one (the one that advances linearly in the midi notes space)

@ddw_music Nice, that is the type of solution I had in mind, but I was trying to treat the "signal" as the original line that goes from 48 to 84 and then aplying math to that, instead of considering the "signal" as a line in the domain [0,1] and then aplying math to map it to [48, 84]. I believe the general solution that I was seeking is the formula (1) in this answer: https://stackoverflow.com/a/63158920/4286437 (By the way, what I understood from bocanegra wasn't a superexponential, but just that the frequency as we hear, in the world of sensations, would rise in a logarithmic way when the frequency rises linearly)

Hi, I'm stuck in a simple exercise from Loadbang book, which is : "Create a glissando that we hear as linear and one that we hear as logarithmic from C3 to C6." That's my functional linear version:

However, about the logarithmic version (and other generalizations I can think about, like exponential, quadratic, etc...), is there an easier way than manually getting the parameters of a function like A*e^x + B and using expr?

@Obineg Hi, I don't get how a loadbang would solve the issue in the original patch, even with the [t b b]. Where would it be connected?

@ingox Nice, that solves an issue of the previous solution. The $1 was being initialized as 0.

Oh, perfect, my mistake: I thought that every object with a $1 would be instantaneously updated with the value that comes from the first inlet, objects with $2 with the values from the second inlet and so on, even if isolated. And the [t f b] also makes sense, since it's like the number information is lost, transformed into a bang, leaving the creation argument $1 immovable.

Why the left print never updates in this example, always showing 10 20, the creation arguments?

"Thus, the left-most [delay] will output a "bang" a fraction of a second sooner than the right [delay]. This causes the right most delay to reset its timer"

Yes! Actually you did help me . That's exactly the point of my confusion: when the lower delay receives two bangs "at the same time" but in different orders. The delay is reset in one case but not in the other. The last section of your link was very helpful: visualizing it as a tree with its rightmost branch being executed first makes it clear to think about the order. Thanks.