Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît
Sorry for double posting, there was a typo in my previous message so I'm sending it again to make sure everything is clear. Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier <benoitfortier@yahoo.ca> a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm sending it again to make sure everything is clear. Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier <benoitfortier@yahoo.ca> a écrit :Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ok here is my simplified patch. First, if you click the top bang, it outputs 50 notes (at once!) without a single glitch, at least on my computer (MAC mini late 2012 quad core 2.6 mhz i7, osx yosemite, 16gig ram). Then if you click the second bang below on the left, even if it outputs just 2 (you can change this number if two doesn't produce audio errors on your computer) notes at a time, it produces almost all the time I/O errors and audio dropout. There's 50 arrays in the patch and 350 voices... So can anyone think of the reason why the first time the arrays are sent a sinesum message everything works fine, but the second time it produces so many errors? Thank you for your help! Benoît Fortier
Le mercredi 7 octobre 2015 16h01, Miller Puckette <msp@ucsd.edu> a écrit :
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm sending it again to make sure everything is clear. Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier benoitfortier@yahoo.ca a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This may be an example of something we talked about recently in the forum with arrays. When you first open the patch, the arrays are not part of any dsp chain, and you can set them almost with impunity. Once you access them with [tabread4~], though, any change you make to any of the arrays that resizes them will trigger Pd to recalculate the ugen graph, and sinesum has an implicit resize. Thus it's doing the recalc 2 times when you change two of the tables, and 50 times if you change all 50).
If you switch the order of the [t f f] outlets after the [mod 50] so that the spectra get written just after starting tabreading (but at the same logical time, which wouldn't affect output were it not for the graph recalculation), you'll get the error right away.
I can't think of a good solution just yet, aside from rewriting the g_array functions to check to see if a resize is actually needed.
Matt
On Wed, Oct 7, 2015 at 7:01 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Ok here is my simplified patch. First, if you click the top bang, it outputs 50 notes (at once!) without a single glitch, at least on my computer (MAC mini late 2012 quad core 2.6 mhz i7, osx yosemite, 16gig ram). Then if you click the second bang below on the left, even if it outputs just 2 (you can change this number if two doesn't produce audio errors on your computer) notes at a time, it produces almost all the time I/O errors and audio dropout. There's 50 arrays in the patch and 350 voices... So can anyone think of the reason why the first time the arrays are sent a sinesum message everything works fine, but the second time it produces so many errors?
Thank you for your help!
Benoît Fortier
Le mercredi 7 octobre 2015 16h01, Miller Puckette msp@ucsd.edu a écrit :
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm
sending it again to make sure everything is clear.
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier <benoitfortier@yahoo.ca> a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-10-08 02:01, Matt Barber wrote:
I can't think of a good solution just yet, aside from rewriting the g_array functions to check to see if a resize is actually needed.
how would you do that? Pd does not provide an API to release an array from being used in DSP. so once an object (or somebody else) claims to use the object, you have no way to find out whether someone is actually using it (apart from vivisecting each object or using a plasma ball).
a good start would be to add a garray_unusedindsp() function... ah no i've already written that [1].
fgmasdr IOhannes
[1] http://lists.puredata.info/pipermail/pd-list/2015-09/111520.html
In this case the array knows its size and sinesum always requests a size, so those could be compared before running an actual resize. On Oct 8, 2015 3:22 AM, "IOhannes m zmoelnig" zmoelnig@iem.at wrote:
On 2015-10-08 02:01, Matt Barber wrote:
I can't think of a good solution just yet, aside from rewriting the
g_array
functions to check to see if a resize is actually needed.
how would you do that? Pd does not provide an API to release an array from being used in DSP. so once an object (or somebody else) claims to use the object, you have no way to find out whether someone is actually using it (apart from vivisecting each object or using a plasma ball).
a good start would be to add a garray_unusedindsp() function... ah no i've already written that [1].
fgmasdr IOhannes
[1] http://lists.puredata.info/pipermail/pd-list/2015-09/111520.html
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-10-08 13:35, Matt Barber wrote:
In this case the array knows its size and sinesum always requests a size, so those could be compared before running an actual resize.
oops, yes of course. Pd should do that.
i'm sure that what i read in your email this morning is not what you had written.
fjmasdrt IOhannes
I haven't tried this in a while, but it might be worth trying to build a custom sinesum abstraction that fills the tables manually with an until loop and then normalizes them. This may take too long, though. There's probably another solution with [tabsend~] and [tabreceive~] where you write the weights in a table and then use use an ifft to tabsend~ the result to the table you're reading from. I haven't thought it through - the blocking would be tricky.
On Wed, Oct 7, 2015 at 7:01 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Ok here is my simplified patch. First, if you click the top bang, it outputs 50 notes (at once!) without a single glitch, at least on my computer (MAC mini late 2012 quad core 2.6 mhz i7, osx yosemite, 16gig ram). Then if you click the second bang below on the left, even if it outputs just 2 (you can change this number if two doesn't produce audio errors on your computer) notes at a time, it produces almost all the time I/O errors and audio dropout. There's 50 arrays in the patch and 350 voices... So can anyone think of the reason why the first time the arrays are sent a sinesum message everything works fine, but the second time it produces so many errors?
Thank you for your help!
Benoît Fortier
Le mercredi 7 octobre 2015 16h01, Miller Puckette msp@ucsd.edu a écrit :
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm
sending it again to make sure everything is clear.
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier <benoitfortier@yahoo.ca> a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thank you all for your help. Matt, Your solutions sounds interesting. I'm not familiar with block size issues and how the fourier analysis objects work apart that I know what they do (at least roughly). I guess it's about time I go deeper into this. I'll start with Miller's book unless you have an other suggestion. Maybe I'm being naive, but what about dynamic patching? Could it be possible to create (and delete) tables on the fly depending of my needs? I find it very hard to find a good documentation about dynamic patching on the web so right now I can hardly experiment with this. Where could I start? Benoît Fortier
Le jeudi 8 octobre 2015 13h16, Matt Barber <brbrofsvl@gmail.com> a écrit :
I haven't tried this in a while, but it might be worth trying to build a custom sinesum abstraction that fills the tables manually with an until loop and then normalizes them. This may take too long, though. There's probably another solution with [tabsend~] and [tabreceive~] where you write the weights in a table and then use use an ifft to tabsend~ the result to the table you're reading from. I haven't thought it through - the blocking would be tricky. On Wed, Oct 7, 2015 at 7:01 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Ok here is my simplified patch. First, if you click the top bang, it outputs 50 notes (at once!) without a single glitch, at least on my computer (MAC mini late 2012 quad core 2.6 mhz i7, osx yosemite, 16gig ram). Then if you click the second bang below on the left, even if it outputs just 2 (you can change this number if two doesn't produce audio errors on your computer) notes at a time, it produces almost all the time I/O errors and audio dropout. There's 50 arrays in the patch and 350 voices... So can anyone think of the reason why the first time the arrays are sent a sinesum message everything works fine, but the second time it produces so many errors? Thank you for your help! Benoît Fortier
Le mercredi 7 octobre 2015 16h01, Miller Puckette <msp@ucsd.edu> a écrit :
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm sending it again to make sure everything is clear. Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier benoitfortier@yahoo.ca a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dynamic patching is rough but possible. If you try it, you'll want to make sure not to dynamically patch any tilde objects. Also I can't remember if deleting a table already used in dsp triggers a recalculation, so it may not even be worth it.
In your patch the sine weights are hardcoded. Can we assume that won't be the case ultimately, and that each of the notes would have a potentially different timbre (and pitch, etc.)? The only other thing I can think of would be to drop 32 oscillators into each of your instances, and then just send the desired weights as amplitude multipliers to the oscillators (you'd have to take care of normalizing manually). That's annoying, but since you're [switch~]ing things off anyway when they aren't playing, it's not out of the realm of possibility. Or, if you're planning on constraining the timbres in a particular way, it wouldn't be impossible to calculate all of the different timbres you're going to use when the patch loads. If there's some randomness, you could dynamically patch 1000 tables with different weightings, and then just have the note choose from among the 1000.
On Thu, Oct 8, 2015 at 2:38 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Thank you all for your help. Matt, Your solutions sounds interesting. I'm not familiar with block size issues and how the fourier analysis objects work apart that I know what they do (at least roughly). I guess it's about time I go deeper into this. I'll start with Miller's book unless you have an other suggestion.
Maybe I'm being naive, but what about dynamic patching? Could it be possible to create (and delete) tables on the fly depending of my needs? I find it very hard to find a good documentation about dynamic patching on the web so right now I can hardly experiment with this. Where could I start?
Benoît Fortier
Le jeudi 8 octobre 2015 13h16, Matt Barber brbrofsvl@gmail.com a écrit :
I haven't tried this in a while, but it might be worth trying to build a custom sinesum abstraction that fills the tables manually with an until loop and then normalizes them. This may take too long, though. There's probably another solution with [tabsend~] and [tabreceive~] where you write the weights in a table and then use use an ifft to tabsend~ the result to the table you're reading from. I haven't thought it through - the blocking would be tricky.
On Wed, Oct 7, 2015 at 7:01 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Ok here is my simplified patch. First, if you click the top bang, it outputs 50 notes (at once!) without a single glitch, at least on my computer (MAC mini late 2012 quad core 2.6 mhz i7, osx yosemite, 16gig ram). Then if you click the second bang below on the left, even if it outputs just 2 (you can change this number if two doesn't produce audio errors on your computer) notes at a time, it produces almost all the time I/O errors and audio dropout. There's 50 arrays in the patch and 350 voices... So can anyone think of the reason why the first time the arrays are sent a sinesum message everything works fine, but the second time it produces so many errors?
Thank you for your help!
Benoît Fortier
Le mercredi 7 octobre 2015 16h01, Miller Puckette msp@ucsd.edu a écrit :
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm
sending it again to make sure everything is clear.
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier <benoitfortier@yahoo.ca> a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I effectively want to have the possibility to give to each note a different timbre if I want. Thanks for your suggestions, fortunately there are many compromise solutions possible. You're mentioning in one of your suggestion I could use 1000 arrays. Let say that I'm lazy and that in the short term, I decide not to change my patch too much and to rely on a big amount of arrays to avoid the audio dropouts I am getting right now. What would be the consequences, if any, of using a ridiculously big amount of arrays? I don't know, lets say 10 000, or more? I'm guessing that each arrays makes the file bigger, but appart from that? This is probably hypothetical by the way : I doubt I will need that many arrays for that project. Benoît Fortier 581 995-5622
Le jeudi 8 octobre 2015 15h11, Matt Barber <brbrofsvl@gmail.com> a écrit :
Dynamic patching is rough but possible. If you try it, you'll want to make sure not to dynamically patch any tilde objects. Also I can't remember if deleting a table already used in dsp triggers a recalculation, so it may not even be worth it. In your patch the sine weights are hardcoded. Can we assume that won't be the case ultimately, and that each of the notes would have a potentially different timbre (and pitch, etc.)? The only other thing I can think of would be to drop 32 oscillators into each of your instances, and then just send the desired weights as amplitude multipliers to the oscillators (you'd have to take care of normalizing manually). That's annoying, but since you're [switch~]ing things off anyway when they aren't playing, it's not out of the realm of possibility. Or, if you're planning on constraining the timbres in a particular way, it wouldn't be impossible to calculate all of the different timbres you're going to use when the patch loads. If there's some randomness, you could dynamically patch 1000 tables with different weightings, and then just have the note choose from among the 1000. On Thu, Oct 8, 2015 at 2:38 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Thank you all for your help. Matt, Your solutions sounds interesting. I'm not familiar with block size issues and how the fourier analysis objects work apart that I know what they do (at least roughly). I guess it's about time I go deeper into this. I'll start with Miller's book unless you have an other suggestion. Maybe I'm being naive, but what about dynamic patching? Could it be possible to create (and delete) tables on the fly depending of my needs? I find it very hard to find a good documentation about dynamic patching on the web so right now I can hardly experiment with this. Where could I start? Benoît Fortier
Le jeudi 8 octobre 2015 13h16, Matt Barber <brbrofsvl@gmail.com> a écrit :
I haven't tried this in a while, but it might be worth trying to build a custom sinesum abstraction that fills the tables manually with an until loop and then normalizes them. This may take too long, though. There's probably another solution with [tabsend~] and [tabreceive~] where you write the weights in a table and then use use an ifft to tabsend~ the result to the table you're reading from. I haven't thought it through - the blocking would be tricky. On Wed, Oct 7, 2015 at 7:01 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Ok here is my simplified patch. First, if you click the top bang, it outputs 50 notes (at once!) without a single glitch, at least on my computer (MAC mini late 2012 quad core 2.6 mhz i7, osx yosemite, 16gig ram). Then if you click the second bang below on the left, even if it outputs just 2 (you can change this number if two doesn't produce audio errors on your computer) notes at a time, it produces almost all the time I/O errors and audio dropout. There's 50 arrays in the patch and 350 voices... So can anyone think of the reason why the first time the arrays are sent a sinesum message everything works fine, but the second time it produces so many errors? Thank you for your help! Benoît Fortier
Le mercredi 7 octobre 2015 16h01, Miller Puckette <msp@ucsd.edu> a écrit :
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm sending it again to make sure everything is clear. Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier benoitfortier@yahoo.ca a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details Basically my patch is a big synth. It has a bank of 50 arrays. Those arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes. The problem starts when all arrays have been sent a first sinesum command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch. Does that ring a bell to anyone? If not I’ll soon make a simplified and clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~). Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You're basically limited by RAM, but if you have a big dynamic patching & sinesum routine on loadbang you might have to wait a few seconds for your patch to open. Or, if you want you can do the dynamic patching once to get the patch, and the sinesum routine once as well, and save the contents of those tables in the patch. You can't save the contents of [table] objects, but graphical ones can be saved (and they're easiest to dynamically patch if you wrap them in an abstraction like you have with the tables in your project). Or, if you're using vanilla, look into the new [array] objects, whose contents can be saved as well. It might still take a moment to load the patch, but you can be confident that everything is there for you. In my experience Pd doesn't run that much slower with tons of arrays, although it may take slightly longer to find the array by name when invoked.
On Fri, Oct 9, 2015 at 2:25 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
I effectively want to have the possibility to give to each note a different timbre if I want. Thanks for your suggestions, fortunately there are many compromise solutions possible.
You're mentioning in one of your suggestion I could use 1000 arrays. Let say that I'm lazy and that in the short term, I decide not to change my patch too much and to rely on a big amount of arrays to avoid the audio dropouts I am getting right now. What would be the consequences, if any, of using a ridiculously big amount of arrays? I don't know, lets say 10 000, or more? I'm guessing that each arrays makes the file bigger, but appart from that? This is probably hypothetical by the way : I doubt I will need that many arrays for that project.
Benoît Fortier 581 995-5622
Le jeudi 8 octobre 2015 15h11, Matt Barber brbrofsvl@gmail.com a écrit :
Dynamic patching is rough but possible. If you try it, you'll want to make sure not to dynamically patch any tilde objects. Also I can't remember if deleting a table already used in dsp triggers a recalculation, so it may not even be worth it.
In your patch the sine weights are hardcoded. Can we assume that won't be the case ultimately, and that each of the notes would have a potentially different timbre (and pitch, etc.)? The only other thing I can think of would be to drop 32 oscillators into each of your instances, and then just send the desired weights as amplitude multipliers to the oscillators (you'd have to take care of normalizing manually). That's annoying, but since you're [switch~]ing things off anyway when they aren't playing, it's not out of the realm of possibility. Or, if you're planning on constraining the timbres in a particular way, it wouldn't be impossible to calculate all of the different timbres you're going to use when the patch loads. If there's some randomness, you could dynamically patch 1000 tables with different weightings, and then just have the note choose from among the 1000.
On Thu, Oct 8, 2015 at 2:38 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Thank you all for your help. Matt, Your solutions sounds interesting. I'm not familiar with block size issues and how the fourier analysis objects work apart that I know what they do (at least roughly). I guess it's about time I go deeper into this. I'll start with Miller's book unless you have an other suggestion.
Maybe I'm being naive, but what about dynamic patching? Could it be possible to create (and delete) tables on the fly depending of my needs? I find it very hard to find a good documentation about dynamic patching on the web so right now I can hardly experiment with this. Where could I start?
Benoît Fortier
Le jeudi 8 octobre 2015 13h16, Matt Barber brbrofsvl@gmail.com a écrit :
I haven't tried this in a while, but it might be worth trying to build a custom sinesum abstraction that fills the tables manually with an until loop and then normalizes them. This may take too long, though. There's probably another solution with [tabsend~] and [tabreceive~] where you write the weights in a table and then use use an ifft to tabsend~ the result to the table you're reading from. I haven't thought it through - the blocking would be tricky.
On Wed, Oct 7, 2015 at 7:01 PM, Benoît Fortier benoitfortier@yahoo.ca wrote:
Ok here is my simplified patch. First, if you click the top bang, it outputs 50 notes (at once!) without a single glitch, at least on my computer (MAC mini late 2012 quad core 2.6 mhz i7, osx yosemite, 16gig ram). Then if you click the second bang below on the left, even if it outputs just 2 (you can change this number if two doesn't produce audio errors on your computer) notes at a time, it produces almost all the time I/O errors and audio dropout. There's 50 arrays in the patch and 350 voices... So can anyone think of the reason why the first time the arrays are sent a sinesum message everything works fine, but the second time it produces so many errors?
Thank you for your help!
Benoît Fortier
Le mercredi 7 octobre 2015 16h01, Miller Puckette msp@ucsd.edu a écrit :
This is probably not your problem but just in case:
MAke sure not to update large numbers of arrays that are visible - hide them in a sub-patch or in "array define" objects (or the old "table") so that they're not visible. Erasing and re-drawing graphs is much more expensive than computing them.
cheers Miller
On Wed, Oct 07, 2015 at 07:12:40PM +0000, Benoît Fortier wrote:
Sorry for double posting, there was a typo in my previous message so I'm
sending it again to make sure everything is clear.
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît Benoît Fortier 581 995-5622
Le mercredi 7 octobre 2015 15h06, Benoît Fortier <benoitfortier@yahoo.ca> a écrit :
Hi list, I’m working on a big patch. I have many audio I/O error and
audio glitch and I’m having a hard time finding why. I’ve done some extensive troubleshooting yesterday but couldn’t pin point the exact cause. I managed to narrow my problem down to what I find is a weird behaviour (at least for me!) with arrays being filled with the sinesum method. Here are some more details
Basically my patch is a big synth. It has a bank of 50 arrays. Those
arrays are storing waveforms (using sinesum) which are read by a bank of 300 « voices » (each using the tabread4~ object). When a « note in » message is received, the patch first sends a sinesum command to an unused array. Then, the array id is sent in the voice bank along with the « note in » message so that it can be dealt with accordingly by an individual voice using a tabread4~ object. The sinesum part of this process happens only if necessary : if many consecutive notes uses the same waveform, then the different voices dealing with those notes will all read the same array and no sinesum command is sent until the waveform changes.
The problem starts when all arrays have been sent a first sinesum
command and start receiving a second one to replace the first waveform, which is not used anymore. (To make that happen quickly I can set my patch to always send a sinesum command to a new array for every « note in » so that I quickly reach a point when all the arrays were sent a first sinesum) The weird behaviour is this : the first 50 notes sounds just fine (the same number , with no I/O errors, but the 51st note and upward almost all provoque I/O errors and audio glitch, no matter how many voices are playing at the same time. It’s like if the first time each arrays are sent a sinesum command they load just fine, but it mysteriously takes much more cpu to send a second (third, fourth… ) sinesum command to each of them, thus provoking the audio glitch. I’ve managed to reproduce the problem with various simplified version of my patch.
Does that ring a bell to anyone? If not I’ll soon make a simplified and
clear version of my patch so that my problem is emphasized and I’ll post it here. To the best of my knowledge and after a lot of testing, I believe my voice management system and my array management system is not part of the problem (for example, I believe no arrays are changed while being read by a tabread4~).
Thank you all for your helpfulness! Benoît _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Benoît Fortier -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Matt Barber -
Miller Puckette