[PD] Fwd: Variable number of objects?

[Jaime Oliver]

I see...

What I do is put a spigot right after all receives and the spigot is
controlled by the same messages that control switch~:

[r foo]
|
[spigot 0]
|
...

In this way you'll at least stop using all lines and metros and the
like. I am not entirely sure that having a receive immediately
connected to a [spigot 0] has any computational expense, but if I'm
measuring things correctly they don't. So no need to shut off
receives, just send them to a closed gate....

best,

J

On Thu, Sep 29, 2011 at 10:30 PM, Ingo <ingo at miamiwave.com> wrote:
>> Why would you have control messages going if switch~ is off?
>
> Because the voice gets assigned to a certain midi channel when it receives a
> [noteon] and has to keep receiving all midi controllers on that channel
> until the envelope release has finished. Then the next voice will play on
> that same midi channel. There is nothing that cuts off the control inlets or
> [send/receive]s automatically because the audio gets switched off.
> So when you play 16 notes in a row all 16 voices are set up to receive
> control data on that particular midi channel. Everything in the control
> domain, like LFOs, [metro]s and [line]s keep running and keep calculating
> pitch, volume, filter offsets and so on ...
>
> Turning off the [receive]s would be very complicated if not impossible which
> is why they need to be avoided wherever it can be done. But all of the wired
> inlets can be cut off manually together with the [switch~] and turned back
> on when the next note will play that voice. On top of it all 500 parameters
> need to be updated to the current state of the external control input and
> the current preset data when played anew.
>
> Ingo
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Jaime Oliver [mailto:jaime.oliver2 at gmail.com]
>> Gesendet: Donnerstag, 29. September 2011 19:56
>> An: Ingo
>> Cc: Jonathan Wilkes; Pd List
>> Betreff: Re: [PD] Fwd: Variable number of objects?
>>
>> On Thu, Sep 29, 2011 at 1:41 PM, Ingo <ingo at miamiwave.com> wrote:
>> > 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.
>>
>> Why would you have control messages going if switch~ is off?
>>
>> J
>>
>>
>> >
>> > 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
>> >> >
>> >
>> >
>> > _______________________________________________
>> > Pd-list at iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> >
>>
>>
>>
>> --
>> Jaime E Oliver LR
>>
>> www.jaimeoliver.pe
>>
>> 858 750 0924 (cel)
>> 858 202 1522 (home)
>
>



-- 
Jaime E Oliver LR

www.jaimeoliver.pe

858 750 0924 (cel)
858 202 1522 (home)