[PD] Fwd: Variable number of objects?

Jaime Oliver jaime.oliver2 at gmail.com
Fri Sep 30 18:32:32 CEST 2011 

If you're going to wire them why not just create specific send messages? 

Give every abstraction an index and send only to that one:

[r $1-foo]
|
etc

J

On Sep 30, 2011, at 4:13 AM, "Ingo" <ingo at miamiwave.com> wrote:

> I actually do switch off everything possible with a spigot but the
> [receive]s do still need to check if the [send] message is meant to be for
> them or not. So once you get too many [receive] objects while sending a lot
> it CAN slow down the patch quite a bit. But unfortunately that only starts
> showing up once the patch is so big that it takes forever to replace all of
> the [receive] objects with wired connections.
> 
> So for now I'm trying to use wires wherever possible to address data only to
> the object that needs the data rather than having ten thousands of objects
> checking hundreds of times per second if the data is meant to be for them or
> not.
> 
> Ingo
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Jaime Oliver [mailto:jaime.oliver2 at gmail.com]
>> Gesendet: Freitag, 30. September 2011 05:04
>> An: Ingo
>> Cc: Jonathan Wilkes; Pd List
>> Betreff: Re: [PD] Fwd: Variable number of objects?
>> 
>> 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)
>

More information about the Pd-list mailing list