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
attached patch
2015-03-14 2:02 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
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
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 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
attached patch
2015-03-14 2:02 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
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
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 porres@gmail.com:
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 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
attached patch
2015-03-14 2:02 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
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
- Alexandre Torres Porres porres@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.
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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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.
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 porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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.
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 porres@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 porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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.
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 <porres@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 porres@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 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.
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 porres@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 gives you one audio block as numbers rather than an 'audio rate print' that does 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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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
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 processed depth-first as I understand it. That's why the infinite loop in Pd is so fatal to the process.
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?
One programming hazard: I think with this external it would be possible to run things out of order, so that some messages that occur slightly sooner in logical time from an object like metro, wait until the default dac block size occurs, and wind up running after all of the messages that occur during the perform routines.
Part of what I'm missing is how the timed messages work. I never learned this completely.
On Sun, Mar 15, 2015 at 11:55 AM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
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 porres@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 porres@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 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.
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 porres@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 gives you one audio block as numbers rather than an 'audio rate print' that does 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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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
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 (or rather: because i didn't understand the concept of having synchronous DSP-processing separated from asynchronous message processing when i wrote that code)
unfortunately some of my colleagues immediately started writing DSP-code (with some heavy DSP maths in message domain) relying on that behaviour, which makes it somewhat hard (employment wise :-)) to fix this behaviour.
gfmrdsa IOhannes
On Mon, Mar 16, 2015 at 2:07 PM, IOhannes m zmölnig zmoelnig@iem.at 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 message during each perform routine.
Ah! I was looking for this today and I gave up when I found the non-signal [pack] object in the vanilla code. I couldn't remember I had seen it in zexy.
this was totally by mistake (or rather: because i didn't understand the concept of having synchronous DSP-processing separated from asynchronous message processing when i wrote that code)
unfortunately some of my colleagues immediately started writing DSP-code (with some heavy DSP maths in message domain) relying on that behaviour, which makes it somewhat hard (employment wise :-)) to fix this behaviour.
gfmrdsa IOhannes
I think there's some value for both, but only if you know you can't mix the two without close inspection.
To workaround the worst part, you could lower the DEFDACBLOCKSIZE to 1, but there's still ordering issues on the messages.
Real-time dangerous, for sure, and limited usefulness. It still seems like a trick to remember.
You could add the code for an "apack~" or asynchronous pack object, and have both (not that I'm really trying to make more work for you)
Chuck
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 a blocksize of 1.
Messages are blocking, and processed depth-first as I understand it. That's why the infinite loop in Pd is so fatal to the process.
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?
It'd be something like vline~ but going in the opposite direction. But I think there are problems with it. (See below.)
One programming hazard: I think with this external it would be possible to run things out of order, so that some messages that occur slightly sooner in logical time from an object like metro, wait until the default dac block size occurs, and wind up running after all of the messages that occur during the perform routines.
Part of what I'm missing is how the timed messages work. I never learned this completely.
[Warning: wrong things may lurk below. I'm still figuring out how this works...]
They work off of clock callbacks. clock_set registers the timestamp in a linked list, and before it fires the corresponding event it sets the current time to that timestamp.
That way even if a dsp tick were somehow changed to last an entire day, you could still get deterministic output out of the timing objects when they fire at rates shorter than a day. For example, you could specify delay times for printing out a message at breakfast, lunch, and dinner time:
[loadbang] | [delay 8 hours] | [breakfast time!( | [print]
[loadbang] | [delay 12 hours] | [lunch time!( | [print]
[loadbang] | [delay 18 hours] | [dinner time!( | [print]
In such a case of day long system blocks, all the messages would unfortunately print out without any delay between them. But on the bright side, the clock callback timestamps would ensure that you see them print out in the correct order. Additionally stuff like [timer] would output a value _as_ _if_ those delay objects had fired with the timestamps you provided them.
Now, in that same day-long block system, from what I understand you could use [vline~] to have ramps (or jumps) in the signal at the relevant meal times. That's one of the reasons Pd's clock API is very useful. Still, there's no way I know to get events to actually fire at anything lower than the system block time. At least not without doing your own timekeeping inside your external.
Anyway, if you make the external to output a bang inside the perform routine, try it at [block~ 1], and measure the logical time between outputs with [timer]. My prediction is that it will measure "0", which is wrong. So I think you'll have to do the math inside the perform routine to figure out what the delay would be given a block size below 64, and then use clock_set to output the bang with the relevant delay specified.
-Jonathan
On Sun, Mar 15, 2015 at 11:55 AM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
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 porres@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 porres@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 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.
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 porres@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 gives you one audio block as numbers rather than an 'audio rate print' that does 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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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
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 jancsika@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 < porres@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 porres@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 porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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
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 to understand/predict results now.
cheers
2015-03-14 12:13 GMT-03:00 Alexandre Torres Porres porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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.
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 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.
[print~] will print the number of samples in the block size for your canvas (or use the default size 64 if nothing is specified). So if you have [block~ 1], [print~] will print a single value.
However, at [block~ 1] you won't be able to print out two _consecutive_ samples using consecutive bangs, no matter what you try. Instead you must send a float to specify consecutive blocks. That is because Pd's event scheduler is limited to firing events at the system block boundary (where the system block is hard coded to 64). The [bang~] object is constrained in the same way.
This gets confusing in the edge cases because, as I wrote in the other thread, Pd's does internal timekeeping as if the event timings weren't limited by anything except the double precision. So if you try to send a bang every sample with [delay], measuring that delay with [timer] will give you the result you expect, regardless of the block size. But the moment you try to enter the signal domain (by sending to a signal object), you run up against the reality that those events actually get fired only on block boundaries.
However, an object like [vline~] calculates its ramps based off of the precise values provided by Pd's event timekeeping. So even though two bangs arrive on block boundaries, they arrive with the timestamps specified by [del], [pipe], etc. That's why in tutorial C04 you're able to take the metro all the way down to 1ms and the [vline~] signal path will output the correct frequency.
I believe ChucK has a different design that doesn't have this underlying timing constraint I'm describing here. But it's unclear to me how valuable that would be in practice. Even if you could [bang~] every sample and convert back to a signal every sample, a chain of control objects of any complexity is going to be inefficient due to overhead of the message dispatching system. (After all if it were efficient there wouldn't be much need for signals.)
-Jonathan
cheers
2015-03-14 6:21 GMT-03:00 Peter P. <peterparker@fastmail.com mailto:peterparker@fastmail.com>:
* Alexandre Torres Porres <porres@gmail.com <mailto:porres@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
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 <porres@gmail.com> wrote:
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 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
attached patch 2015-03-14 2:02 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
- Alexandre Torres Porres porres@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 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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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.
- Alexandre Torres Porres porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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~ ?
" *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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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~ ?
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 porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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. peterparker@fastmail.com:
- Alexandre Torres Porres porres@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~ ?
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 thread is a bit confusing .... what timing are we considering:
1/ real world time of various kinds of events as sent out of hardware, say to a gpio or to a midi port or the networking hardware
2/ real world time of events sent by pd to another process within the local machine
3/ time-stamping of events of either of those kinds
4/ the nature and relationship between the interlocking scheduling, time-stamping and event loops within pd, and what the several different ways of interacting with these each mean in terms of each of the above cases
5/ how any of this is related to any communications protocol which might carry this timing information accurately, and at what latency
6/ how this all relates to the kernel, cpu and hardware scheduling, buffering and latencies (especially at some of the ridiculously small time intervals being considered in this thread which are completely irrelevant within pd, given this context)
These issues are complex and no general answers, out of context of an actual use-case, can make much sense ... at least not at the level of a email thread.
The obvious external communications protocol available for pd that integrates audio and control time-stamping in a readily usable way is jack with jack-midi so how pd time-stamping works in this particular case is interesting in detail, but I have not looked into this myself.
How each of the different ways of using timestamps and adjusting pd scheduling in relation to computing a dsp signal work is very important, and for answers in an email thread a use-case is needed ... there are a great number of options, all useful in the right context.
How very tight timing of hardware inputs and outputs might be achieved is also very interesting ... and once you want accurate timing much tighter than the audio latency you are using you are going to need to either create a separate external thread outside the pd loops, or for even tighter timing you are going to need to have a hardware loop happening outside the cpu pipeline .... modern general purpose computers are inherently awful in this respect, it is not what they are designed to do. Using a modern desktop in this context is madness, but if you have unlimited time and energy then a completely independent GUI program running via carefully controlled communications on a separate modern machine with a modern desktop is possible. Then comes the issue of how to get a single clock pulse to run all these devices so your time-stamps make sense.
Pd is very useful as the glue in all of this, and if you are interested in the kind of hardware which can handle this kind of work then an Udoo is not a bad place to start looking. It has 2 chips on the board, linked via their GPIOs, one is an arduino to run the tight loops required and the other is a quad core with lots of GPIO that can run a suitably adjusted linux kernel that can do the control needed and even have a core spare to run a desktop environment.
Simon
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 objects, which I also found to exist.
this thread is a bit confusing .... what timing are we considering:
[...]
These issues are complex and no general answers, out of context of an actual use-case, can make much sense ... at least not at the level of a email thread.
The obvious external communications protocol available for pd that integrates audio and control time-stamping in a readily usable way is jack with jack-midi so how pd time-stamping works in this particular case is interesting in detail, but I have not looked into this myself.
You're now adding midi to the mix, which is (or at least should) be outside the scope of how and why [bang~] behaves as it does.
How each of the different ways of using timestamps and adjusting pd scheduling in relation to computing a dsp signal work is very important, and for answers in an email thread a use-case is needed ... there are a great number of options, all useful in the right context.
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 the constraint that the system block size of 64 imposes. For block size below 64, couldn't [bang~] have a conditional where it schedules more clock callbacks with the relevant timestamps?
I don't think a use-case is needed to understand the issue, though
several are probably needed to assess the efficacy of hacking [bang~].
My quick hypothesis is that in a language like ChucK where these
constraints don't exist, the user is free to implement a prohibitively
expensive algorithm before changing it to something more sensible.
(Whereas in Pd, we have a high-latency asynchronous discussion about it.)
-Jonathan
How very tight timing of hardware inputs and outputs might be achieved is also very interesting ... and once you want accurate timing much tighter than the audio latency you are using you are going to need to either create a separate external thread outside the pd loops, or for even tighter timing you are going to need to have a hardware loop happening outside the cpu pipeline .... modern general purpose computers are inherently awful in this respect, it is not what they are designed to do. Using a modern desktop in this context is madness, but if you have unlimited time and energy then a completely independent GUI program running via carefully controlled communications on a separate modern machine with a modern desktop is possible. Then comes the issue of how to get a single clock pulse to run all these devices so your time-stamps make sense.
Pd is very useful as the glue in all of this, and if you are interested in the kind of hardware which can handle this kind of work then an Udoo is not a bad place to start looking. It has 2 chips on the board, linked via their GPIOs, one is an arduino to run the tight loops required and the other is a quad core with lots of GPIO that can run a suitably adjusted linux kernel that can do the control needed and even have a core spare to run a desktop environment.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 the constraint that the system block size of 64 imposes. For block size below 64, couldn't [bang~] have a conditional where it schedules more clock callbacks with the relevant timestamps?
I don't think a use-case is needed to understand the issue, though several are probably needed to assess the efficacy of hacking [bang~]. My quick hypothesis is that in a language like ChucK where these constraints don't exist, the user is free to implement a prohibitively expensive algorithm before changing it to something more sensible. (Whereas in Pd, we have a high-latency asynchronous discussion about it.)
yes
Simon
-
Alexandre Torres Porres -
Charles Z Henry -
IOhannes m zmölnig -
Jonathan Wilkes -
Peter P. -
Simon Wise