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@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@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@miamiwave.com To: 'Roman Haefeli' reduzent@gmail.com; 'Ludwig Maes'
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-bounces@iem.at [mailto:pd-list-bounces@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@gmail.com > Date: 28 September 2011 19:29 > Subject: Re: [PD] Variable number of objects? > To: Ingo ingo@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)