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?

@seb-harmonik.ar said:

of course [expr] is also far more convenient and clean from a language perspective.

The funny contradiction here is that Max/Pd were supposed to make programming more approachable for people who don't like code, but the canonical way to write math in Max/Pd is... awful. It's really painful, and it's not any less fiddly than code in the end (perhaps even more fiddly, e.g. 1/x).

Tbh I sometimes think this alone is enough to make graphical patching only a partially successful project. It's obviously successful in the sense that it appeals very deeply to a large number of people -- but can it be said to be easier than code? At first, yes, but perhaps not always so, in the long run.

hjh

@ddw_music agreed. there are some things that graphical programming makes really difficult, though it's generally more intuitive at first especially for audio imo

@seb-harmonik.ar said:

@ddw_music agreed. though it's generally more intuitive at first especially for audio imo

At some point, I realized that code requires you to have a mental map of the expected state at every step in the code sequence. Without this mental map, basically you're just throwing tokens at the wall and hoping something sticks. It's a little easier to visualize with patch cables, except for the ever-present risk of spaghetti patching (and this risk increases dramatically as algorithmic complexity rises).

But, though state is invisible in code, it scales up easily to very complex processes in a way that I don't see happen in patching very often. (Perhaps patching seems more intuitive because it implicitly discourages complexity.)

For audio, I'd agree in that new SC users do have trouble visualizing the signal graphs when they're specified in code. (But it's much easier to create large numbers of parallel chains in code, too.)

hjh

while using mtof and ftom gives you musically useful curves, these readymade objects do not really teach you how to perform arbitrary distortion of input ranges.

the screenshots above (untested, i just made this up from memory) will need to know the last note on notenumber and the current note on notenumber, and then it performs the following tasks:

• scale the (linear) input range (in note numbers) down to 0.-1.

• perform a distortion on that linear range of 0.-1.

• scale back to the note numbers you need.

it is always good practice to

• do anything you do to frequency (vibrato, pitch wheel, randomisation, offsets and transpositions, relational functions, range distortion for portamento effects) on the linear layer

• as soon as it is unavoidable, go to signal domain

• then use mtof~ only "inside" the oscillator /generator.

because, beside other things, it is easier to think in note numbers than in hertz.

oh yes.

and to get the inverse direction of the distortion, simply inverse that 0.-1 range by * -1, + 1, one time before the distortion function, and one time after it.

tanh can also be fun for portamento glides.

insert this function in the middle of the patch:

*~ 7. 594308
tanh~