[PD] Strange behaviour when sending sinesum commands to arrays

[Matt Barber]

​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 at 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 at 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 at 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> >
> >
> >
>
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151008/5c7b9ff7/attachment.html>