I made some more changes and added some help information to the voice creation patch so you can simple use a float to add voices and 0 to clear all voices. There are wired inlets for the voices now.
Hope it's helpful for anybody!
Ingo
-----Ursprüngliche Nachricht----- Von: Ingo [mailto:ingo@miamiwave.com] Gesendet: Donnerstag, 29. September 2011 12:02 An: 'Ingo'; 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: AW: [PD] Fwd: Variable number of objects?
I just added the [; pd dsp 0( when starting to creat voices to speed it up and eliminated the 17 voices limit of the patch.
Maybe it's useful for somebody.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag
von
Ingo Gesendet: Donnerstag, 29. September 2011 11:33 An: 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: Re: [PD] Fwd: Variable number of objects?
Actually, I just tried again to simply copy a couple of voices and it
only
took a fraction of a second with a very short dropout - even with the
dsp
on.
I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned.
So it looks like dynamic patching of voices isn't "that" much of a
problem
here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned
it.
I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are
using
wired inlets you will have to dynamically add the connections of course.
I added a cut & paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag
von
Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects?
On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
---------- Forwarded message ---------- From: Ludwig Maes ludwig.maes@gmail.com Date: 28 September 2011 19:29 Subject: Re: [PD] Variable number of objects? To: Ingo ingo@miamiwave.com
I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction...
How can that take 10 seconds?? I dont see what would cause such a
huge
overhead, i'd expect an increase in computations & memory though
(say
from 10 voices to 11: 10% increase in cpu workload & ram dedicated
to
these voices..., I fail to see what would necessitate a long initialization...)
also, how is it done even with the long delays?
As I understand it, the whole DSP is recompiled whenever it is
changed.
So, if you have a very large patch (and Ingo seems to be an expert in very large patches) and you create another voice, it's easily possible to eat up quite some time.
Also, it's probably much slower the first time, if the voice
abstraction
is built of many other abstractions, which need to be read from disk.
But I guess you are right about the increase in CPU workload _after_
the
DSP graph has been recompiled: A switch from 10 two 11 instances is expected to show only an increase of 10% in CPU usage.
It's been said, that often you can gain quite some time while turning off DSP during dynamic instantiation. But I guess, this makes only a difference when performing several instantiations at the same time.
When
DSP is on, each cycle would cause a complete DSP graph recompilation, whereas when DSP is off, it's only recompiled once (after turning it
on
again).
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list