I did read, but I think how snapshot~ can't work in a block size of 1 is a side issue.
But whatever restrictions it has, we do have [vsnapshot~] as a workaround. Unfortunately, there's no help file yet to [vnapshot~]. Hopefully there'll be one in the next update. > couldn't [bang~] have a conditional where it schedules > more clock callbacks with the relevant timestamps? yeah, right? couldn't it? why not? cheers 2015-03-15 13:55 GMT-03:00 Jonathan Wilkes <jancs...@yahoo.com>: > snapshot~ is to vsnapshot~ what line~ is to vline~. > > Did you read the chapter of Miller's book which he linked to here? > > > > On Saturday, March 14, 2015 11:55 AM, Alexandre Torres Porres < > por...@gmail.com> wrote: > > > moreover, [snapshot~] will also print 64 equal values of the last value in > a 64 block even if the patch is running at a block size of "1", being this > kind of behaviour my biggest surprise that i point in this thread. > > 2015-03-14 12:17 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > > > snapshot~ will always output the last sample from an audio block of 64 > > > > > *This sounded strange at first to me, but it makes sense if you > considerthat snapshot~'s role is to give you one audio sample from the > audiostream. Since you will only receive messages in between audio blocks > thelast sample in a vector is the one that is closest (in timing) to > thepoint at which you receive the value in the gui.* > > > For snapshot, I know I ran proper tests as I was comparing it to > vsnapshot~, meaning that it wasn't constricted to the bang gui behaviour. > So sending bangs at every sample did only spit out 64 equal values of the > last sample in the block - whereas [vsnapshot~] can give a value for each > sample. > > cheers > > > > 2015-03-14 12:13 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > > > print~ will always start printing from the beginning of a 64 block period > > > *The same here. Perhaps it helps to see print~ as the object that givesyou > one audio block as numbers rather than an 'audio rate print' thatdoes > things faster than message timing.* > > I also meant that it can't help but start from a 64 block boundary, even > if the block is less, such as "1", but I think that this is because the > bang button is always aligned to a 64 block tick, as I pointed out later, > so I may have to run other tests to see how [print~] actually behaves with > different size blocks. > > cheers > > 2015-03-14 6:21 GMT-03:00 Peter P. <peterpar...@fastmail.com>: > > * Alexandre Torres Porres <por...@gmail.com> [2015-03-14 07:36]: > > It seems there are other objects that somehow restrict themselves to a 64 > > size block minimum. > > > > print~ will always start printing from the beginning of a 64 block period > The same here. Perhaps it helps to see print~ as the object that gives > you one audio block as numbers rather than an 'audio rate print' that > does things faster than message timing. > > > snapshot~ will always output the last sample from an audio block of 64 > This sounded strange at first to me, but it makes sense if you consider > that snapshot~'s role is to give you one audio sample from the audio > stream. Since you will only receive messages in between audio blocks the > last sample in a vector is the one that is closest (in timing) to the > point at which you receive the value in the gui. > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
