Hi pd-list,
I use outlet_float() in an external to output messages. How often is it allowed to send a message in a loop? I didn't find anything about it...
br,
Piotr
hi piotr,
I use outlet_float() in an external to output messages. How often is it allowed to send a message in a loop? I didn't find anything about it...
short answer is there isn't - you can go as fast as current blocksize allows, long answer is a bit dependent on what you are trying to do - best practice IMO if you have to update a value regularly is to request a clock from pd, set a sensible default and use this as a tick to send out your floats, I'd also make the delay time settable by the user with some message (i.e. [ refresh $1 ( )
HTH
x
Piotr Majdak wrote:
Hi pd-list,
I use outlet_float() in an external to output messages. How often is it allowed to send a message in a loop? I didn't find anything about it...
the built-in "stack overflow" counter allows a recursion of 1000/(#obj involved)
abstractions count as several objects (as many as there are involved)
see attached patch.
mfg.ads.r IOhannes
#N canvas 132 282 724 301 10; #X obj 51 163 i; #X obj 88 163 + 1; #X msg 51 129 0; #X obj 161 163 i; #X obj 198 163 + 1; #X msg 161 129 0; #X obj 161 185 t f f; #X obj 275 166 i; #X obj 312 166 + 1; #X msg 275 132 0; #X obj 275 188 t f f; #X obj 349 166 * 1; #X obj 51 190 print 2obj; #X obj 191 205 print 3obj; #X obj 305 208 print 4obj; #X obj 442 170 i; #X obj 479 170 + 1; #X msg 442 136 0; #X obj 442 192 t f f; #N canvas 0 0 450 300 3-more-objects 0; #X obj 119 52 inlet; #X obj 119 198 outlet; #X obj 119 124 f; #X connect 0 0 2 0; #X connect 2 0 1 0; #X restore 505 170 pd 3-more-objects; #X obj 472 212 print 7obj; #X connect 0 0 12 0; #X connect 0 0 1 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 6 0; #X connect 4 0 3 0; #X connect 5 0 3 0; #X connect 6 0 4 0; #X connect 6 1 13 0; #X connect 7 0 10 0; #X connect 8 0 11 0; #X connect 9 0 7 0; #X connect 10 0 8 0; #X connect 10 1 14 0; #X connect 11 0 7 0; #X connect 15 0 18 0; #X connect 16 0 19 0; #X connect 17 0 15 0; #X connect 18 0 16 0; #X connect 18 1 20 0; #X connect 19 0 15 0;
I use outlet_float() in an external to output messages. How often is it allowed to send a message in a loop? I didn't find anything about it...
the built-in "stack overflow" counter allows a recursion of 1000/(#obj involved)
not exactly ... the 1000 frames recursion depth is used by devel ... iirc miller's version is limiting the recursions by stack size ... so it would depend on the objects ...
but a construction like: for (int i = 0; i != infinity; ++i) outlet_float()
is an iteration, not a recursion ... so there is no limit (except the speed of the machine) ... the |until| object is working this way ...
hth ... tim
Tim Blechmann wrote:
I use outlet_float() in an external to output messages. How often is it allowed to send a message in a loop? I didn't find anything about it...
the built-in "stack overflow" counter allows a recursion of 1000/(#obj involved)
not exactly ... the 1000 frames recursion depth is used by devel ... iirc miller's version is limiting the recursions by stack size ... so it would depend on the objects ...
öhm, dat's why i put the (#obj involved) term into my "equation": it means "number of objects involved". this means that it is not a real "recursion depth". (and sometimes it
but a construction like: for (int i = 0; i != infinity; ++i) outlet_float()
is an iteration, not a recursion ... so there is no limit (except the
this is correct.
i was dummified by the "loop" (as in "message loop") and thus was immediately thinking of recursion.
speed of the machine) ... the |until| object is working this way ...
well, the speed of the machine does _not_ effect the maximum allowed number of loop-iterations. (however, if you are doing audio at the same time, you might consider a fast machine and a larger audiobuffer to avoid clicks)
i guess the only limitation is the size of the counter.
mfg.asd.r IOhannes
Hi!
IOhannes m zmoelnig wrote:
well, the speed of the machine does _not_ effect the maximum allowed number of loop-iterations. (however, if you are doing audio at the same time, you might consider a fast machine and a larger audiobuffer to avoid clicks)
Well, I'm confused now. I do audio at the same time and I have to avoid any clicks, of course. But, how fast must the machine run? How large must be the audio buffer for a given number of messages in loop? Or, generally, what are the limitations and dependencies on chosing the number of iterations for a message output in a loop?
br, Piotr
Piotr Majdak wrote:
Hi!
IOhannes m zmoelnig wrote:
well, the speed of the machine does _not_ effect the maximum allowed number of loop-iterations. (however, if you are doing audio at the same time, you might consider a fast machine and a larger audiobuffer to avoid clicks)
Well, I'm confused now. I do audio at the same time and I have to avoid any clicks, of course. But, how fast must the machine run? How large must be the audio buffer for a given number of messages in loop? Or, generally, what are the limitations and dependencies on chosing the number of iterations for a message output in a loop?
no assumption can be made on my side about "how fast" or "how many".
as long as pd is handling messages, it cannot calculate audio. how long the message handling takes, depends on what it does. if you object outputs 10 floats in a loop and nothing is connected to it, you are unlikely to notice. however, if each of these floats triggers a 65000-sample fft (e.g. of a table) and sends the result of these as an email to the nearest spyware blaster, you are likely to get into troubles.
the simplest thing you can do is try it out, how many calcs you can do in a row without clicks.
and of course, there is the option of using a separate thread for the message handling (if using pd-devel is an option)
mfg.asdr. IOhannes
Hi!
IOhannes m zmoelnig wrote:
as long as pd is handling messages, it cannot calculate audio. how long the message handling takes, depends on what it does. if you object outputs 10 floats in a loop and nothing is connected to it, you are unlikely to notice. however, if each of these floats triggers a 65000-sample fft (e.g. of a table) and sends the result of these as an email to the nearest spyware blaster, you are likely to get into troubles.
Do I understand it correctly:
- calling outlet_float(), a depth-first handling of all objects attached
to this outlet is triggered?
If yes, what must be guarrantied to avoid clicks:
- the handling of _this_ message must be completed within one sample
block or
- the handling of _all_ messages of _this_ external must be completed
within one sample block or
- tha handling of _all_ messages of _all_ objects in pd must be
completed within one sample block?
If you tell me which of these statements is correct, I'm able to estimate the maximal number of messages for my machine.
the simplest thing you can do is try it out, how many calcs you can do in a row without clicks.
My patch contains many modules which can be triggered asynchronous and sometimes my pd freezes (see another thread). Thus, the try and error method didn't help, up to now :-( Now, I'm trying to estimate the possible error sources...
and of course, there is the option of using a separate thread for the message handling (if using pd-devel is an option)
What is the difference between the pd-devel and the 0.39.1? Is there a readme/howto I could read before trying the pd-devel version?
br, Piotr
Piotr Majdak wrote:
Hi!
IOhannes m zmoelnig wrote:
Do I understand it correctly:
- calling outlet_float(), a depth-first handling of all objects attached
to this outlet is triggered?
yes
If yes, what must be guarrantied to avoid clicks:
- the handling of _this_ message must be completed within one sample
block or
- the handling of _all_ messages of _this_ external must be completed
within one sample block or
- tha handling of _all_ messages of _all_ objects in pd must be
completed within one sample block?
If you tell me which of these statements is correct, I'm able to estimate the maximal number of messages for my machine.
the 3rd one is the _most_ correct: in addition, the audio processing needs to be done within the one sample block too :-(
however, pd's audio processing is buffered, so it's ok if it happens now and then, if the messages cannot be completed within one sample block. message handling somewhat floats with respect to the real time. this is basically what the "audiobuf" is for.
and of course, if your messages keep needing more time to evaluate than one audioblock, your patch is unusable. (with "keep" i mean, that e.g. each and every audioblock you need more time than you have) luckily this is rather seldom.
What is the difference between the pd-devel and the 0.39.1? Is there a
everything :-)
readme/howto I could read before trying the pd-devel version?
the only readme/howto (i know) is pd-dev.
mfg.asd.r IOhannes
On Thu, 3 Nov 2005, IOhannes m zmoelnig wrote:
What is the difference between the pd-devel and the 0.39.1? Is there a
everything :-)
How do you define "everything" in this context?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 3 Nov 2005, Piotr Majdak wrote:
Do I understand it correctly:
- calling outlet_float(), a depth-first handling of all objects attached to
this outlet is triggered?
yes
If yes, what must be guarrantied to avoid clicks:
- tha handling of _all_ messages of _all_ objects in pd must be completed
within one sample block?
To avoid clicks, the handling of messages should leave enough CPU power to the DSP often enough so that buffers can be sent to the soundcard. This depends on your settings for latency.
If you set the latency at the minimum possible, then the handling of the sample block in DSP _plus_ the handling of all scheduled t_clocks for that sample block must be done within the duration of one sample block, e.g. 64/44100 of a second. (I'm not even including messages from the GUI here)
If the latency is not set at minimum, then you have more headroom, as the jobs assigned to one block can spill over the time allocated to another block. This is the difference between "logical time" and "physical time".
A t_clock is what drives [metro], [line], [delay], [pipe], etc. The handling of a t_clock event includes the handling of all messages sent from those handlers, recursively, depth-first. This does not include messages which are delayed for later blocks.
What is the difference between the pd-devel and the 0.39.1? Is there a readme/howto I could read before trying the pd-devel version?
Relative to this question, I think that there is no difference. There is a plan to make DSP run in a separate thread, but I don't think that's been coded yet.
For devel_0_39 you will need to have "scons" installed. I don't think there's such a README, but doing "scons --help" will give you a list of compile-time options you may want to try, such as accelerated FFT (FFTW), accelerated DSP (SIMD), threaded soundfiler, etc.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
speed of the machine) ... the |until| object is working this way ...
well, the speed of the machine does _not_ effect the maximum allowed number of loop-iterations.
right ... not the _allowed_ but the _usable_ number ...
(however, if you are doing audio at the same time, you might consider a fast machine and a larger audiobuffer to avoid clicks)
... or a thread :-)
cheers ... tim
-
CK -
IOhannes m zmoelnig -
Mathieu Bouchard -
Piotr Majdak -
Tim Blechmann