[PD] Fwd: Variable number of objects?

Ingo ingo at miamiwave.com
Thu Sep 29 18:11:08 CEST 2011


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 at 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 at iem.at [mailto:pd-list-bounces at 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 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: create_voices.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110929/730f1706/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: samplevoice.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110929/730f1706/attachment-0001.asc>


More information about the Pd-list mailing list