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 <[email protected]> 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 <[email protected]> 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 < > [email protected]> 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 > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
