@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!

Hello,

Is there a way in PD to send a bang whenever the "DSP" switch is ticked ON (or OFF) on the console window?
Cheers.

Clever.

@lacuna said:

To avoid duplicates, rename your arrays with $0-arrayname

I've seen load of examples and people's patches using $0-xxxxx as array names, never quite understood if there was any reason why. Could you expand on what that does exactly or point me to some documentation explaining about this tag?

EDIT: nevermind, found it.

@whale-av Alright! I've misunderstood what bound messages did. Though they limited the actual values to be computed. Thanks for clearing this up.

If you create an Array and change its size using [array size] messages, the canvas (or "graph") is also rescaled accordingly so that it displays the new range of values from the array along it full width.

However when you tie more than one array to the canvas and resize both arrays, the canvas does not rescale anymore. I understand this is to deal with the fact that the 2 arrays might have different sizes and this design makes sense.

In this case, knowing that my 2 arrays will always both have the same size (even if I'm to change said size as part of my code), is there a way to resize the canvas separately then?

So here's my issue.

I'm working on a patch and have been saving versions of it. On V3 things started becoming glitchy and I want to figure out what part of the patch causes that. So I made a return into V2 which has a lot less code and is working fine. I want to have then both opened and start adding the bits of code from V3 to V2 one at a time to isolate the culprit. But in order to do this I need PD not to process V3 at all because it obviously does not like that all my arrays are duplicated.

Is there a way to tell PD to open a patch but not process it (and I mean not only having DSP OFF for the patch but also ignore things like missing arrays and such) while still having another patch open and processed normally?

Thanks for helping!

@ingox Ah yeah, thanks!

@ingox I'm trying to decipher your code. What does the "const 0" in the message box do exactly? Never come across that and can't find it in the documentation.

@ingox I see, thanks for the clarification.

@ingox You are right on this one, this would save some computing resources. I'll try your idea.

EDIT: I see you have posted 2 slightly different versions. Which one is more optimised?