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