> you won't be able to use objects like [adc~]/[dac~] if you have a block size different than 64
2015-03-14 12:09 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > " > *I have not tested this, but let me ask if you did already try putting > a**bang~ > in a subpatch which itself is reblocked using block~ ?*" > > Of course, I even sent such a patch to the pd list in this thread, check > it out... > > cheers > > ps. block~ doesn't have to be in a subpatch, it also works on the parent > patch, although you won't be able to use objects like [adc~]/[dac~] > > 2015-03-14 11:59 GMT-03:00 Peter P. <peterpar...@fastmail.com>: > > * Alexandre Torres Porres <por...@gmail.com> [2015-03-14 15:52]: >> > "*I assume that's what bang~ was designed for. It is not an 'audio rate* >> > >> > *bang' but something that lets you get timing information from audio* >> > *blocks*" >> > >> > but it doesn't work for blocks lesser than 64... can't bang at each 32, >> 16, >> > 8, 4, 2, 1 block samples... this was unexpected to me and what made me >> > wonder about similar/parallel behaviours from other objects, which I >> also >> > found to exist. >> > >> > cheers >> > >> > >> > 2015-03-14 6:18 GMT-03:00 Peter P. <peterpar...@fastmail.com>: >> > >> > > * Alexandre Torres Porres <por...@gmail.com> [2015-03-14 06:02]: >> > > > I was trying to get a bang at every sample and found out that the >> minimum >> > > > time bang~ works is at the 64 blocksize, check attached patch. >> > > I assume that's what bang~ was designed for. It is not an 'audio rate >> > > bang' but something that lets you get timing information from audio >> > > blocks, eg. deriving a video playback frame rate in sync to an audio >> > > stream. >> > > >> >> I have not tested this, but let me ask if you did already try putting a >> bang~ in a subpatch which itself is reblocked using block~ ? >> > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
