Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
FYI: This subpatch two times duplicated with same name, and the first one works correctly, but the second one has bug. I don't really understand.
I tried: change the subpatch name = no luck delete the subpatch, and re-duplicate = no luck
On Sun, Oct 5, 2014 at 11:49 PM, Jonghyun Kim agitato816@gmail.com wrote:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
I guess, it can be a bug on [%]
On Mon, Oct 6, 2014 at 12:03 AM, Jonghyun Kim agitato816@gmail.com wrote:
FYI: This subpatch two times duplicated with same name, and the first one works correctly, but the second one has bug. I don't really understand.
I tried: change the subpatch name = no luck delete the subpatch, and re-duplicate = no luck
On Sun, Oct 5, 2014 at 11:49 PM, Jonghyun Kim agitato816@gmail.com wrote:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
On 05. Oktober 2014 17:04:37 MESZ, Jonghyun Kim agitato816@gmail.com wrote:
I guess, it can be a bug on [%]
This is *very* unlikely. Most of the times it is save to assume that the bug is in the patch. mfg.fzd.g IOhannes
On 05. Oktober 2014 17:03:15 MESZ, Jonghyun Kim agitato816@gmail.com wrote:
FYI: This subpatch two times duplicated with same name, and the first one works
If you want the same functionality *multiple* times, thou shalt use abstractions (and not subpatches)
correctly, but the second one has bug. I don't really understand.
I tried: change the subpatch name = no luck
the name of a subpatch is *purely* cosmetic. You can change it without affecting any functionality (including (no) resets: this is different from the rest of pd)
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
The ASCII patch is a bit ambiguous. could you post it as an attachment?
On 10/05/2014 11:49 PM, Jonghyun Kim wrote:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks for your attention. I have a concert tomorrow with PD:) So I can post it a few later.
On Mon, Oct 6, 2014 at 12:05 AM, Max abonnements@revolwear.com wrote:
The ASCII patch is a bit ambiguous. could you post it as an attachment?
On 10/05/2014 11:49 PM, Jonghyun Kim wrote:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
I don't really understand about this.
I closed Pd, and reloaded the patch, then bug disappeared. I can't reproduce this bug anymore...
On Mon, Oct 6, 2014 at 12:15 AM, Jonghyun Kim agitato816@gmail.com wrote:
Thanks for your attention. I have a concert tomorrow with PD:) So I can post it a few later.
On Mon, Oct 6, 2014 at 12:05 AM, Max abonnements@revolwear.com wrote:
The ASCII patch is a bit ambiguous. could you post it as an attachment?
On 10/05/2014 11:49 PM, Jonghyun Kim wrote:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
(had to find a real compuer before anwering the actual question)
Quoting Jonghyun Kim agitato816@gmail.com:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
this very much sounds like a problem with floating point precision overrun.
an [f] object (and actually *any* number within the Pd universe) will
hold a single precision 32bit floating point number, which can only
represent *consecutive* integer values up to 16777216.
(consecutive means, that [f] can hold representations of both (e.g.)
1000023 and 1000024).
if the numbers go higher, singple precision floats will have gaps
bigger than 1.0 inbetween them (e.g. the next number after 16777216
representable by [f] is 16777218) - this breaks a counter that
increments 1 (since 16777216+1 will be evaulated to ~16777216!)
the solution is actually quite simple: never allow your number to grow
as big as that.
in your counter this means, that the feeback part, must include the [%
6] (so the numbers in the counter will only ever stay in the range
0..6):
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
btw, you ASCII rendering of the patch did not use [trigger]. you
should always use it when you want to connect multiple inlets to a
single outlet.
mfgsdr IOhannes
Thanks for the solution. I can understand the actual problem on 32bit. But I think still this is a bug.
|
| +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
Could you give me the patch again with easily drawing? Sorry I can't recognize your patch drawing...
Many thanks, akntk
On Mon, Oct 6, 2014 at 1:22 AM, zmoelnig@iem.at wrote:
(had to find a real compuer before anwering the actual question)
Quoting Jonghyun Kim agitato816@gmail.com:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
this very much sounds like a problem with floating point precision overrun. an [f] object (and actually *any* number within the Pd universe) will hold a single precision 32bit floating point number, which can only represent *consecutive* integer values up to 16777216. (consecutive means, that [f] can hold representations of both (e.g.) 1000023 and 1000024). if the numbers go higher, singple precision floats will have gaps bigger than 1.0 inbetween them (e.g. the next number after 16777216 representable by [f] is 16777218) - this breaks a counter that increments 1 (since 16777216+1 will be evaulated to ~16777216!)
the solution is actually quite simple: never allow your number to grow as big as that.
in your counter this means, that the feeback part, must include the [% 6] (so the numbers in the counter will only ever stay in the range 0..6):
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
btw, you ASCII rendering of the patch did not use [trigger]. you should always use it when you want to connect multiple inlets to a single outlet.
mfgsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
FYI: I used very fast metronome [metro 1] or [metro 0.1], so I think the float value(allowed under 32bit) maximized so quickly.
On Mon, Oct 6, 2014 at 3:40 AM, Jonghyun Kim agitato816@gmail.com wrote:
Thanks for the solution. I can understand the actual problem on 32bit. But I think still this is a bug.
|
| +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
Could you give me the patch again with easily drawing? Sorry I can't recognize your patch drawing...
Many thanks, akntk
On Mon, Oct 6, 2014 at 1:22 AM, zmoelnig@iem.at wrote:
(had to find a real compuer before anwering the actual question)
Quoting Jonghyun Kim agitato816@gmail.com:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
this very much sounds like a problem with floating point precision overrun. an [f] object (and actually *any* number within the Pd universe) will hold a single precision 32bit floating point number, which can only represent *consecutive* integer values up to 16777216. (consecutive means, that [f] can hold representations of both (e.g.) 1000023 and 1000024). if the numbers go higher, singple precision floats will have gaps bigger than 1.0 inbetween them (e.g. the next number after 16777216 representable by [f] is 16777218) - this breaks a counter that increments 1 (since 16777216+1 will be evaulated to ~16777216!)
the solution is actually quite simple: never allow your number to grow as big as that.
in your counter this means, that the feeback part, must include the [% 6] (so the numbers in the counter will only ever stay in the range 0..6):
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
btw, you ASCII rendering of the patch did not use [trigger]. you should always use it when you want to connect multiple inlets to a single outlet.
mfgsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 05. Oktober 2014 20:40:19 MESZ, Jonghyun Kim agitato816@gmail.com wrote:
Thanks for the solution. I can understand the actual problem on 32bit.
You might be confusing things here: Currently pd will always uses single precision floats (which happen to have 32bit on all known platforms), even when run "on" a 64bit system.
But I think still this is a bug.
Yes, in your patch :-) the question is, whether pd should work around system limitations. Eg if you ask it for a tabke with 10 tera-samples and you only have 4gb ram, should it...
|
| +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
Could you give me the patch again with easily drawing? Sorry I can't recognize your patch drawing...
check it with a monospaced font. (and no, i cannot redraw it on my smartphone).
Many thanks, akntk
On Mon, Oct 6, 2014 at 1:22 AM, zmoelnig@iem.at wrote:
(had to find a real compuer before anwering the actual question)
Quoting Jonghyun Kim agitato816@gmail.com:
Pd 0.45.5 (Vanilla) Mac OS X Mavericks 10.9.5
I don't really know why this bug cause, or only my problem. This bug sometimes appears. I think this is very critical bug. [f] storing bug
[metro 1] | [f 0] | / [+ 1] | [% 6]
respected result: 0, 1, 2, 3, 4, 5 (repeat)
bug: 4, 4, 4, 4, 4 (always 4)
this very much sounds like a problem with floating point precision
overrun.
an [f] object (and actually *any* number within the Pd universe) will
hold
a single precision 32bit floating point number, which can only
represent
*consecutive* integer values up to 16777216. (consecutive means, that [f] can hold representations of both (e.g.) 1000023 and 1000024). if the numbers go higher, singple precision floats will have gaps
bigger
than 1.0 inbetween them (e.g. the next number after 16777216
representable
by [f] is 16777218) - this breaks a counter that increments 1 (since 16777216+1 will be evaulated to ~16777216!)
the solution is actually quite simple: never allow your number to
grow as
big as that.
in your counter this means, that the feeback part, must include the
[% 6]
(so the numbers in the counter will only ever stay in the range
0..6):
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
btw, you ASCII rendering of the patch did not use [trigger]. you
should
always use it when you want to connect multiple inlets to a single
outlet.
mfgsdr IOhannes
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
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
Am 06. Oktober 2014 09:22:33 MESZ, schrieb "IOhannes zmölnig" zmoelnig@iem.at:
the question is, whether pd should work around system limitations. Eg if you ask it for a tabke with 10 tera-samples and you only have 4gb ram, should it...
Should have read "table". sorry for the typos, i'm having troubles with my mail client.
The point i was trying to make, is that there are some limitations that cannot be worked around realistically and which make a seemingly fine program (patch) not behave as expected. mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
problem solved! thanks for all. Zack Lee commented this solution on facebook group.
On Mon, Oct 6, 2014 at 4:58 PM, IOhannes zmölnig zmoelnig@iem.at wrote:
Am 06. Oktober 2014 09:22:33 MESZ, schrieb "IOhannes zmölnig" < zmoelnig@iem.at>:
the question is, whether pd should work around system limitations. Eg if you ask it for a tabke with 10 tera-samples and you only have 4gb ram, should it...
Should have read "table". sorry for the typos, i'm having troubles with my mail client.
The point i was trying to make, is that there are some limitations that cannot be worked around realistically and which make a seemingly fine program (patch) not behave as expected. mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You might be confusing things here: Currently pd will always uses single precision floats (which happen to have 32bit on all known platforms), even when run "on" a 64bit system.
Thanks for the info. I didn't know about that. Currently I'm on 64bit Mac OS X, but Pd uses still 32bit floats.
On Mon, 2014-10-06 at 03:40 +0900, Jonghyun Kim wrote:
Thanks for the solution. I can understand the actual problem on 32bit. But I think still this is a bug.
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |Could you give me the patch again with easily drawing? Sorry I can't recognize your patch drawing...
Specifically for mailing lists, I strongly recommend to:
- write plain text mails (no html formatting)
- use a monospaced font in your mail client
This makes life on mailing lits a lot easier.
Roman
I attached the patch. I understand what is the problem, but I don't have the real solution for this. I want to know how to prevent this situation.
many thanks, akntk
On Mon, Oct 6, 2014 at 8:30 PM, Roman Haefeli reduzent@gmail.com wrote:
On Mon, 2014-10-06 at 03:40 +0900, Jonghyun Kim wrote:
Thanks for the solution. I can understand the actual problem on 32bit. But I think still this is a bug.
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |Could you give me the patch again with easily drawing? Sorry I can't recognize your patch drawing...
Specifically for mailing lists, I strongly recommend to:
- write plain text mails (no html formatting)
- use a monospaced font in your mail client
This makes life on mailing lits a lot easier.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 10/07/2014 08:51 PM, Jonghyun Kim wrote:
I attached the patch.
thanks. for the future, it would be welcome if you only attached the pd-patch. the png does not add any additional information, might not show the actual problem and is (in the specific case) about 80 times bigger than the pd-patch.
I understand what is the problem, but I don't have the real solution for this. I want to know how to prevent this situation.
my ascii-art patch should have given you the clue:
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |
#0 use trigger whenever you want to connect a single outlet to multiple inlets (this is general advice, and is not related to your *current* problem)
#1 keep the [% 6] in the loop. it will make sure that the number that is incremented will never get into the problematic range (even if you force it to a too-high value (e.g. by sending a large number directly into the counter) it will bring the values down to an operable range and thus "magically" fix the problem in the next iteration.
gfmasdr IOhannes
Thanks for the advice and your time, IOhannes.
On Wed, Oct 8, 2014 at 7:17 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 10/07/2014 08:51 PM, Jonghyun Kim wrote:
I attached the patch.
thanks. for the future, it would be welcome if you only attached the pd-patch. the png does not add any additional information, might not show the actual problem and is (in the specific case) about 80 times bigger than the pd-patch.
I understand what is the problem, but I don't have the real solution for this. I want to know how to prevent this situation.
my ascii-art patch should have given you the clue:
| | +------+ [f] | | | [+ 1] | | | [% 6] | | | [t f f] | | +--+ |#0 use trigger whenever you want to connect a single outlet to multiple inlets (this is general advice, and is not related to your *current* problem)
#1 keep the [% 6] in the loop. it will make sure that the number that is incremented will never get into the problematic range (even if you force it to a too-high value (e.g. by sending a large number directly into the counter) it will bring the values down to an operable range and thus "magically" fix the problem in the next iteration.
gfmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmölnig -
IOhannes zmölnig
-
Jonghyun Kim -
Max -
Roman Haefeli -
zmoelnig＠iem.at