[PD] Strange behaviour when sending sinesum commands to arrays

[Matt Barber]

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 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/20151007/dae26a97/attachment.html>