heya,
...looking for a pd object or abstraction that'll round a float up/ down...
james
On Wed, 12 Oct 2005, james tittle wrote:
...looking for a pd object or abstraction that'll round a float up/down...
I told you, here's the full source code of the external, just paste it in the appropriate config file:
GridFlow::FObject.subclass("round",1,1){def _0_float(f)send_out 0,f.round end}
Note to other people: we know [i] is similar to what James wants, but it's not similar enough.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 12 Oct 2005, Mathieu Bouchard wrote:
On Wed, 12 Oct 2005, james tittle wrote:
...looking for a pd object or abstraction that'll round a float up/down...
I told you, here's the full source code of the external, just paste it in the appropriate config file:
Oh, and if you mean up/down as in nearest, that's what [round] does; else, for always down, it's [floor], and always up, it's [ceil].
GridFlow::FObject.subclass("round",1,1){def _0_float(f)send_out 0,f.round end} GridFlow::FObject.subclass("floor",1,1){def _0_float(f)send_out 0,f.floor end} GridFlow::FObject.subclass("ceil" ,1,1){def _0_float(f)send_out 0,f.ceil end}
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, Oct 12, 2005 at 12:43:41AM -0400, Mathieu Bouchard wrote:
On Wed, 12 Oct 2005, james tittle wrote:
...looking for a pd object or abstraction that'll round a float up/down...
I told you, here's the full source code of the external, just paste it in the appropriate config file:
GridFlow::FObject.subclass("round",1,1){def _0_float(f)send_out 0,f.round end}
Note to other people: we know [i] is similar to what James wants, but it's not similar enough.
so perhaps [round] is similar enough?
Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montr?al QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 12 Oct 2005, carmen wrote:
On Wed, Oct 12, 2005 at 12:43:41AM -0400, Mathieu Bouchard wrote:
On Wed, 12 Oct 2005, james tittle wrote: Note to other people: we know [i] is similar to what James wants, but it's not similar enough.
so perhaps [round] is similar enough?
[round] is like [+ .5]-[floor], so [floor] is like [- .5]-[round].
[ceil] is like [* -1]-[floor]-[* -1].
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Note to other people: we know [i] is similar to what James wants, but it's not similar enough.
I can't really follow: What's wrong with
[+/- 0.5] | [int]
as in attached patch which doesn't need any externals at all?
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Note to other people: we know [i] is similar to what James wants, but it's not similar enough.
I can't really follow: What's wrong with
[+/- 0.5] | [int]
as in attached patch which doesn't need any externals at all?
Forgot to say; The only difference to a round as in C was the handling of halfway cases smaller than 0, so if that is important to you, the abstraction gets a little bit more complicated, as in attached new version, which rounds away from zero even in sub-zero halfway cases.
Frank Barknecht _ ______footils.org_ __goto10.org__
james tittle schrieb:
heya,
...looking for a pd object or abstraction that'll round a float up/ down...
james
I use my round to have a defined number of comma digits. 0.12345 --> round 2 --> 0.12 (default is 0)
marius.
#N canvas 25 60 441 377 10; #X msg 194 116 10; #X obj 194 93 loadbang; #X obj 194 138 pow $1; #X obj 79 98 * 1; #X obj 79 23 inlet; #X obj 155 168 / 1; #X msg 155 146 1; #X obj 116 146 + 0.5; #X obj 79 180 div; #X obj 79 227 outlet; #X obj 79 203 * 1; #X obj 79 121 moses 0; #X obj 79 146 - 0.5; #X obj 268 24 inlet; #X text 41 297 rounds to a certain amount of digits after the comma ; #X text 32 267 USE: arg for number of commadigits default = 0; #X obj 268 55 runden; #X text 41 309 0.123456 --> runden 2 --> 0.12; #X text 41 319 0.123456 --> runden 4 --> 0.1235; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 2 0 3 1; #X connect 2 0 5 1; #X connect 2 0 6 0; #X connect 3 0 11 0; #X connect 4 0 3 0; #X connect 5 0 10 1; #X connect 6 0 5 0; #X connect 7 0 8 0; #X connect 8 0 10 0; #X connect 10 0 9 0; #X connect 11 0 12 0; #X connect 11 1 7 0; #X connect 12 0 8 0; #X connect 13 0 16 0; #X connect 16 0 2 1;
Marius Schebella wrote:
james tittle schrieb:
heya,
...looking for a pd object or abstraction that'll round a float up/ down...
james
I use my round to have a defined number of comma digits. 0.12345 --> round 2 --> 0.12 (default is 0)
nice abstraction.
however, i would use [i] instead of [div] (should be faster), and [t b f] instead of [runden] (ok, you'll have to adjust the patchcords a bit, so that the 1st outlet of [t b f] triggers the [10( and the 2nd one goes to the 2nd inlet of [pow])
mfg.asdr IOhannes
IOhannes m zmoelnig schrieb:
however, i would use [i] instead of [div] (should be faster),
hi, thanks for the hints. how do you know [i] is faster than [div], or to say it more precicely how much faster? which brings me to the thought, that would it be possible to have a list of cpu-values/ranking for pd objects? btw. is it faster to have a [bang( message or a [bng] gui? marius.
Marius Schebella schrieb:
IOhannes m zmoelnig schrieb:
however, i would use [i] instead of [div] (should be faster),
hi, thanks for the hints. how do you know [i] is faster than [div], or to say it more precicely how much faster? which brings me to the thought, that would it be possible to have a list of cpu-values/ranking for pd objects? btw. is it faster to have a [bang( message or a [bng] gui? marius.
or a [bang] object? or a [t b]? (both only when converting 'any message' to a bang)
Urs
I read:
thanks for the hints. how do you know [i] is faster than [div], or to
because float to int conversion is simpler than actually dividing
compare:
static void binop3_div_bang(t_binop *x) { int n1 = x->x_f1, n2 = x->x_f2, result; if (n2 < 0) n2 = -n2; else if (!n2) n2 = 1; if (n1 < 0) n1 -= (n2-1); result = n1 / n2; outlet_float(x->x_obj.ob_outlet, (t_float)result); }
to
static void pdint_bang(t_pdint *x) { outlet_float(x->x_obj.ob_outlet, (t_float)(int)(x->x_f)); }
say it more precicely how much faster? which brings me to the thought, that would it be possible to have a list of cpu-values/ranking for pd objects?
the answer to both questions is that this might be quite different depending on architecture, compiler, os, library versions ....
btw. is it faster to have a [bang( message or a [bng] gui?
definitely a [bang ( consumes less resources
HTH
x
Hallo, Marius Schebella hat gesagt: // Marius Schebella wrote:
btw. is it faster to have a [bang( message or a [bng] gui?
Th GUI-[bng] can be much, much, much slower. You should only use it for GUIs, not for logic e.g. to replace a [t b].
Frank Barknecht _ ______footils.org_ __goto10.org__
btw. is it faster to have a [bang( message or a [bng] gui?
Th GUI-[bng] can be much, much, much slower. You should only use it for GUIs, not for logic e.g. to replace a [t b].
there are 3 different bangs; |bng|: gui bang ... very slow, since it sends data over the gui connection
|bang(: the good old bang ... this is slow, too, since the string "bang" is converted to a bang message each time, you use it ...
|bang|: the fastest conversion ... best choice ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
there are 3 different bangs; |bng|: gui bang ... very slow, since it sends data over the gui connection
|bang(: the good old bang ... this is slow, too, since the string "bang" is converted to a bang message each time, you use it ...
|bang|: the fastest conversion ... best choice ...
Just to complete this: There also is [t b]. How would that fit into the equation? Is it the same as [bang]?
Frank Barknecht _ ______footils.org_ __goto10.org__
there are 3 different bangs; |bng|: gui bang ... very slow, since it sends data over the gui connection
|bang(: the good old bang ... this is slow, too, since the string "bang" is converted to a bang message each time, you use it ...
|bang|: the fastest conversion ... best choice ...
Just to complete this: There also is [t b]. How would that fit into the equation? Is it the same as [bang]?
not exactly ... in my view of the _language_ pd these three are bang objects. |t b| is a |trigger| object with the argument "bang". although it shouldn't be much slower than |bang|, i think it introduces some overhead (i haven't checked the source, though)
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
not exactly ... in my view of the _language_ pd these three are bang objects. |t b| is a |trigger| object with the argument "bang". although it shouldn't be much slower than |bang|, i think it introduces some overhead (i haven't checked the source, though)
Well, yes, you're right. However as they are functionally equivalent and as personally I tend to use [t b] a lot more(*) than [bang] (which I practically never use), I'm curious how big the overhead would be.
(*) Because I find myself to often extend a [t b] to become a [t b b b ...] anyway later so I often just start with [t b] instead of [bang]
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo,
Well, yes, you're right. However as they are functionally equivalent and as personally I tend to use [t b] a lot more(*) than [bang] (which I practically never use), I'm curious how big the overhead would be.
(*) Because I find myself to often extend a [t b] to become a [t b b b ...] anyway later so I often just start with [t b] instead of [bang]
i don't have an answer to your question (how big the overhead might be), however i have a (meaningless) remark regarding the use of [t b] instead of [bang]:
adding " b b b" to [t b] is not less work than to change [bang] to [t b b b b]; the patch's functionality will not be touched.
otoh, i myself often use [t b] instead of [bang], as it saves an entire keystroke. which makes me think that a shortcut [b] for [bang] would save even more keystrokes and - ...checking... - indeed, there is an object [b] which is an alias for [bang]. (and changing [b] to [t b b] is probably simpler and more efficient in terms of typing than changing [t b] to the same)
mf.adsr IOhannes
Ciao
On Wed, 12 Oct 2005, Tim Blechmann wrote:
|bang(: the good old bang ... this is slow, too, since the string "bang" is converted to a bang message each time, you use it ...
Hey. Isn't a messagebox, just like other t_objects, reparsing its text at
modification time, using t_binbuf, so that they become t_atoms ? Else,
there wouldn't be a need for decaying ("radioactive") atom types:
A_DOLLAR, A_DOLLSYM, A_COMMA, A_SEMI. Don't you agree?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 12 Oct 2005, Tim Blechmann wrote:
|bang(: the good old bang ... this is slow, too, since the string "bang" is converted to a bang message each time, you use it ...
Hey. Isn't a messagebox, just like other t_objects, reparsing its text at modification time, using t_binbuf, so that they become t_atoms ? Else, there wouldn't be a need for decaying ("radioactive") atom types: A_DOLLAR, A_DOLLSYM, A_COMMA, A_SEMI. Don't you agree?
i don't think so ... i had a look at the code some time ago ... then decided to abandon the use of messageboxes in my patches in favor of |zl reg|, since they are slow ...
haven't had a look at the code lately, but try something like:
|bang~| | |10000| | |until| | |b| or |bang(
to see the difference ...
t