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" <[email protected]> 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:[email protected]] >> 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 <[email protected]> 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:[email protected]] >>>> 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 <[email protected]> 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 <[email protected]> >>>>>>> To: 'Roman Haefeli' <[email protected]>; 'Ludwig Maes' >>>>>> <[email protected]> >>>>>>> Cc: 'Pd List' <[email protected]> >>>>>>> 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: [email protected] [mailto:[email protected]] 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 <[email protected]> >>>>>>>> > Date: 28 September 2011 19:29 >>>>>>>> > Subject: Re: [PD] Variable number of objects? >>>>>>>> > To: Ingo <[email protected]> >>>>>>>> > >>>>>>>> > >>>>>>>> > 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> [email protected] mailing list >>>>>>>> UNSUBSCRIBE and account-management -> >>>>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>>> >>>>>>> _______________________________________________ >>>>>>> [email protected] mailing list >>>>>>> UNSUBSCRIBE and account-management -> >>>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> [email protected] 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) > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
