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 <i...@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.oliv...@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 <i...@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 <i...@miamiwave.com> >> >> > To: 'Roman Haefeli' <reduz...@gmail.com>; 'Ludwig Maes' >> >> <ludwig.m...@gmail.com> >> >> > Cc: 'Pd List' <pd-list@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-boun...@iem.at [mailto:pd-list-boun...@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.m...@gmail.com> >> >> >> > Date: 28 September 2011 19:29 >> >> >> > Subject: Re: [PD] Variable number of objects? >> >> >> > To: Ingo <i...@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@iem.at mailing list >> >> >> UNSUBSCRIBE and account-management -> >> >> >> http://lists.puredata.info/listinfo/pd-list >> >> > >> >> > _______________________________________________ >> >> > Pd-list@iem.at mailing list >> >> > UNSUBSCRIBE and account-management -> >> >> > http://lists.puredata.info/listinfo/pd-list >> >> > >> > >> > >> > _______________________________________________ >> > Pd-list@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) _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list