---------- 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?
On 28 September 2011 18:33, Ingo ingo@miamiwave.com wrote:
To my experience there will be definitely audio dropouts with dynamic voice creation. In the case of my rather complex patch (with currently only 8 voices) I have to wait up to ten seconds until the patch is ready again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow. Simpler synth voices might be faster, though.
I think it is much better to create as many voices as needed beforehand and turn unused voices off with the [switch~] object.
Ingo
Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects?
Im not sure what the best way is to instantiate variable number of objects, for example consider polysynth.pd:
Theres a fixed number of manually placed voices, suppose I want to have the top patch to contain a counter through which one may increase or decrease the number of voices, how would I go about that (without manually placing a load of voices and disabling them...)?
Whats the vanilla way to do this? Whats the pd-extended way to do this? ...
Perhaps better rephrased: how does one use arrays of .pd objects? or variable length vectors/lists?
On 28 September 2011 19:29, Ludwig Maes ludwig.maes@gmail.com 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?
On 28 September 2011 18:33, Ingo ingo@miamiwave.com wrote:
To my experience there will be definitely audio dropouts with dynamic voice creation. In the case of my rather complex patch (with currently only 8 voices) I have to wait up to ten seconds until the patch is ready again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow. Simpler synth voices might be faster, though.
I think it is much better to create as many voices as needed beforehand and turn unused voices off with the [switch~] object.
Ingo
Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects?
Im not sure what the best way is to instantiate variable number of objects, for example consider polysynth.pd:
Theres a fixed number of manually placed voices, suppose I want to have the top patch to contain a counter through which one may increase or decrease the number of voices, how would I go about that (without manually placing a load of voices and disabling them...)?
Whats the vanilla way to do this? Whats the pd-extended way to do this? ...
Le 2011-09-28 à 19:31:00, Ludwig Maes a écrit :
Perhaps better rephrased: how does one use arrays of .pd objects? or variable length vectors/lists?
[#many tgl] makes mosaïcs of toggles, [#many nbx] makes mosaïcs of numberboxes, like this :
http://gridflow.ca/help/%23many-help.html
It's probably not anywhere close to what you are interested in, but it's an example of something quite different from what the other automatic dynamic patchers are doing : it's GOP, it's 2-D, it has a properties dialogue, etc.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
I don't know if I posted this to this thread already, but try out the
'many' lib, it has a few different approaches to managing many
instances of Pd objects.
http://download.puredata.info/many
.hc
On Sep 28, 2011, at 1:31 PM, Ludwig Maes wrote:
Perhaps better rephrased: how does one use arrays of .pd objects? or
variable length vectors/lists?On 28 September 2011 19:29, Ludwig Maes ludwig.maes@gmail.com 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?
On 28 September 2011 18:33, Ingo ingo@miamiwave.com wrote: To my experience there will be definitely audio dropouts with
dynamic voice creation. In the case of my rather complex patch (with currently
only 8 voices) I have to wait up to ten seconds until the patch is ready
again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow.
Simpler synth voices might be faster, though.I think it is much better to create as many voices as needed
beforehand and turn unused voices off with the [switch~] object.Ingo
Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im
Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects?Im not sure what the best way is to instantiate variable number of
objects, for example consider polysynth.pd:Theres a fixed number of manually placed voices, suppose I want to
have the top patch to contain a counter through which one may increase or
decrease the number of voices, how would I go about that (without manually
placing a load of voices and disabling them...)?Whats the vanilla way to do this? Whats the pd-extended way to do
this? ...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
From: Ludwig Maes ludwig.maes@gmail.com To: Pd List pd-list@iem.at Sent: Wednesday, September 28, 2011 1:31 PM Subject: Re: [PD] Variable number of objects?
Perhaps better rephrased: how does one use arrays of .pd objects? or variable length vectors/lists?
Variable list message: [list] family objects and the list-abs library
Variable length glists: dynamic patching (search the list and see patches in doc/manuals/pd-msg/ )
Variable length vectors: hm.. not sure what this means ( [block~] ? )
Arrays of .pd objects: I don't think it's possible, but I'd love to do something like that with data structures.
You'd have a "template" subpatch, define a field of the struct as type "glist", then use that struct as the
template for an array:
[pd my-template-patch]
[struct foo float y glist my-template-patch]
[filledpolygon 900 0 1 -5 -5 5 -5 5 5 -5 5]
Then the container struct:
[struct bar float x float y array a foo]
[plot a 0 1 0 0 20]
Now when you create a scalar "bar", each element of array "a" would have a little red rectangle,
a yvalue, and a glist copied from the contents of my-template-patch.
The issues are:
- for maximum expressivity you'd need a way for each element's glist to have access to it's other
members (like "y" in the above example).
- I'm not sure how tilde objects inside "my-template-patch" would work when you increase the size of the array.
(Seems like you'd have the same problem as with current dynamic-patching where you need to turn off dsp
before the new objects get created, then turn it back on once they exist.
-Jonathan
On 28 September 2011 19:29, Ludwig Maes ludwig.maes@gmail.com 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?
On 28 September 2011 18:33, Ingo ingo@miamiwave.com wrote:
To my experience there will be definitely audio dropouts with dynamic voice
creation. In the case of my rather complex patch (with currently only 8 voices) I have to wait up to ten seconds until the patch is ready again for playback. I am using a 3.2 GHz Athlon II X2 which is not that slow. Simpler synth voices might be faster, though.
I think it is much better to create as many voices as needed beforehand and turn unused voices off with the [switch~] object.
Ingo
Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Ludwig Maes Gesendet: Mittwoch, 28. September 2011 17:56 An: Pd List Betreff: [PD] Variable number of objects?
Im not sure what the best way is to instantiate variable number of objects, for example consider polysynth.pd:
Theres a fixed number of manually placed voices, suppose I want to have the top patch to contain a counter through which one may increase or decrease the number of voices, how would I go about that (without manually placing a load of voices and disabling them...)?
Whats the vanilla way to do this? Whats the pd-extended way to do this? ...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-09-28 à 19:29:00, Ludwig Maes a écrit :
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...)
BTW, IIRC, PureData's DSP compiler just relies on realloc() being really fast all of the time. I don't know whether there's any version of libc that contains an older-style realloc() that could make turning DSP on really slow... I haven't seen one in a long time.
If anyone can identify such a problem, I know how to fix it... it's not very hard.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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
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
I just added the [; pd dsp 0( when starting to creat voices to speed it up and eliminated the 17 voices limit of the patch.
Maybe it's useful for somebody.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von Ingo Gesendet: Donnerstag, 29. September 2011 11:33 An: 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: 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
I made some more changes and added some help information to the voice creation patch so you can simple use a float to add voices and 0 to clear all voices. There are wired inlets for the voices now.
Hope it's helpful for anybody!
Ingo
-----Ursprüngliche Nachricht----- Von: Ingo [mailto:ingo@miamiwave.com] Gesendet: Donnerstag, 29. September 2011 12:02 An: 'Ingo'; 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: AW: [PD] Fwd: Variable number of objects?
I just added the [; pd dsp 0( when starting to creat voices to speed it up and eliminated the 17 voices limit of the patch.
Maybe it's useful for somebody.
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag
von
Ingo Gesendet: Donnerstag, 29. September 2011 11:33 An: 'Roman Haefeli'; 'Ludwig Maes' Cc: 'Pd List' Betreff: 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
What happens if you just have the maximum number of voices you think you'd ever need and
[switch~] them on and off as needed?
Since you have a large patch, I'd be curious to know how much memory is taken up by
having the switched off voices just sitting there.
-Jonathan
----- Original Message -----
From: Ingo ingo@miamiwave.com To: 'Roman Haefeli' reduzent@gmail.com; 'Ludwig Maes' ludwig.maes@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-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
On Thu, Sep 29, 2011 at 1:17 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
What happens if you just have the maximum number of voices you think you'd ever need and [switch~] them on and off as needed?
In my case it takes a bit long to load the patch, but if the voices are switched off then they don't hurt cpu usage at all.
In Pd this is definitely the way to go unless you don't care about audio dropouts...
J
Since you have a large patch, I'd be curious to know how much memory is taken up by
having the switched off voices just sitting there.
-Jonathan
----- Original Message -----
From: Ingo ingo@miamiwave.com To: 'Roman Haefeli' reduzent@gmail.com; 'Ludwig Maes' ludwig.maes@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-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
What happens if you just have the maximum number of voices you think you'd ever need and [switch~] them on and off as needed?
Since you have a large patch, I'd be curious to know how much memory is taken up by having the switched off voices just sitting there.
-Jonathan
That's what I am doing anyway. Memory is not an issue. There is obviously no change in memory by simply switching the voices on or off. After I got most of the control stuff as well as a large number of the [receive] objects out of the way the patch doesn't need that much cpu time at all unless the voices are turned on and playing.
Now that the switched off voices are not hardly doing anything anymore there is no more need to adjust the voice number as it was the case before I got rid of a whole bunch of [receive] objects and cut most of the control messages when the [switch~] object gets turned off. In certain cases I can limit the voice number with different [poly] objects.
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.
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
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
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)
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@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@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)
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@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@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@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)
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
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@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@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@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@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' ludwig.maes@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-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)
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
Le 2011-09-30 à 12:32:00, Jaime Oliver a écrit :
If you're going to wire them why not just create specific send messages?
Yes, that's much faster.
But keep in mind that making large amounts of symbols makes gensym become gradually slower, which slows down interpreting $1-foo in all messageboxes, for example. The problem appears gradually as you have several thousand symbols at once, but I have not benchmarked to see how much it changes the balance of things. I think that send/receive will be almost always faster than anything else.
[route] is of intermediate speed, faster than [spigot] by a constant ratio for an average of many different lookups. [route] is faster than [spigot] for high indices (right-side outlets), and even faster for lower indices (left-side outlets). [s]/[r] is fast like one of the smallest indices of [route].
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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@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@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@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@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' > ludwig.maes@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-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)
-- Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel) 858 202 1522 (home)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2011 04:48 AM, Ingo wrote:
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.
this is not how send/receive work in Pd. in general, Pd's messaging system works in a "push" manner, where data is pushed from one object to the next, rather than a "pull" manner, where an object requests a message from the previous one.
therefore, [receive] need not care which [send]s are attached to it.
then, [send] need not search for attached [receive]s either, because the send-symbol will maintain a linked list of all attached receivers. going through the linked list for dispatching a message is quite fast.
gfdstm IOhannes
Ok, it looks like I was misunderstanding the way how the [send] / [receive] is working.
But then I am still wondering why I got a lot of performance boost after replacing the [send] / [receive] with wired connections?
Ingo
-----Ursprüngliche Nachricht----- Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von IOhannes m zmölnig Gesendet: Samstag, 1. Oktober 2011 18:18 An: pd-list@iem.at Betreff: Re: [PD] Fwd: Variable number of objects?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2011 04:48 AM, Ingo wrote:
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.
this is not how send/receive work in Pd. in general, Pd's messaging system works in a "push" manner, where data is pushed from one object to the next, rather than a "pull" manner, where an object requests a message from the previous one.
therefore, [receive] need not care which [send]s are attached to it.
then, [send] need not search for attached [receive]s either, because the send-symbol will maintain a linked list of all attached receivers. going through the linked list for dispatching a message is quite fast.
gfdstm IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6HPTEACgkQkX2Xpv6ydvQ8bQCfStNUi4fxyCOe2ZK3uvHtN7BG p+oAoNqIIRG/oaeeD7Qjoi2mmgkNXcZV =Chc9 -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-10-01 à 04:48:00, Ingo a écrit :
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.
Which implementation of Pd actually works like that ?
(ever heard of Hashtables ?)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/30/2011 05:03 AM, Jaime Oliver wrote:
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,
it sure has.
nevertheless, i usually can be neglected, so i would suggest the same to save some CPU power down the patch.
[line] can be become quite expensive when used massively, and a switched-off [line~] that is fed with new values can also make problems (at least it did a while ago; dunno whether this has been fixed)
fgmasdr IOhannes
Le 2011-09-29 à 19:41:00, Ingo a écrit :
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.
I wonder what kind of ears it takes to listen to something so complex... rather, what kind of brain lobes it takes.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-10-01 à 04:14:00, Ingo a écrit :
I wonder what kind of ears it takes to listen to something so complex... rather, what kind of brain lobes it takes.
It takes a regular pair of ears - one on the left side and one on the right side!
per head ?
how many heads do you have ?
e.g. quadraphonic : http://upload.wikimedia.org/wikipedia/en/7/72/Mark_Wing-Davey_as_Zaphod_Beeb...
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Actually, I do have a twin brother. I could almost compete with the guy on the picture. Since I am using 3 stereo outs I could maybe top that with around something like six ears. I'll have to see how quickly I can clone myself! I'm not sure if Pd supports cloning of the listener with the current version?
Maybe with an abstraction like:
[dac~]
|
[ear~ $1] [ear~ $2]
Then do some dynamic patching?
Ingo
-----Ursprüngliche Nachricht----- Von: Mathieu Bouchard [mailto:matju@artengine.ca] Gesendet: Montag, 3. Oktober 2011 19:38 An: Ingo Cc: 'Pd List' Betreff: Re: AW: [PD] Fwd: Variable number of objects?
Le 2011-10-01 à 04:14:00, Ingo a écrit :
I wonder what kind of ears it takes to listen to something so
complex...
rather, what kind of brain lobes it takes.
It takes a regular pair of ears - one on the left side and one on the
right
side!
per head ?
how many heads do you have ?
e.g. quadraphonic : http://upload.wikimedia.org/wikipedia/en/7/72/Mark_Wing- Davey_as_Zaphod_Beeblebrox.jpg
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-09-29 à 10:17:00, Jonathan Wilkes a écrit :
Since you have a large patch, I'd be curious to know how much memory is taken up by having the switched off voices just sitting there.
It's not easy to know how much memory is taken by a bunch of small mallocs. If you use getbytes() you have some idea of what's going on, but it doesn't count the malloc accounting info that only malloc()/free() usually know about, and it doesn't count the overallocation that malloc() might do in order to make its life easier and make gradual realloc() faster. Then it also doesn't count the overallocation of the memory zones so that brk() or mmap() or mremap() doesn't have to be called as often, which means that when you look at the process size in a process monitor (ps or top or other) the difference you might see will not be accurate at all... even if you manage to get it in bytes 4k-blocks instead of megabytes.
So, if you really want to know the memory usage for a certain part of pd, make sure that everything uses getbytes() instead of malloc()/new/etc, and then try to find a formula that can tell you how much extra you should count, and call it from getbytes() and freebytes() in order to keep accurate statistics.
E.g. I recall that will the Perl Allocator that was being used by Perl in the late 90's, you had to add sizeof(void*) to your byte request, and then round to the next power of two. From this info you can then write :
size_t real_size (size_t n) {return 1<<highest_bit(n+sizeof(void *));}
highest_bit is a function that finds the position of the highest «1» bit of an int. I have such a function in gridflow.h :
#define Z(N) if ((x>>N)&(((typeof(x))1<<N)-1)) { x>>=N; i+=N; } static int highest_bit(uint32 x) {int i=0; Z(16)Z(8)Z(4)Z(2)Z(1)return i;} #undef Z
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-09-30 à 12:01:00, Mathieu Bouchard a écrit :
size_t real_size (size_t n) {return 1<<highest_bit(n+sizeof(void *));}
erratum :
size_t real_size (size_t n) {return 2<<highest_bit(n+sizeof(void *)-1);}
because the first version I wrote gets the PREVIOUS-or-equal power, which is nonsense. Doubling that gives the NEXT power, but not next-or-equal, so I subtract 1 to compensate for that.
BTW, I haven't looked at modern glibc mallocs. I suspect it might do things similar to the Perl Allocator nowadays, though I have not checked, and it's probably not documented (?). Chances are that it's a different formula, anyway.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Hans-Christoph Steiner -
Ingo -
IOhannes m zmölnig -
Jaime Oliver -
Jonathan Wilkes -
Ludwig Maes -
Mathieu Bouchard -
Roman Haefeli