• tomatoKetchup

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

posted in technical issues read more
• tomatoKetchup

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.

posted in technical issues read more
• tomatoKetchup

``````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...

posted in technical issues read more
• tomatoKetchup

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?

posted in technical issues read more
• tomatoKetchup

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

posted in technical issues read more
• tomatoKetchup

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

posted in technical issues read more
• tomatoKetchup

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

posted in technical issues read more
• tomatoKetchup

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

posted in technical issues read more
• tomatoKetchup

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...

posted in technical issues read more
• tomatoKetchup

@ingox Fantastic, cheers!

posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!