[PD] Fwd: Variable number of objects?

Ingo ingo at miamiwave.com
Sat Oct 1 04:48:20 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

Every [receive] will have to check if any [send] message is meant to be for
this particular [receive]. It will have to check if the header of the [send]
matches the header of the [receive] until the first character doesn't match
anymore. Then it will abort checking and the next [receive] will start
checking, and so on ...
I can't see how this can be done without taxing the cpu.

Having several hundred of messages being sent per second going to several
hundred [receives] multiplied by the voice number will add up to many
millions of these checks per second. After a certain amount of objects and
input data this definitely takes too much time for realtime low latency
playing when using high voice counts. It may not affect anything until the
number of [send/receive] exceeds a certain number. Getting rid of the
[send/receive]s at this point takes a ridiculous amount of time (I'm still
not done after several months but getting much better results already).
Using dollar arguments only adds a number to the [receive] and doesn't keep
it from having to do the checking.

That's the reason why I try to avoid [send/receive] objects wherever
realtime playing is involved. I still use them, but only for non realtime
editing purposes. But there is still a tendency for audio dropouts.

Ingo


> 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