You're basically limited by RAM, but if you have a big dynamic patching &
sinesum routine on loadbang you might have to wait a few seconds for your
patch to open. Or, if you want you can do the dynamic patching once to get
the patch, and the sinesum routine once as well, and save the contents of
t
I effectively want to have the possibility to give to each note a different
timbre if I want. Thanks for your suggestions, fortunately there are many
compromise solutions possible.
You're mentioning in one of your suggestion I could use 1000 arrays. Let say
that I'm lazy and that in the short te
On 10/08/2015 09:11 PM, Matt Barber wrote:
> Also I can't remember if
> deleting a table already used in dsp triggers a recalculation,
yes, that's the point of tracking tables used in dsp.
gfamdsr
IOhannes
signature.asc
Description: OpenPGP digital signature
_
Dynamic patching is rough but possible. If you try it, you'll want to make
sure not to dynamically patch any tilde objects. Also I can't remember if
deleting a table already used in dsp triggers a recalculation, so it may
not even be worth it.
In your patch the sine weights are hardcoded. Can we a
Thank you all for your help. Matt, Your solutions sounds interesting. I'm not
familiar with block size issues and how the fourier analysis objects work apart
that I know what they do (at least roughly). I guess it's about time I go
deeper into this. I'll start with Miller's book unless you have
I haven't tried this in a while, but it might be worth trying to build a
custom sinesum abstraction that fills the tables manually with an until
loop and then normalizes them. This may take too long, though. There's
probably another solution with [tabsend~] and [tabreceive~] where you write
the w
On 2015-10-08 13:35, Matt Barber wrote:
> In this case the array knows its size and sinesum always requests a size,
> so those could be compared before running an actual resize.
oops, yes of course.
Pd should do that.
i'm sure that what i read in your email this morning is not what you had
writt
In this case the array knows its size and sinesum always requests a size,
so those could be compared before running an actual resize.
On Oct 8, 2015 3:22 AM, "IOhannes m zmoelnig" wrote:
> On 2015-10-08 02:01, Matt Barber wrote:
> > I can't think of a good solution just yet, aside from rewriting
On 2015-10-08 02:01, Matt Barber wrote:
> I can't think of a good solution just yet, aside from rewriting the g_array
> functions to check to see if a resize is actually needed.
>
how would you do that?
Pd does not provide an API to release an array from being used in DSP.
so once an object (or s
This may be an example of something we talked about recently in the forum
with arrays. When you first open the patch, the arrays are not part of any
dsp chain, and you can set them almost with impunity. Once you access them
with [tabread4~], though, any change you make to any of the arrays that
res
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them
in a sub-patch or in "array define" objects (or the old "table") so that
they're not visible. Erasing and re-drawing graphs is much more expensive
than computing them.
Sorry for double posting, there was a typo in my previous message so I'm
sending it again to make sure everything is clear.
Hi list, I’m working on a big patch. I have many audio I/O error and audio
glitch and I’m having a hard time finding why. I’ve done some extensive
troubleshooting yesterday
Hi list, I’m working on a big patch. I have many audio I/O error and audio
glitch and I’m having a hard time finding why. I’ve done some extensive
troubleshooting yesterday but couldn’t pin point the exact cause. I managed to
narrow my problem down to what I find is a weird behaviour (at least f
13 matches
Mail list logo
