Dear all, i am sorry, my previous email to the list was obviously GPG-encrypted.
My question is the following: What is the best way to find out the DSP block size within an abstraction/sub patch? It could be set differently than 64 samples using block~ in a parent patch.
Right now, i am counting audio samples but this is not ideal since it is non-instantaneous and can therefore not be used for initialization purposes at the time of loadbang.
thanks, Thomas
-- Thomas Grill http://grrrr.org
Am 11.06.2016 um 18:54 schrieb Thomas Grill gr@grrrr.org:
<encrypted.asc>
Sample rate and block sizes can change as a result of messages to "block" objects. This causes DSP to be re-sorted. The only safe way I know to determine block size is to make a tilde object with a signal input or output and catch "dsp" messages.
cheers Miller
On Sat, Jun 11, 2016 at 08:02:47PM +0200, Thomas Grill wrote:
Dear all, i am sorry, my previous email to the list was obviously GPG-encrypted.
My question is the following: What is the best way to find out the DSP block size within an abstraction/sub patch? It could be set differently than 64 samples using block~ in a parent patch.
Right now, i am counting audio samples but this is not ideal since it is non-instantaneous and can therefore not be used for initialization purposes at the time of loadbang.
thanks, Thomas
-- Thomas Grill http://grrrr.org
Am 11.06.2016 um 18:54 schrieb Thomas Grill gr@grrrr.org:
<encrypted.asc>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Sure, thanks, but your answer implies that there is currently no way to do this with Vanilla objects, right? I think there should be a way. gr~~~
-- Thomas Grill http://grrrr.org
Am 11.06.2016 um 20:12 schrieb Miller Puckette msp@ucsd.edu:
Sample rate and block sizes can change as a result of messages to "block" objects. This causes DSP to be re-sorted. The only safe way I know to determine block size is to make a tilde object with a signal input or output and catch "dsp" messages.
cheers Miller
On Sat, Jun 11, 2016 at 08:02:47PM +0200, Thomas Grill wrote:
Dear all, i am sorry, my previous email to the list was obviously GPG-encrypted.
My question is the following: What is the best way to find out the DSP block size within an abstraction/sub patch? It could be set differently than 64 samples using block~ in a parent patch.
Right now, i am counting audio samples but this is not ideal since it is non-instantaneous and can therefore not be used for initialization purposes at the time of loadbang.
thanks, Thomas
-- Thomas Grill http://grrrr.org
Am 11.06.2016 um 18:54 schrieb Thomas Grill gr@grrrr.org:
<encrypted.asc>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/12/2016 12:16 AM, Thomas Grill wrote:
Sure, thanks, but your answer implies that there is currently no way to do this with Vanilla objects, right? I think there should be a way.
attached is a somewhat naive approach to the problem in pure vanilla.
it doesn't take any overlap/oversampling into account, and only works up to blocksizes of 65536-
gmsdr IOhannes
Thanks, i guess there's no way around using DSP right now which is difficult to unite with loadbang initialization after instantiation of the abstraction. This is my approach so far: https://github.com/grrrr/upp/blob/master/upp.blocksize.pd
-- Thomas Grill http://grrrr.org
Am 12.06.2016 um 00:24 schrieb IOhannes m zmölnig zmoelnig@iem.at:
On 06/12/2016 12:16 AM, Thomas Grill wrote:
Sure, thanks, but your answer implies that there is currently no way to do this with Vanilla objects, right? I think there should be a way.
attached is a somewhat naive approach to the problem in pure vanilla.
it doesn't take any overlap/oversampling into account, and only works up to blocksizes of 65536-
gmsdr IOhannes
<vecsize~.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I know you're looking for a vanilla solution. But just in case it might help: there's an object called [iem_blocksize~] in iemlib which I think does what you're looking for.
Christof
Gesendet: Sonntag, 12. Juni 2016 um 00:31 Uhr Von: "Thomas Grill" gr@grrrr.org An: "IOhannes m zmölnig" zmoelnig@iem.at Cc: pd-list@lists.iem.at Betreff: Re: [PD] inquire block size
Thanks, i guess there's no way around using DSP right now which is difficult to unite with loadbang initialization after instantiation of the abstraction. This is my approach so far: https://github.com/grrrr/upp/blob/master/upp.blocksize.pd
-- Thomas Grill http://grrrr.org
Am 12.06.2016 um 00:24 schrieb IOhannes m zmölnig zmoelnig@iem.at:
On 06/12/2016 12:16 AM, Thomas Grill wrote:
Sure, thanks, but your answer implies that there is currently no way to do this with Vanilla objects, right? I think there should be a way.
attached is a somewhat naive approach to the problem in pure vanilla.
it doesn't take any overlap/oversampling into account, and only works up to blocksizes of 65536-
gmsdr IOhannes
<vecsize~.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I might do it the IOhannes way, but put in a [switch~], turn on dsp, and send a bang to the [switch~]s in each instance to get dsp on for one block (and turn it off if desired). I'd send that bang as near to the end of my main patch's initial [loadbang] sequence as possible. If you wanted to get really fancy, if you knew either the maximum block size or the number of abstraction instances, you could close off all your user interface controls with [spigot]s and then open them back up after the requisite delay (if you know the max block size) or after you've counted all of the [bang~]s from the abstraction instances (if you know the number).
On Sat, Jun 11, 2016 at 6:43 PM, Christof Ressi christof.ressi@gmx.at wrote:
I know you're looking for a vanilla solution. But just in case it might help: there's an object called [iem_blocksize~] in iemlib which I think does what you're looking for.
Christof
Gesendet: Sonntag, 12. Juni 2016 um 00:31 Uhr Von: "Thomas Grill" gr@grrrr.org An: "IOhannes m zmölnig" zmoelnig@iem.at Cc: pd-list@lists.iem.at Betreff: Re: [PD] inquire block size
Thanks, i guess there's no way around using DSP right now which is
difficult to unite with loadbang initialization after instantiation of the abstraction.
This is my approach so far: https://github.com/grrrr/upp/blob/master/upp.blocksize.pd
-- Thomas Grill http://grrrr.org
Am 12.06.2016 um 00:24 schrieb IOhannes m zmölnig zmoelnig@iem.at:
On 06/12/2016 12:16 AM, Thomas Grill wrote:
Sure, thanks, but your answer implies that there is currently no way
to do this with Vanilla objects, right?
I think there should be a way.
attached is a somewhat naive approach to the problem in pure vanilla.
it doesn't take any overlap/oversampling into account, and only works
up
to blocksizes of 65536-
gmsdr IOhannes
<vecsize~.pd>_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/12/2016 12:31 AM, Thomas Grill wrote:
Thanks, i guess there's no way around using DSP right now which is difficult to unite with loadbang initialization after instantiation of the abstraction.
idon't think there is *any* way to get the block size during what you call "loadbang initialization". simple because it is not know at that time (even to Pd).
This is my approach so far: https://github.com/grrrr/upp/blob/master/upp.blocksize.pd
which seems to not behave well with overlapping and upsampling:
- [block~ 512] gives 512
- [block~ 512 2] gives 256
- [block~ 512 1 4] gives 128
mgfr IOhannes
Am 12.06.2016 um 09:06 schrieb IOhannes m zmölnig zmoelnig@iem.at:
This is my approach so far: https://github.com/grrrr/upp/blob/master/upp.blocksize.pd
which seems to not behave well with overlapping and upsampling:
- [block~ 512] gives 512
- [block~ 512 2] gives 256
- [block~ 512 1 4] gives 128
Right! The original intention was to get the time in samples between two block ticks. Your patch and mine should be combined to get the full picture.
-- Thomas Grill http://grrrr.org
-
Christof Ressi -
IOhannes m zmölnig -
Matt Barber -
Miller Puckette -
Thomas Grill