I've been using [link]x[mass] sending [setK 9, setD 0, setD2 500( to [link] and [setM 10000( to [mass] in a patch and it worked fine when sending a ramp from 0 to 1 with [line]. Just now though it looks like these two objects don't work properly any more as the values produced by [mass] go to something like 1790, which is totally weird. The patch was working half an hour ago (a bit too big to post) and now it's behaving crazy. Any ideas why this happens?
Just an addition to this, there's some more weird behavior. When I have my patch open, with no bangs sent to [link] or [mass], if I open the 01_basic.pd patch from pmpd's examples, I get "error: inlet: expected 'float' but got 'bang'", whereas if I open 01_basics.pd without having my patch open, everything seems to work fine. I'm not using [send] from [metro] to [link] and [mass], but I rather connect them with cords. I'm just sending this one as well in case it's a hint that will help someone who might know what's wrong.
On Tue, Jan 8, 2013 at 7:49 PM, Alexandros Drymonitis adrcki@gmail.comwrote:
I've been using [link]x[mass] sending [setK 9, setD 0, setD2 500( to [link] and [setM 10000( to [mass] in a patch and it worked fine when sending a ramp from 0 to 1 with [line]. Just now though it looks like these two objects don't work properly any more as the values produced by [mass] go to something like 1790, which is totally weird. The patch was working half an hour ago (a bit too big to post) and now it's behaving crazy. Any ideas why this happens?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-08 19:02, Alexandros Drymonitis wrote:
Just an addition to this, there's some more weird behavior. When I have my patch open, with no bangs sent to [link] or [mass], if I open the 01_basic.pd patch from pmpd's examples, I get "error: inlet: expected 'float' but got 'bang'", whereas if I open 01_basics.pd without having my patch open, everything seems to work fine. I'm not using [send] from [metro] to [link] and [mass], but I rather connect them with cords. I'm just sending this one as well in case it's a hint that will help someone who might know what's wrong.
wild guess: you have copied (and modified) the example patch and re-used some of the receiver labels (the first arg to [link]/[mass]), but are now sending other messages to those labels that are not understood by the objects in 01_basics.pd
fgmasdr IOhannes
No, that's not the case. I've actually never really touched the example patch. Anyway, my actual worry is why these objects behave the way they do in my patch, which is really strange. In order to see what's wrong I opened earlier versions of the patch I'm working on (which were using [link] and [mass] fine) and they also show the same strange behavior. It looks like a bug hit it all of a sudden.. I've attached an earlier version which is smaller, if anyone's willing to check. Physical modelling is inside [pd object1], [pd object2] etc. inside [pd coordinates1].. It used to be that the first time you hit the bangs, the rectangles wouldn't behave as expected (in the gem window), but after that everything was working pretty stably. Hope someone can help.
On Tue, Jan 8, 2013 at 8:08 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-08 19:02, Alexandros Drymonitis wrote:
Just an addition to this, there's some more weird behavior. When I have my patch open, with no bangs sent to [link] or [mass], if I open the 01_basic.pd patch from pmpd's examples, I get "error: inlet: expected 'float' but got 'bang'", whereas if I open 01_basics.pd without having my patch open, everything seems to work fine. I'm not using [send] from [metro] to [link] and [mass], but I rather connect them with cords. I'm just sending this one as well in case it's a hint that will help someone who might know what's wrong.
wild guess: you have copied (and modified) the example patch and re-used some of the receiver labels (the first arg to [link]/[mass]), but are now sending other messages to those labels that are not understood by the objects in 01_basics.pd
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDsYJ4ACgkQkX2Xpv6ydvTfuQCg9xakByo1gGTQJFKsR/vErL59 MbEAoMw7mm1n5Ph1UWB1nkMxvs2HWFWh =UmEb -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-08 19:18, Alexandros Drymonitis wrote:
No, that's not the case. I've actually never really touched the example patch. Anyway, my actual worry is why these objects behave the way they do in my patch, which is really strange. In order to see what's wrong I opened earlier versions of the patch I'm working on (which were using [link] and [mass] fine) and they also show the same strange behavior. It looks like a bug hit it all of a sudden.. I've attached an earlier version which is smaller, if anyone's willing to check. Physical modelling is inside [pd object1], [pd object2] etc. inside [pd coordinates1].. It used to be that the first time you hit the bangs, the rectangles wouldn't behave as expected (in the gem window), but after that everything was working pretty stably. Hope someone can help.
i haven't really tried to understand your patch, but you will most likely find, that [trigger] will fix most of your problems.
**never ever connect one message outlet to multiple message inlets; always use [trigger] in such cases**
fgmasdr IOhannes
Well, it's full of [trigger]s..
On Tue, Jan 8, 2013 at 8:25 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-08 19:18, Alexandros Drymonitis wrote:
No, that's not the case. I've actually never really touched the example patch. Anyway, my actual worry is why these objects behave the way they do in my patch, which is really strange. In order to see what's wrong I opened earlier versions of the patch I'm working on (which were using [link] and [mass] fine) and they also show the same strange behavior. It looks like a bug hit it all of a sudden.. I've attached an earlier version which is smaller, if anyone's willing to check. Physical modelling is inside [pd object1], [pd object2] etc. inside [pd coordinates1].. It used to be that the first time you hit the bangs, the rectangles wouldn't behave as expected (in the gem window), but after that everything was working pretty stably. Hope someone can help.
i haven't really tried to understand your patch, but you will most likely find, that [trigger] will fix most of your problems.
**never ever connect one message outlet to multiple message inlets; always use [trigger] in such cases**
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDsZIkACgkQkX2Xpv6ydvSLjACfSdq5S3d5gfewhHix9ZOJhLJ2 ftEAoLwwKnhAX68HaLw1qItWOW3zl6a6 =O2gO -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
From: Alexandros Drymonitis adrcki@gmail.com
Well, it's full of [trigger]s..
[OT] -- hmmmm, why am i suddenly thinking "HAL, Dave, 2001" etc....? .pltk.
...Don't really get it. Anyway, it seems it came back to normal. For some reason it went crazy for some 20 minutes and settled back to what it's supposed to be doing. Hope I don't get this in a couple of days during a gig I have, crossing fingers..
On Tue, Jan 8, 2013 at 8:43 PM, plutek plutek@infinity.net wrote:
From: Alexandros Drymonitis adrcki@gmail.com
Well, it's full of [trigger]s..
[OT] -- hmmmm, why am i suddenly thinking "HAL, Dave, 2001" etc....? .pltk.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-08 19:47, Alexandros Drymonitis wrote:
...Don't really get it. Anyway, it seems it came back to normal. For some reason it went crazy for some 20 minutes and settled back to what it's supposed to be doing. Hope I don't get this in a couple of days during a gig I have, crossing fingers..
that's probably the worst that could have happened, as you now will have an even harder time to fix the problem (but then, it might be ok for you to wait for some 20minutes during the performance, in order to get the system back to normal)
On Tue, Jan 8, 2013 at 8:43 PM, plutek plutek@infinity.net wrote:
From: Alexandros Drymonitis adrcki@gmail.com
Well, it's full of [trigger]s..
there are already a lot of triggers, true. but there is still a number of fan out connections. you should get rid of all of them.
fgmasdr IOhannes
You have a receive sharing the same name as in the example patch. It's in [pd rect-length] and it's [r G]. Not a very specific name... :)
On 08/01/2013 19:18, Alexandros Drymonitis wrote:
No, that's not the case. I've actually never really touched the example patch. Anyway, my actual worry is why these objects behave the way they do in my patch, which is really strange. In order to see what's wrong I opened earlier versions of the patch I'm working on (which were using [link] and [mass] fine) and they also show the same strange behavior. It looks like a bug hit it all of a sudden.. I've attached an earlier version which is smaller, if anyone's willing to check. Physical modelling is inside [pd object1], [pd object2] etc. inside [pd coordinates1].. It used to be that the first time you hit the bangs, the rectangles wouldn't behave as expected (in the gem window), but after that everything was working pretty stably. Hope someone can help.
On Tue, Jan 8, 2013 at 8:08 PM, IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-01-08 19:02, Alexandros Drymonitis wrote: > Just an addition to this, there's some more weird behavior. When I > have my patch open, with no bangs sent to [link] or [mass], if I > open the 01_basic.pd patch from pmpd's examples, I get "error: > inlet: expected 'float' but got 'bang'", whereas if I open > 01_basics.pd without having my patch open, everything seems to work > fine. I'm not using [send] from [metro] to [link] and [mass], but I > rather connect them with cords. I'm just sending this one as well > in case it's a hint that will help someone who might know what's > wrong. wild guess: you have copied (and modified) the example patch and re-used some of the receiver labels (the first arg to [link]/[mass]), but are now sending other messages to those labels that are not understood by the objects in 01_basics.pd fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDsYJ4ACgkQkX2Xpv6ydvTfuQCg9xakByo1gGTQJFKsR/vErL59 MbEAoMw7mm1n5Ph1UWB1nkMxvs2HWFWh =UmEb -----END PGP SIGNATURE----- _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Damn! That was for the length of the letter G for [text2d]. Sorry for that. Still the weird behavior didn't have to do with this, but as I said, it's now gone.
On Tue, Jan 8, 2013 at 8:48 PM, Pierre-Olivier Boulant po.boulant@free.frwrote:
You have a receive sharing the same name as in the example patch. It's in [pd rect-length] and it's [r G]. Not a very specific name... :)
On 08/01/2013 19:18, Alexandros Drymonitis wrote:
No, that's not the case. I've actually never really touched the example patch. Anyway, my actual worry is why these objects behave the way they do in my patch, which is really strange. In order to see what's wrong I opened earlier versions of the patch I'm working on (which were using [link] and [mass] fine) and they also show the same strange behavior. It looks like a bug hit it all of a sudden.. I've attached an earlier version which is smaller, if anyone's willing to check. Physical modelling is inside [pd object1], [pd object2] etc. inside [pd coordinates1].. It used to be that the first time you hit the bangs, the rectangles wouldn't behave as expected (in the gem window), but after that everything was working pretty stably. Hope someone can help.
On Tue, Jan 8, 2013 at 8:08 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-08 19:02, Alexandros Drymonitis wrote:
Just an addition to this, there's some more weird behavior. When I have my patch open, with no bangs sent to [link] or [mass], if I open the 01_basic.pd patch from pmpd's examples, I get "error: inlet: expected 'float' but got 'bang'", whereas if I open 01_basics.pd without having my patch open, everything seems to work fine. I'm not using [send] from [metro] to [link] and [mass], but I rather connect them with cords. I'm just sending this one as well in case it's a hint that will help someone who might know what's wrong.
wild guess: you have copied (and modified) the example patch and re-used some of the receiver labels (the first arg to [link]/[mass]), but are now sending other messages to those labels that are not understood by the objects in 01_basics.pd
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDsYJ4ACgkQkX2Xpv6ydvTfuQCg9xakByo1gGTQJFKsR/vErL59 MbEAoMw7mm1n5Ph1UWB1nkMxvs2HWFWh =UmEb -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
~ Pierre-Olivier Boulant ~ -o- www.puffskydd.net -o- ~ www.flickr.com/pob31/sets ~ -o- www.lepixophone.net -o-