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 conditi
On 03/16/2015 01:46 PM, Charles Z Henry wrote:
This is the first time I've read the code for snapshot~ and
vsnapshot~. I had expected that it runs a message routine during the
perform routine--and it does not. You can't take the output of
snapshot~ and use it to affect the following sample with
On Mon, Mar 16, 2015 at 2:07 PM, IOhannes m zmölnig wrote:
> On 03/16/2015 06:46 PM, Charles Z Henry wrote:
>> So, what if I made an external (however dangerous to patch) that does
>> trigger a float message during each perform routine? What good is it?
>
> accidentally zexy's [pack~] triggers a
On 03/16/2015 06:46 PM, Charles Z Henry wrote:
> So, what if I made an external (however dangerous to patch) that does
> trigger a float message during each perform routine? What good is it?
accidentally zexy's [pack~] triggers a message during each perform routine.
this was totally by mistake (
This is the first time I've read the code for snapshot~ and
vsnapshot~. I had expected that it runs a message routine during the
perform routine--and it does not. You can't take the output of
snapshot~ and use it to affect the following sample with a blocksize
of 1.
Messages are blocking, and pr
On 16/03/15 03:41, Jonathan Wilkes via Pd-list wrote:
The relevant chapter that Miller cited for his book explains the ways in which
this can be handled. Ideally that's all one needs.
The problem is at the edge case where someone wants to synchronize control
events with the signal graph below t
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
wrote:
moreover, [snapshot~] will also print 64 equal values of the last value in a
64 block even if
But [print~] has a float method for specifying consecutive blocks, so that
shouldn't matter.
-Jonathan
On Saturday, March 14, 2015 2:36 AM, Alexandre Torres Porres
wrote:
It seems there are other objects that somehow restrict themselves to a 64 size
block minimum.
print~ will alw
On 03/15/2015 12:50 AM, Simon Wise wrote:
On 15/03/15 01:52, Alexandre Torres Porres wrote:
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 obj
On 15/03/15 01:52, Alexandre Torres Porres wrote:
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.
this th
On 03/14/2015 11:13 AM, Alexandre Torres Porres wrote:
> 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
print~ is a bit trickier... send it 64 bangs at each sample for a block
size of 1 and it'll only print once, and from the beginning of a 64 block
size boundary.
seems like working along with different sizes of block is more the
exception than the rule in Pd.
I find it all curious and kinda hard t
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 :
> > snapshot~ will always o
> 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 sampl
> 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 sta
> 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 :
> "
> *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~ ?*
"
*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 p
* Alexandre Torres Porres [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
"*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
* Alexandre Torres Porres [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
* Alexandre Torres Porres [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 tim
> there must be other examples...
like from control objects, seems the bang GUI will also only fire at 64
block periods.
sorry if I annoy, but I find it all curious and interesting
2015-03-14 3:36 GMT-03:00 Alexandre Torres Porres :
> It seems there are other objects that somehow restrict thems
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
snapshot~ will always output the last sample from an audio block of 64
there must be other examples...
cheers
2015-03-14 2:02
attached patch
2015-03-14 2:02 GMT-03:00 Alexandre Torres Porres :
> 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.
>
> Anyway, no question, just saying... but yeah, I don't see why it has to be
> this way
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.
Anyway, no question, just saying... but yeah, I don't see why it has to be
this way. Hopefully it can increase its resolution someday.
cheers
__
25 matches
Mail list logo
