[PD] Fwd: Variable number of objects?

Ingo ingo at miamiwave.com
Thu Sep 29 19:41:36 CEST 2011


> What happens if you just have the maximum number of voices you think you'd
> ever need and [switch~] them on and off as needed?
> 
> Since you have a large patch, I'd be curious to know how much memory is
> taken up by having the switched off voices just sitting there.
> 
> -Jonathan

That's what I am doing anyway. Memory is not an issue. There is obviously no
change in memory by simply switching the voices on or off. After I got most
of the control stuff as well as a large number of the [receive] objects out
of the way the patch doesn't need that much cpu time at all unless the
voices are turned on and playing.

Now that the switched off voices are not hardly doing anything anymore there
is no more need to adjust the voice number as it was the case before I got
rid of a whole bunch of [receive] objects and cut most of the control
messages when the [switch~] object gets turned off. In certain cases I can
limit the voice number with different [poly] objects.

One shouldn't underestimate the cpu load when several hundreds of midi
controllers per second are modulating hundreds of parameters and the get
multiplied by 16 voices constantly because the control messages are still
active all of the time.

Ingo


> ----- Original Message -----
> > From: Ingo <ingo at miamiwave.com>
> > To: 'Roman Haefeli' <reduzent at gmail.com>; 'Ludwig Maes'
> <ludwig.maes at gmail.com>
> > Cc: 'Pd List' <pd-list at iem.at>
> > Sent: Thursday, September 29, 2011 5:33 AM
> > Subject: 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 at iem.at [mailto:pd-list-bounces at 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 at gmail.com>
> >>  > Date: 28 September 2011 19:29
> >>  > Subject: Re: [PD] Variable number of objects?
> >>  > To: Ingo <ingo at 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 at iem.at mailing list
> >>  UNSUBSCRIBE and account-management ->
> >>  http://lists.puredata.info/listinfo/pd-list
> >
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >




More information about the Pd-list mailing list