@whale-av Ok thanks David, that's what I was expecting.

Hello,

Is there an easy way to compile a patch that makes use of custom abstractions so that these are being embedded in the code instead of called up from external files?

Thanks.

n raised to -1 equals 1/n
n raised to 0 equals 1
n raised to 1 equals n

@jameslo Of course!!! The answer was so obvious, how did I miss it! Told you my maths was rusty as hell!

Here's the answer, for those interested but in worth arithmetical condition than me...

I'm trying to solve the maths behind the lin to log conversion in the sliders properties:

• Give a log slider a (0.1-10) range, and its centre position will be equal to 1
• Give a log slider a (0.01-100) range, and its centre position will still be 1

This is a great behavior for pitch scaling when you want to create a frequency offset of an oscillator in relation to another. For instance, with a (0.1-10) range, you get unison at centre position, +10 octaves at max position and -10 octaves at min position.

I want to recreate a similar behavior by converting a positive signal ranging (0 to n) linearly to a signal ranging (1/n - n) logarithmically.

The function should be something like this I believe:
f(0) = 1/n
f(n/2) = 1
f(n) = n

Did a bit of research and I think the function should look something like: y = a exp (bx).

My maths is a bit rusty I'm afraid. Could you help me solve this problem?

Everything seems to be working fine, fantastic! A great thanks to both of you @whale-av and @jameslo for the help!

@jameslo ok thanks, making some progress. Following your example, I've removed the [block~] object in the throw~ subpatch (I figure there's no need since none of the parent patches are being reblocked) and then changed the block~ in the catch for [block~ 64 1 0.25] (0.5 didn't work, probably because the parent was reblocked at 256, not 128 like in your example).

It seems to work and I've no more error messages, which is good. But there's a very strange new glitch in that the catch~d signal is somehow twice the amplitude of the one being throw~d (it oscillate between -2 and +2). Why would that be in your opinion?

EDIT: got it. My reblocked parent patch needed to be [block~ 256 1 4]. I gather the signal was sent twice between each new blocking of the receiver, hence appearing as if 2 identical signals were being mixed.

I hope changing this to 4 won't somehow break the code I had running already. Will have to do some heavy testing now to make sure the rest of the patch still behaves correctly.

@jameslo When I do that I get no signal (the PWM does not work). I've tried tabwrite~ing both before the throw~ and after the catch~ and this is what I get:

@whale-av I'm not sure I quite get it, even after reading the chapter and your post. Isn't it already what I'm doing there?
For instance, all my [throw~] are in the SrcX routing subpatches, and all my [catch~] too (related to the reblocked Subpatch1). Yet I'm still getting the error message.
I have screenshot a throw/catch pair of subpatches embedded with inlet~/outlet~ connections below:

Hello,

I'm trying to create a modulation matrix for my patch, where I can route a bunch of control signals (LFO, ADSR, etc) to modulate various parameters using a matrix mixer topology (all mod sources can be sent to all destinations, and all destinations can receive a mix of all sources). I am naturally going for the [throw~] and [catch~] object to create one summing bus per destination (16 in total).
But I run into some errors there:

throw~ MO_pulse-width_mod: vector size mismatch
sigcatch summingBus1: unexpected vector size

I have figured out this has to do with DSP block size conflicts, as I have [block~] objects of varying sizes in several sub-patches. However I cannot get my head around DSP block size handling in Pd, and even less how to solve my issue. I have tried putting a number of size-matching [block~] objects on the subpatches containing the [throw~] and [catch~] objects and/or, where the source signal is actually being generated. None worked.

However, I noticed that if I replace [throw~]/[catch~] by {send~]/{receive~] and put a [block~ 64 1 1] in both sub-patches, the conflict is resolved. But using {send~]/{receive~] would greatly complexify the patch so I'd rather stick with [throw~]/[catch~] if I can.

I have tried to draw an accurate hierarchy of my current patch in the hope you may help me figure out where the mismatch occur. It's a tad complex as the modulation sources, the matrix mixer and the modulation destinations are all in different places of my patch. So I'm first using [s~] objects to send the various mod sources to the mod matrix, then use [throw~] objects to send these to the various "destinations" summing buses. I have added info where the signal generators are (~), [s~]/{r~] and {throw~/catch~] are all located in the hierarchy, as well as where some mandatory [block~] objects are (I cannot remove these as it will break my code).
Here it is:

Hope my post and this graph somehow makes sense...

@ingox Fantastic, cheers!