Thanks for the advice and your time, IOhannes.
On Wed, Oct 8, 2014 at 7:17 AM, IOhannes m zmölnig 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 additio
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-pat
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 wrote:
>
>
> Am 06. Oktober 2014 09:22:33 MESZ, schrieb "IOhannes zmölnig" <
> zmoel...@iem.at>:
> >the question is, whether pd should work around system limita
>
> 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 float
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 wrote:
> On Mon, 2014-10-06 at 03:40 +0900, Jonghyun Kim wrote:
> > Thanks for the
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]|
> ||
> [%
Am 06. Oktober 2014 09:22:33 MESZ, schrieb "IOhannes zmölnig" :
>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
On 05. Oktober 2014 20:40:19 MESZ, Jonghyun Kim 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 64b
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 wrote:
> Thanks for the solution. I can understand the actual problem on 32bit. But
> I think still this is a bug.
>
> |
>>
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
(had to find a real compuer before anwering the actual question)
Quoting Jonghyun Kim :
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]
|
On 05. Oktober 2014 17:03:15 MESZ, Jonghyun Kim 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 real
On 05. Oktober 2014 17:04:37 MESZ, Jonghyun Kim 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRI
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 wrote:
> Thanks for your attention. I have a concert tomorrow with PD:) So I can
> post it a few later.
>
> On Mon
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 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
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
I guess, it can be a bug on [%]
On Mon, Oct 6, 2014 at 12:03 AM, Jonghyun Kim 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
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 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
19 matches
Mail list logo
