Re: [PD] bang vs empty list
IOhannes,
Your patch has one regression:
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol *s, int
argc, t_atom *argv)
else if (u-u_type == TR_SYMBOL)
outlet_symbol(u-u_outlet,
(argc ? atom_getsymbol(argv) : s_symbol));
+else if (u-u_type == TR_ANYTHING)
+outlet_anything(u-u_outlet, s, argc, argv);
else if (u-u_type == TR_POINTER)
{
if (!argc || argv-a_type != TR_POINTER)
This part causes pointers to not properly propagate through the trigger
objects. If you run scalar-help.pd file (part of pd-extended/pd-l2ork
documentation developed by Jonathan and others), clicking on scalars that
should animate generates an error. Removing this works fine for scalars but I
wonder if it then disables functionality of the patch you provided.
Any thoughts?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 03:12 PM, Ivica Ico Bukvic wrote:
IOhannes,
Your patch has one regression:
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol
*s, int argc, t_atom *argv)
else if (u-u_type == TR_SYMBOL)
outlet_symbol(u-u_outlet,
(argc ? atom_getsymbol(argv) : s_symbol));
+else if (u-u_type == TR_ANYTHING)
+outlet_anything(u-u_outlet, s, argc, argv);
else if (u-u_type == TR_POINTER)
{
if (!argc || argv-a_type != TR_POINTER)
This part causes pointers to not properly propagate through the
trigger objects. If you run scalar-help.pd file (part of
pd-extended/pd-l2ork documentation developed by Jonathan and others),
clicking on scalars that should animate generates an error. Removing
this works fine for scalars but I wonder if it then disables
functionality of the patch you provided.
Any thoughts?
As of right now, I cannot see any regressions by removing that part
since at the end it does output_list call anyhow. Can you test this/confirm?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 20:26, Ivica Ico Bukvic wrote:
On 03/21/2013 03:12 PM, Ivica Ico Bukvic wrote:
IOhannes,
hi
Your patch has one regression:
thanks for reporting
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol
*s, int argc, t_atom *argv)
else if (u-u_type == TR_SYMBOL)
outlet_symbol(u-u_outlet,
(argc ? atom_getsymbol(argv) : s_symbol));
+else if (u-u_type == TR_ANYTHING)
+outlet_anything(u-u_outlet, s, argc, argv);
else if (u-u_type == TR_POINTER)
{
if (!argc || argv-a_type != TR_POINTER)
[...]
Any thoughts?
yep.
outlet_list() is *not* the same as outlet_anything()
As of right now, I cannot see any regressions by removing that part
since at the end it does output_list call anyhow. Can you test
this/confirm?
i cannot test right now, but i'm pretty sure that removing that very
line makes my entire patch obsolete and reverts to the old behaviour.
which errors do you get?
fgmadsr
IOhannes
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 20:47, IOhannes m zmölnig wrote: which errors do you get? inlet: expected 'pointer' but got 'pointer' how cool is that? fgmsrd IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 21:02, IOhannes m zmölnig wrote:
inlet: expected 'pointer' but got 'pointer'
so having a short go into m_class.c, it seems indeed that the
c_pointermethod is called from within the list-method.
the attached patch should fix this, by using the list selector when
outputting pointers through [trigger].
this should be totally compatible to the original behaviour (regarding
pointers):
org: outlet_list(out, 0 , 1, ptratom);
new: outlet_anything(out, s_list, 1, ptratom);
nevertheless it's probably good to hear some pointer expert's (e.g.
miller's) opinion about how this *should* be handled.
fgmasrd
IOhannes
From 0830fff9c3c6533c3a68ded1f921acc66b4a9c24 Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig zmoel...@umlauto.umlaeute.mur.at
Date: Thu, 21 Mar 2013 21:13:16 +0100
Subject: [PATCH 3/3] pointers are output as lists
a pointer message is really a list ptr rather than
pointer ptr (which i would have guessed due to the
existance of 's_pointer').
this can be confirmed by sending a pointer via [t a] to the
right inlet of [set] (which gives the error:
inlet: expected 'pointer' but got 'pointer'
checking back in m_class.c, it seems that the pointer-method
will only ever get called from within the pd_defaultlist.
---
src/x_connective.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/x_connective.c b/src/x_connective.c
index 0ac8cc6..08cb97c 100644
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -1026,7 +1026,7 @@ static void trigger_pointer(t_trigger *x, t_gpointer *gp)
{
t_atom at;
SETPOINTER(at, gp);
-trigger_list(x, s_pointer, 1, at);
+trigger_list(x, s_list, 1, at);
}
static void trigger_float(t_trigger *x, t_float f)
--
1.7.10.4
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-03-01 18:03, Ivica Bukvic wrote: This makes perfect sense. However, I have at least a couple of patches where I have a select connected to a networked stream of messages one which includes bang. So after I have to appied IOhannes' patch, this effectively resulted in a regression where bang messages were not recognized by the select object, throwing a large number of errors. While one can argue that this is simply a poorly designed patch the other side of the coin is to say that this latest addition has caused a breakage in the existing patches as this problem was never reported by pd before and now is causing xruns. I also hear your call for consistency so I am open for going either way particularly because the example you gave did not use select. After all what follows from select is nothing more than a bang while symbol bang would be intercepted anyways. thanks for the test. however, i'm not entirely sure whether this is really a regression (or a poorly designed patch). my patch will make empty lists do something meaningful (that is: check whether the object can handle them) rather than simply ignore them, but that was the point of the patch. before my patch, [select] would emit a no method for 'bang' whenever it received a [bang(, and it would do nothing when it received a [list( (neither accept nor reject the message through it's designated outlets). now it will emit a no method for 'list' whenever it gets a [list(, and retain the original behaviour for all other messages. this is the intended behaviour. i tried to reproduce your test-case, but it seems to behave differently on pd-vanilla than on pd-l2ork. this is what i tried: [connect localhost ( [r data] | | | +-+ | [netsend] [netreceive ] | [select] doing a [;data send bang( will give me a select: no method for 'bang' both with and without my patch applied. doing a [;data send( will give me nothing both with and without my patch applied (since [netsend] will not send an empty message). could this be a regression in [dsis_netsend]/[dsis_netreceive] that has been exposed by my patch? maybe it would help if you posted a patch that exposes the problem. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE0WiMACgkQkX2Xpv6ydvRsxwCg8vxkb3JB4SKisMki5J5twdPD K98AoIEsBMLZ1KNrUvhDZfTuYaHEgu+M =Sr1k -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
- Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at Cc: Sent: Thursday, February 28, 2013 7:15 PM Subject: Re: [PD] bang vs empty list BTW, the only regression with this is that [select] object complains it does not understand bang. Pd's [select] only understands symbol and float messages. If you make it accept bangs then you create an inconsistency where both symbol bang and bang are matched by [sel bang]. -Jonathan I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ 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
Re: [PD] bang vs empty list
Yes, but it also prevents profuse errors on the console regarding how select does not understand things which may happen in complex patches under certain circumstances, and which previously were not reported. On Mar 1, 2013 3:29 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at Cc: Sent: Thursday, February 28, 2013 7:15 PM Subject: Re: [PD] bang vs empty list BTW, the only regression with this is that [select] object complains it does not understand bang. Pd's [select] only understands symbol and float messages. If you make it accept bangs then you create an inconsistency where both symbol bang and bang are matched by [sel bang]. -Jonathan I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ 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
Re: [PD] bang vs empty list
To add to this, I cannot think of a scenario where you would want to differentiate between bang versus symbol bang. Please feel free to convince me otherwise. On Mar 1, 2013 7:50 AM, Ivica Bukvic i...@vt.edu wrote: Yes, but it also prevents profuse errors on the console regarding how select does not understand things which may happen in complex patches under certain circumstances, and which previously were not reported. On Mar 1, 2013 3:29 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at Cc: Sent: Thursday, February 28, 2013 7:15 PM Subject: Re: [PD] bang vs empty list BTW, the only regression with this is that [select] object complains it does not understand bang. Pd's [select] only understands symbol and float messages. If you make it accept bangs then you create an inconsistency where both symbol bang and bang are matched by [sel bang]. -Jonathan I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ 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
Re: [PD] bang vs empty list
From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 7:55 AM Subject: Re: [PD] bang vs empty list To add to this, I cannot think of a scenario where you would want to differentiate between bang versus symbol bang. Please feel free to convince me otherwise. Just one example: If you parse a Pd patch in Pd you'll want to handle everything as lists, because the moment you shave off the list selector you're in danger of outputting bad messages: #X text 10 10 INLET_0 bang float symbol | [route #X] | [route text] | [route 10] | [route 10] | [route INLET_0] | [route bang] | [route float] -- oops, float got silently discarded above Of course that's just a didactic example, because in real life you would iterate over the message one atom at a time, and if bang and float had been switched above you'd even get an explicit error about Bad arguments (since float needs to be followed by a float atom and not the symbol atom bang). Therefore you have to use list objects to ensure you don't lose data or run into a badly formed mesage, and when you split lists you end up with symbol bang which [select] handles perfectly well. The point is that select inspects the payload of the message and not the selector. Bang messages don't have a payload so you've now made a special case where the selector is inspected only if the user types bang as an arg. The [route] object already chooses bases on selector so I don't see a reason to change the behavior for [select] in this way. -Jonathan On Mar 1, 2013 7:50 AM, Ivica Bukvic i...@vt.edu wrote: Yes, but it also prevents profuse errors on the console regarding how select does not understand things which may happen in complex patches under certain circumstances, and which previously were not reported. On Mar 1, 2013 3:29 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at Cc: Sent: Thursday, February 28, 2013 7:15 PM Subject: Re: [PD] bang vs empty list BTW, the only regression with this is that [select] object complains it does not understand bang. Pd's [select] only understands symbol and float messages. If you make it accept bangs then you create an inconsistency where both symbol bang and bang are matched by [sel bang]. -Jonathan I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ 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
Re: [PD] bang vs empty list
This makes perfect sense. However, I have at least a couple of patches where I have a select connected to a networked stream of messages one which includes bang. So after I have to appied IOhannes' patch, this effectively resulted in a regression where bang messages were not recognized by the select object, throwing a large number of errors. While one can argue that this is simply a poorly designed patch the other side of the coin is to say that this latest addition has caused a breakage in the existing patches as this problem was never reported by pd before and now is causing xruns. I also hear your call for consistency so I am open for going either way particularly because the example you gave did not use select. After all what follows from select is nothing more than a bang while symbol bang would be intercepted anyways. On Mar 1, 2013 11:47 AM, Jonathan Wilkes jancs...@yahoo.com wrote: From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 7:55 AM Subject: Re: [PD] bang vs empty list To add to this, I cannot think of a scenario where you would want to differentiate between bang versus symbol bang. Please feel free to convince me otherwise. Just one example: If you parse a Pd patch in Pd you'll want to handle everything as lists, because the moment you shave off the list selector you're in danger of outputting bad messages: #X text 10 10 INLET_0 bang float symbol | [route #X] | [route text] | [route 10] | [route 10] | [route INLET_0] | [route bang] | [route float] -- oops, float got silently discarded above Of course that's just a didactic example, because in real life you would iterate over the message one atom at a time, and if bang and float had been switched above you'd even get an explicit error about Bad arguments (since float needs to be followed by a float atom and not the symbol atom bang). Therefore you have to use list objects to ensure you don't lose data or run into a badly formed mesage, and when you split lists you end up with symbol bang which [select] handles perfectly well. The point is that select inspects the payload of the message and not the selector. Bang messages don't have a payload so you've now made a special case where the selector is inspected only if the user types bang as an arg. The [route] object already chooses bases on selector so I don't see a reason to change the behavior for [select] in this way. -Jonathan On Mar 1, 2013 7:50 AM, Ivica Bukvic i...@vt.edu wrote: Yes, but it also prevents profuse errors on the console regarding how select does not understand things which may happen in complex patches under certain circumstances, and which previously were not reported. On Mar 1, 2013 3:29 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at Cc: Sent: Thursday, February 28, 2013 7:15 PM Subject: Re: [PD] bang vs empty list BTW, the only regression with this is that [select] object complains it does not understand bang. Pd's [select] only understands symbol and float messages. If you make it accept bangs then you create an inconsistency where both symbol bang and bang are matched by [sel bang]. -Jonathan I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ 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
Re: [PD] bang vs empty list
From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 12:03 PM Subject: Re: [PD] bang vs empty list This makes perfect sense. However, I have at least a couple of patches where I have a select connected to a networked stream of messages one which includes bang. So after I have to appied IOhannes' patch, this effectively resulted in a regression where bang messages were not recognized by the select object, throwing a large number of errors. I don't understand. When did you change [select] to accept bang messages? Or are you saying that you were receiving the message list and it went unreported? While one can argue that this is simply a poorly designed patch the other side of the coin is to say that this latest addition has caused a breakage in the existing patches as this problem was never reported by pd before and now is causing xruns. I also hear your call for consistency so I am open for going either way particularly because the example you gave did not use select. After all what follows from select is nothing more than a bang while symbol bang would be intercepted anyways. There are probably very few cases where one would actually need to differentiate between bang and symbol bang using [select], but it seems like bad design to let two distinct messages trigger the same behavior in an object whose sole purpose is to differentiate messages from each other. Anyway, you could fix your patches simply by inserting [route bang] before your [select]. -Jonathan On Mar 1, 2013 11:47 AM, Jonathan Wilkes jancs...@yahoo.com wrote: From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 7:55 AM Subject: Re: [PD] bang vs empty list To add to this, I cannot think of a scenario where you would want to differentiate between bang versus symbol bang. Please feel free to convince me otherwise. Just one example: If you parse a Pd patch in Pd you'll want to handle everything as lists, because the moment you shave off the list selector you're in danger of outputting bad messages: #X text 10 10 INLET_0 bang float symbol | [route #X] | [route text] | [route 10] | [route 10] | [route INLET_0] | [route bang] | [route float] -- oops, float got silently discarded above Of course that's just a didactic example, because in real life you would iterate over the message one atom at a time, and if bang and float had been switched above you'd even get an explicit error about Bad arguments (since float needs to be followed by a float atom and not the symbol atom bang). Therefore you have to use list objects to ensure you don't lose data or run into a badly formed mesage, and when you split lists you end up with symbol bang which [select] handles perfectly well. The point is that select inspects the payload of the message and not the selector. Bang messages don't have a payload so you've now made a special case where the selector is inspected only if the user types bang as an arg. The [route] object already chooses bases on selector so I don't see a reason to change the behavior for [select] in this way. -Jonathan On Mar 1, 2013 7:50 AM, Ivica Bukvic i...@vt.edu wrote: Yes, but it also prevents profuse errors on the console regarding how select does not understand things which may happen in complex patches under certain circumstances, and which previously were not reported. On Mar 1, 2013 3:29 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at Cc: Sent: Thursday, February 28, 2013 7:15 PM Subject: Re: [PD] bang vs empty list BTW, the only regression with this is that [select] object complains it does not understand bang. Pd's [select] only understands symbol and float messages. If you make it accept bangs then you create an inconsistency where both symbol bang and bang are matched by [sel bang]. -Jonathan I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ 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
Re: [PD] bang vs empty list
On Mar 1, 2013 12:14 PM, Jonathan Wilkes jancs...@yahoo.com wrote: From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 12:03 PM Subject: Re: [PD] bang vs empty list This makes perfect sense. However, I have at least a couple of patches where I have a select connected to a networked stream of messages one which includes bang. So after I have to appied IOhannes' patch, this effectively resulted in a regression where bang messages were not recognized by the select object, throwing a large number of errors. I don't understand. When did you change [select] to accept bang messages? Or are you saying that you were receiving the message list and it went unreported? Yes they were being registered as list that before IOhannes' patch and now are being reported as errors. so I opted for the select patch I proposed above. While one can argue that this is simply a poorly designed patch the other side of the coin is to say that this latest addition has caused a breakage in the existing patches as this problem was never reported by pd before and now is causing xruns. I also hear your call for consistency so I am open for going either way particularly because the example you gave did not use select. After all what follows from select is nothing more than a bang while symbol bang would be intercepted anyways. There are probably very few cases where one would actually need to differentiate between bang and symbol bang using [select], but it seems like bad design to let two distinct messages trigger the same behavior in an object whose sole purpose is to differentiate messages from each other. At the same time I think having to cover bang to symbol bang just to have it selectable by select does not seem very intuitive to me. How would you even do that in the first place if there's more than just a bang coming into that inlet, e.g. a bang and float values? You couldn't use [symbol] before it as that would trash float values. Anyway, you could fix your patches simply by inserting [route bang] before your [select]. That is what I did, but that does not address the issue above. -Jonathan On Mar 1, 2013 11:47 AM, Jonathan Wilkes jancs...@yahoo.com wrote: From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 7:55 AM Subject: Re: [PD] bang vs empty list To add to this, I cannot think of a scenario where you would want to differentiate between bang versus symbol bang. Please feel free to convince me otherwise. Just one example: If you parse a Pd patch in Pd you'll want to handle everything as lists, because the moment you shave off the list selector you're in danger of outputting bad messages: #X text 10 10 INLET_0 bang float symbol | [route #X] | [route text] | [route 10] | [route 10] | [route INLET_0] | [route bang] | [route float] -- oops, float got silently discarded above Of course that's just a didactic example, because in real life you would iterate over the message one atom at a time, and if bang and float had been switched above you'd even get an explicit error about Bad arguments (since float needs to be followed by a float atom and not the symbol atom bang). Therefore you have to use list objects to ensure you don't lose data or run into a badly formed mesage, and when you split lists you end up with symbol bang which [select] handles perfectly well. The point is that select inspects the payload of the message and not the selector. Bang messages don't have a payload so you've now made a special case where the selector is inspected only if the user types bang as an arg. The [route] object already chooses bases on selector so I don't see a reason to change the behavior for [select] in this way. -Jonathan On Mar 1, 2013 7:50 AM, Ivica Bukvic i...@vt.edu wrote: Yes, but it also prevents profuse errors on the console regarding how select does not understand things which may happen in complex patches under certain circumstances, and which previously were not reported. On Mar 1, 2013 3:29 AM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at Cc: Sent: Thursday, February 28, 2013 7:15 PM Subject: Re: [PD] bang vs empty list BTW, the only regression with this is that [select] object complains it does not understand bang. Pd's [select] only understands symbol and float messages. If you make it accept bangs then you create an inconsistency where both symbol bang and bang are matched by [sel bang]. -Jonathan I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I
Re: [PD] bang vs empty list
From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 1:41 PM Subject: Re: [PD] bang vs empty list On Mar 1, 2013 12:14 PM, Jonathan Wilkes jancs...@yahoo.com wrote: From: Ivica Bukvic i...@vt.edu To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Sent: Friday, March 1, 2013 12:03 PM Subject: Re: [PD] bang vs empty list This makes perfect sense. However, I have at least a couple of patches where I have a select connected to a networked stream of messages one which includes bang. So after I have to appied IOhannes' patch, this effectively resulted in a regression where bang messages were not recognized by the select object, throwing a large number of errors. I don't understand. When did you change [select] to accept bang messages? Or are you saying that you were receiving the message list and it went unreported? Yes they were being registered as list that before IOhannes' patch and now are being reported as errors. so I opted for the select patch I proposed above. While one can argue that this is simply a poorly designed patch the other side of the coin is to say that this latest addition has caused a breakage in the existing patches as this problem was never reported by pd before and now is causing xruns. I also hear your call for consistency so I am open for going either way particularly because the example you gave did not use select. After all what follows from select is nothing more than a bang while symbol bang would be intercepted anyways. There are probably very few cases where one would actually need to differentiate between bang and symbol bang using [select], but it seems like bad design to let two distinct messages trigger the same behavior in an object whose sole purpose is to differentiate messages from each other. At the same time I think having to cover bang to symbol bang just to have it selectable by select does not seem very intuitive to me. How would you even do that in the first place if there's more than just a bang coming into that inlet, e.g. a bang and float values? You couldn't use [symbol] before it as that would trash float values. Outputting the message from [textfile] (which has its own problems because it outputs anything instead of list), then something like [list-drip]. Splitting the message up in the list domain ensures that you won't lose data since everything is treated as a list. So if there is the word bang somewhere in the middle of the message it will come out of [list-drip] (or a home-brewed one using [list split]) as list bang which gets interpreted by [select] as a symbol message. That's the only way to parse a text file in Pd without running into errors (although you'll still lose data, for example, if consecutive whitespaces are needed, or special characters that Pd escapes, etc.). -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i guess i'm missing something, but... On 2013-02-28 00:38, Charles Z Henry wrote: Each class has methods that can be looked up by symbol. At some point after the class has been created, you could check the class has no bang method, and if so, add the default bang method. Only built-in classes are loaded when pd starts up, so if you load a class later, it would not have the default method. each object has a default method, namely the defaul catch-all (aka anything) method, that will print no method for foo. not having an explicit bang method, will defer the bang message to this catch-all method. If you wanted it done at setup time, you would have to modify the function that calls the setup function (I don't know what it is or how it's done--please tell me) so you would follow the setup function and add default methods. not sure whether i totally understand what you mean by setup time (and setup function) here. the function that calls the setup function does not do anything special (it just calls an entry point in a dll). especially, it does notmake any assumptions what this setup function is going to perform (though in most cases it will register some classes). so, the only function that needed to be changed would be the generic class-creator function class_new(). nevertheless i don't see what this would solve with respect to the current behaviour. i can imagine that the problems you are trying to solve are caused by Pd's automatic conversions between different types (e.g. [list 12( and [float 12(). if you removed all those conversions, you would immediately get your desired behaviour. and people would start complaining why the following gives an error [sin]: no method for 'list'. [1 2 3( | [list split 1] | [sin] this can of course be fixed by simply adding an explicit list method to [sin], which does the right thing. but all the problems that arise because of the automatic message conversion can already be solved by adding explicit methods for messages you don't want to be autoconverted. btw, i think something really nice to have would be per-object methods (as oppposed to per-class methods). for this to work, the object would need a copy of the class method table (rather than a reference). fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEvFakACgkQkX2Xpv6ydvS4vgCfa5l8LEuR8IhDQdqPtH/VE7qX 860An0vDf9w36U/I4qxD7si1pLX5CVT4 =9kvD -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-02-26 02:17, Jonathan Wilkes wrote:
Seems like for any object that doesn't have a bang method nor list
method, an empty list silently gets discarded.
[...]
Is there a way to fix this?
sure :-)
the default list method will try to do something clever with the empty
list:
- - if there is a non-default bangmethod, it will call that (which is
not the case for [sin])
- - elif there is a non-default catchall method, it will call that
(which is not the case for [sin])
- - elif the object has inlets (which is the case for [sin]), it will
distribute the atoms over the inlets. since there are 0 atoms, no
inlet will receive any data.
- - else call the default catchall method.
so i think there are two things to fix:
1. Pd shouldn't try to fill an empty list to the objects inlets.
2. [t a] should not output an empty list if it receives a [bang(
attached are fixes for both problems (actually the 2nd patch makes [t
a] output the message as it came in, rather than converting it to a
list - so it also fixes the problem for numbers and symbols, not only
for bangs)
i rely on the community to test them thorougly :-)
there are still some weirdos though:
[float 42, list 666, list, foo(
|
[t s]
|
[print]
i wonder what the correct behaviour should actually be.
intuitively i would say that for non-symbols, [t s] should output the
selector as a symbol (if we don't want to introduce %d semantics
which i would rather not for performance reasons).
this would also make sense for anythings, where we currently get that
weird only convert 's' to 'b' or 'a' (it's weird insofar as it takes
some time to see what the 's' is referring to)
fgm,asdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEvIWQACgkQkX2Xpv6ydvROxQCcCySUREYwDdUEAQwkHpq/oSVX
TJUAoMxAjB4wZwUGy+QiOAoSwY2o7xLF
=56Tj
-END PGP SIGNATURE-
From 049904da3f4019593e6565bb7b2723b5154f5e87 Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig zmoel...@iem.at
Date: Thu, 28 Feb 2013 10:05:45 +0100
Subject: [PATCH 1/3] don't unpack empty lists to object's inlets
since the list is empty, this will effectively be a no-op
(and thus an empty list is silently discarded).
better call the pd_defaultanything() method.
---
src/m_class.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/m_class.c b/src/m_class.c
index bbc2fe7..3fb6d5c 100644
--- a/src/m_class.c
+++ b/src/m_class.c
@@ -132,7 +132,7 @@ static void pd_defaultlist(t_pd *x, t_symbol *s, int argc, t_atom *argv)
/* if the object is patchable (i.e., can have proper inlets)
send it on to obj_list which will unpack the list into the inlets */
-else if ((*x)-c_patchable)
+else if (argc0 (*x)-c_patchable)
obj_list((t_object *)x, s, argc, argv);
/* otherwise gove up and complain. */
else pd_defaultanything(x, s_list, argc, argv);
--
1.7.10.4
From 7bfdcc792d20cf173ab58e69260b148144dbd903 Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig zmoel...@iem.at
Date: Thu, 28 Feb 2013 10:09:05 +0100
Subject: [PATCH 2/3] fixing trigger's a outlet
so it re-sends the actual message, rather than converting it to list.
---
src/x_connective.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/x_connective.c b/src/x_connective.c
index abd0931..0ac8cc6 100644
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol *s, int argc, t_atom *argv)
else if (u-u_type == TR_SYMBOL)
outlet_symbol(u-u_outlet,
(argc ? atom_getsymbol(argv) : s_symbol));
+else if (u-u_type == TR_ANYTHING)
+outlet_anything(u-u_outlet, s, argc, argv);
else if (u-u_type == TR_POINTER)
{
if (!argc || argv-a_type != TR_POINTER)
@@ -1017,28 +1019,28 @@ static void trigger_anything(t_trigger *x, t_symbol *s, int argc, t_atom *argv)
static void trigger_bang(t_trigger *x)
{
-trigger_list(x, 0, 0, 0);
+trigger_list(x, s_bang, 0, 0);
}
static void trigger_pointer(t_trigger *x, t_gpointer *gp)
{
t_atom at;
SETPOINTER(at, gp);
-trigger_list(x, 0, 1, at);
+trigger_list(x, s_pointer, 1, at);
}
static void trigger_float(t_trigger *x, t_float f)
{
t_atom at;
SETFLOAT(at, f);
-trigger_list(x, 0, 1, at);
+trigger_list(x, s_float, 1, at);
}
static void trigger_symbol(t_trigger *x, t_symbol *s)
{
t_atom at;
SETSYMBOL(at, s);
-trigger_list(x, 0, 1, at);
+trigger_list(x, s_symbol, 1, at);
}
static void trigger_free(t_trigger *x)
--
1.7.10.4
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
How about further expanding trigger to tolerate a-s by simply taking
the very first argument if the first argument is not type descriptor?
See attached.
e.g.
[foo
|
[t s]
|
[print]
would output foo.
foo bar-outputs foo
bar foo-outputs bar
--- x_connective.c.orig 2013-02-28 13:31:10.011297224 -0500
+++ x_connective.c 2013-02-28 13:33:08.110292915 -0500
@@ -977,6 +977,9 @@
t_triggerout *x_vec;
} t_trigger;
+// forward declaration
+static void trigger_symbol(t_trigger *x, t_symbol *s);
+
static void *trigger_new(t_symbol *s, int argc, t_atom *argv)
{
t_trigger *x = (t_trigger *)pd_new(trigger_class);
@@ -1100,8 +1103,8 @@
else if (u-u_type == TR_STATIC_SYMBOL)
{
outlet_symbol(u-u_outlet, u-u_sym);
- }
-else pd_error(x, trigger: can only convert 'a' to 'b' or 'a');
+ }
+ else trigger_symbol(x, s);
}
}
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 02/28/2013 19:34, Ivica Ico Bukvic wrote: How about further expanding trigger to tolerate a-s by simply taking the very first argument if the first argument is not type descriptor? that's what i was proposing, though i used terminology which i think is more common, e.g. selector instead of type descriptor (foo is really _not_ a type-descriptor, but instead is the CAR that selects (sic!) a method of an object). See attached. to which versionn of Pd should this be applied? doesn't seem to be compatible with Pd master/git. anyhow, yes, i agree that the implementation is fairly simple, i was more concerned with the question what's the *right* thing to do. fgmadrs IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
This is for pd-l2ork, but should be near identical to regular. Pd-l2ork's trigger is also capable of static values like Max's, so this may be the discrepancy in source. On Feb 28, 2013 2:29 PM, IOhannes m zmölnig zmoel...@iem.at wrote: On 02/28/2013 19:34, Ivica Ico Bukvic wrote: How about further expanding trigger to tolerate a-s by simply taking the very first argument if the first argument is not type descriptor? that's what i was proposing, though i used terminology which i think is more common, e.g. selector instead of type descriptor (foo is really _not_ a type-descriptor, but instead is the CAR that selects (sic!) a method of an object). See attached. to which versionn of Pd should this be applied? doesn't seem to be compatible with Pd master/git. anyhow, yes, i agree that the implementation is fairly simple, i was more concerned with the question what's the *right* thing to do. fgmadrs IOhannes ___ 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
Re: [PD] bang vs empty list
BTW, the only regression with this is that [select] object complains it does not understand bang. I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
I wonder if we could as part of the setup call for each external somehow
infer default behaviors for each object e.g.:
something_bang() {
Error(this inlet does not support bang message\n);
}
etc.
Then if that particular object has another addmethod after it referencing
its own genuine bang (or whatever) method, such call would override the
original. I am just not sure if this is possible in the first place and
whether that could produce some misleading messages as well (e.g. I just
fixed cxc/ascseq crash when receiving a bang but this was solved without
having the bang function--this may be fixed by the aforesaid approach as
long as this is somehow possible as part of the setup function and without
having to manually alter every single external's setup function and assuming
that bang function will take precedence over the anything function).
Thoughts?
-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
Jonathan Wilkes
Sent: Monday, February 25, 2013 8:18 PM
To: pd-list
Subject: [PD] bang vs empty list
Seems like for any object that doesn't have a bang method nor list method,
an empty list silently gets discarded.
compare
[bang(
|
[sin]
to
[list(
|
[sin]
or, more likely
[bang(
|
[t a]
|
[sin]
Same for [select] and many others.
Is there a way to fix this?
-Jonathan
___
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
Re: [PD] bang vs empty list
Each class has methods that can be looked up by symbol. At some point
after the class has been created, you could check the class has no bang
method, and if so, add the default bang method. Only built-in classes are
loaded when pd starts up, so if you load a class later, it would not have
the default method.
If you wanted it done at setup time, you would have to modify the function
that calls the setup function (I don't know what it is or how it's
done--please tell me) so you would follow the setup function and add
default methods.
Chuck
On Wed, Feb 27, 2013 at 5:05 PM, Ivica Ico Bukvic i...@vt.edu wrote:
I wonder if we could as part of the setup call for each external somehow
infer default behaviors for each object e.g.:
something_bang() {
Error(this inlet does not support bang message\n);
}
etc.
Then if that particular object has another addmethod after it referencing
its own genuine bang (or whatever) method, such call would override the
original. I am just not sure if this is possible in the first place and
whether that could produce some misleading messages as well (e.g. I just
fixed cxc/ascseq crash when receiving a bang but this was solved without
having the bang function--this may be fixed by the aforesaid approach as
long as this is somehow possible as part of the setup function and without
having to manually alter every single external's setup function and
assuming
that bang function will take precedence over the anything function).
Thoughts?
-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf
Of
Jonathan Wilkes
Sent: Monday, February 25, 2013 8:18 PM
To: pd-list
Subject: [PD] bang vs empty list
Seems like for any object that doesn't have a bang method nor list
method,
an empty list silently gets discarded.
compare
[bang(
|
[sin]
to
[list(
|
[sin]
or, more likely
[bang(
|
[t a]
|
[sin]
Same for [select] and many others.
Is there a way to fix this?
-Jonathan
___
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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang
wow... is your sister married?? (just kiddin'..) alabala On 24 August 2010 09:59, Philip Cunningham pcunningham...@googlemail.comwrote: Visiting my family in Scotland, my sister made me an early birthday present. It's a very tasty, and patchable, cake. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ypatios ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang
seconded... Date: Tue, 24 Aug 2010 10:22:37 +0300 From: ypat...@gmail.com To: pcunningham...@googlemail.com CC: pd-list@iem.at Subject: Re: [PD] Bang wow... is your sister married?? (just kiddin'..) alabala On 24 August 2010 09:59, Philip Cunningham pcunningham...@googlemail.com wrote: Visiting my family in Scotland, my sister made me an early birthday present. It's a very tasty, and patchable, cake. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ypatios ___ 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
Re: [PD] Bang
genious. On Tue, Aug 24, 2010 at 10:24 AM, Andrew Faraday jbtur...@hotmail.comwrote: seconded... -- Date: Tue, 24 Aug 2010 10:22:37 +0300 From: ypat...@gmail.com To: pcunningham...@googlemail.com CC: pd-list@iem.at Subject: Re: [PD] Bang wow... is your sister married?? (just kiddin'..) alabala On 24 August 2010 09:59, Philip Cunningham pcunningham...@googlemail.comwrote: Visiting my family in Scotland, my sister made me an early birthday present. It's a very tasty, and patchable, cake. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ypatios ___ 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 -- Pedro Lopes (ongoing MSc) contact: pedro.lo...@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang
On Tue, Aug 24, 2010 at 8:59 AM, Philip Cunningham pcunningham.uk@ googlemail.com wrote: Visiting my family in Scotland, my sister made me an early birthday I love your family :) cheers -- when Art become pratical we call it technology. When Technology become useless we call it Art www.estereotips.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang
Awesome! She did a bang-up job! (sorry couldn't resist) .hc On Aug 24, 2010, at 2:59 AM, Philip Cunningham wrote: Visiting my family in Scotland, my sister made me an early birthday present. It's a very tasty, and patchable, cake. photo.JPG___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang
Awesome. This is the second time I've seen one of these. Bring on more Pd cakes! Maybe the next PdCon could have a baking contest instead of all those ever-so-exciting academic papers ;-) D. On 8/24/10 8:59 AM, Philip Cunningham wrote: Visiting my family in Scotland, my sister made me an early birthday present. It's a very tasty, and patchable, cake. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 27: Change instrument roles ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang order entry
Hi João If the first bang is triggered, wait some time and if within this time frame the second is triggered as well, then you know the direction. It's actually mostly about timing and to make sure to clear the state after a certain time, if not both bangs are triggered within the time frame. Check the attached (ugly; done with touchpad) patch. Roman On Tue, 2010-08-17 at 13:45 +0100, João de Brito Rocha Reis Vidigal wrote: Hi again. Here goes another problem! Ok. So I'm working with Arduino firmata here... To expose to problem in a simple way, I have 2 sensors that are detecting a door crossing. The 2 detectors give an order to the door crossing: coming in or going out. Now I just don't know how I can translate that to bang 2 different [bang( depending on if someone's comming in or going out! Can you help me with that!? Thanks #N canvas 424 192 632 528 10; #X obj 81 -7 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 116 -7 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 77 251 symbol; #X msg 217 181 symbol left; #X obj 200 249 symbol; #X msg 94 178 symbol right; #X msg 242 120 symbol empty; #X obj 149 294 select empty; #X obj 234 362 print; #X obj 233 321 t a b; #X msg 347 53 stop; #X obj 415 86 t b b; #X obj 243 92 delay 1000; #X connect 0 0 5 0; #X connect 0 0 2 0; #X connect 0 0 12 0; #X connect 1 0 3 0; #X connect 1 0 4 0; #X connect 1 0 12 0; #X connect 2 0 7 0; #X connect 3 0 2 1; #X connect 4 0 7 0; #X connect 5 0 4 1; #X connect 6 0 2 1; #X connect 6 0 4 1; #X connect 7 1 9 0; #X connect 9 0 8 0; #X connect 9 1 11 0; #X connect 10 0 12 0; #X connect 11 0 10 0; #X connect 11 1 6 0; #X connect 12 0 6 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang order entry
With Firmata, you should either get a 1/0 with a digital input or a range between 0-1 for an analog value. .hc On Aug 17, 2010, at 9:51 AM, João de Brito Rocha Reis Vidigal wrote: As it is coming from the arduino firmata, the only way I know is that the signal inputs a bang. So I'll have 2 bangs being hit with a delay between them. this delay depends on the speed of the body crossing the sensors and its size! calling them bang1 and bang2, if the order is bang1 then bang2 = coming in, if it is bang2 then bang1 it means coming out. the thing is I think I have to pair the hits to set an order and I just don't know how to pair them and read it to then bang an in or an out. On 17 Aug 2010, at 14:29, Andrew Faraday wrote: what form is this coming into pd in? If it's a list (such as (door_crossing in) or (door_crossing out)) then you could parse it down with routes e.g. [route door_crossing] (removes the first item in the list, if it's door_crossing) | [sel in out] (the first two inlets will be a bang if it's in or out respectively) Not sure how else you might be getting the data into pd From: jbvidi...@gmail.com Date: Tue, 17 Aug 2010 13:45:53 +0100 To: pd-list@iem.at Subject: [PD] Bang order entry Hi again. Here goes another problem! Ok. So I'm working with Arduino firmata here... To expose to problem in a simple way, I have 2 sensors that are detecting a door crossing. The 2 detectors give an order to the door crossing: coming in or going out. Now I just don't know how I can translate that to bang 2 different [bang( depending on if someone's comming in or going out! Can you help me with that!? Thanks Joao Vidigal ___ 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 Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bang order entry
what form is this coming into pd in? If it's a list (such as (door_crossing in) or (door_crossing out)) then you could parse it down with routes e.g. [route door_crossing] (removes the first item in the list, if it's door_crossing) | [sel in out] (the first two inlets will be a bang if it's in or out respectively) Not sure how else you might be getting the data into pd From: jbvidi...@gmail.com Date: Tue, 17 Aug 2010 13:45:53 +0100 To: pd-list@iem.at Subject: [PD] Bang order entry Hi again. Here goes another problem! Ok. So I'm working with Arduino firmata here... To expose to problem in a simple way, I have 2 sensors that are detecting a door crossing. The 2 detectors give an order to the door crossing: coming in or going out. Now I just don't know how I can translate that to bang 2 different [bang( depending on if someone's comming in or going out! Can you help me with that!? Thanks Joao Vidigal ___ 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
Re: [PD] Bang order entry
As it is coming from the arduino firmata, the only way I know is that the signal inputs a bang. So I'll have 2 bangs being hit with a delay between them. this delay depends on the speed of the body crossing the sensors and its size! calling them bang1 and bang2, if the order is bang1 then bang2 = coming in, if it is bang2 then bang1 it means coming out. the thing is I think I have to pair the hits to set an order and I just don't know how to pair them and read it to then bang an in or an out. On 17 Aug 2010, at 14:29, Andrew Faraday wrote: what form is this coming into pd in? If it's a list (such as (door_crossing in) or (door_crossing out)) then you could parse it down with routes e.g. [route door_crossing] (removes the first item in the list, if it's door_crossing) | [sel in out] (the first two inlets will be a bang if it's in or out respectively) Not sure how else you might be getting the data into pd From: jbvidi...@gmail.com Date: Tue, 17 Aug 2010 13:45:53 +0100 To: pd-list@iem.at Subject: [PD] Bang order entry Hi again. Here goes another problem! Ok. So I'm working with Arduino firmata here... To expose to problem in a simple way, I have 2 sensors that are detecting a door crossing. The 2 detectors give an order to the door crossing: coming in or going out. Now I just don't know how I can translate that to bang 2 different [bang( depending on if someone's comming in or going out! Can you help me with that!? Thanks Joao Vidigal ___ 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
Re: [PD] bang~ event resolution
Hallo, brandon zeeb hat gesagt: // brandon zeeb wrote: For example: 1. If I am attempting to send a message every 8msec (5.51 dsp blocks), will the event actually be sent, rendered, and perceived to occur every 8msec or will it be rounded up to the next block ( #6 ) at 8.7msec? If you send the message from a clock-object like [metro] it will be sent every 8 msec. Rendered and perceived are ambigous terms here that don't have much value without additional info on what exactly you mean by them (best do a patch). 2. If an event is scheduled to occur every 1.50msec, will it be scheduled in time every 1.50msec or every 2.90msec? It will be scheduled every 1.5 msec. Or rather, it will be scheduled whenever Pd thinks it has time to schedule it, but you can depend on it to happen every 1.5 msec of Pd's internal scheduler time, not at some other time. Pd has an internal clock, which is what drives [metro], [delay], [pipe], [timer] and some other objects. This clock time is as accurate as the resolution of numbers in Pd is (32 bit) and it is not quantized to any blocks. However the difficulties start as soon as you convert from messages to audio signals (and back). Most dsp objects in Pd operate on block boundaries, so they are quantized. For example if you try to build a fake phasor~ from a [line~] object and a fast [metro], the frequency will jitter around the block size. Often this doesn't matter (because you'd use a phasor~ anyway), but if it should matter, you have to use one of the special audio objects that correctly interpret clock-messages without any block quantization. Instead of [line~] you just use [vline~] and your fake phasor~ will be perfectly in tune. You don't need to do anything special when just dealing with messages without conversions to dsp. Note that events coming from the GUI (mouse clicks) are quantized to be read every 64 samples. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang~ event resolution
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: If your message rate is faster than the sample block rate you get multiple messages arriving at the same time. But still each of these messages knows its own distinct scheduler time and can tell that time to a signal object that asks for it, like [vline~] does, which then can delay each of the messages accordingly. In the end, even the messages that arrive in the same block may trigger signal actions at different times. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang~ event resolution
i'm still at a loss to explain the effects observed in the attached patch: blocksizetester2.pd Description: application/extension-pd ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang~ event resolution
brandon zeeb wrote: Hello, With regards to the block limit thread and the following previous discussion [1], I have a question regarding event timing resolution in Puredata. In the previous email thread, it was noted: What is also interesting, is that i get the double value of 2.9 msec for blocksizes above 64, for example 65 and above. There are no adc~ or dac~ objects or any subpatches in this setup. Does this mean that the resolution of a bang is in _multiples_ of 1.45msec? For example: 1. If I am attempting to send a message every 8msec (5.51 dsp blocks), will the event actually be sent, rendered, and perceived to occur every 8msec or will it be rounded up to the next block ( #6 ) at 8.7msec? 2. If an event is scheduled to occur every 1.50msec, will it be scheduled in time every 1.50msec or every 2.90msec? I've read the pertinent section of Miller's Theory and Technique of Electronic Music, but I guess this is one small bit I'm still hung up on. It averages out to the interval you specify (as long as the interval is longer than an audio block), but time is quantized to the duration of an audio block, because messages are sent at the end of the audio block during which they logically occur. So in case 1 you would get a sequence of 5 and 6 block intervals that averages out to 5.51. If your message rate is faster than the sample block rate you get multiple messages arriving at the same time. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang~ =64 samples
You can do it combining bang~ with sub-64-sample message delays. cheers M On Sat, Mar 15, 2008 at 10:05:46PM -0400, marius schebella wrote: hi, is there an alternative for bang~ that will work with blocksizes smaller than 64 samples? or is there a chance to fix bang~? marius. ___ 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
Re: [PD] bang~ =64 samples
hi miller, not exaclty sure what sub-64-sample message delays means? block~ 64 64? or 64 delays each 0.0226757369615 ms. will test this. marius. Miller Puckette wrote: You can do it combining bang~ with sub-64-sample message delays. cheers M On Sat, Mar 15, 2008 at 10:05:46PM -0400, marius schebella wrote: hi, is there an alternative for bang~ that will work with blocksizes smaller than 64 samples? or is there a chance to fix bang~? marius. ___ 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
Re: [PD] bang~ =64 samples
Bang~ goes off at 64-sample intervals (1.45 msec) - but for instance a 0.725 msec delay would sync a message to 32 sample into a 64 sample buffer. Of course you might need objects that can deal with messages on such a fine time grain. Tne only one I know of is vline~ (which is the one I use for this kind of thing.) cheers M On Sat, Mar 15, 2008 at 10:45:05PM -0400, marius schebella wrote: hi miller, not exaclty sure what sub-64-sample message delays means? block~ 64 64? or 64 delays each 0.0226757369615 ms. will test this. marius. Miller Puckette wrote: You can do it combining bang~ with sub-64-sample message delays. cheers M On Sat, Mar 15, 2008 at 10:05:46PM -0400, marius schebella wrote: hi, is there an alternative for bang~ that will work with blocksizes smaller than 64 samples? or is there a chance to fix bang~? marius. ___ 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang~ =64 samples
...uhmm, negative. I created now a subpatch with the 64 delays, and get good timer measurements of 0.0226757 ms. but when I hook it up to sig~ the signal is still only updated every 64 samples. same btw with vline~. I was trying [$1 1.45( into line~, but that only a bad fake, and the ring modulator effect is still there... am I missing something? marius. Miller Puckette wrote: Bang~ goes off at 64-sample intervals (1.45 msec) - but for instance a 0.725 msec delay would sync a message to 32 sample into a 64 sample buffer. Of course you might need objects that can deal with messages on such a fine time grain. Tne only one I know of is vline~ (which is the one I use for this kind of thing.) cheers M On Sat, Mar 15, 2008 at 10:45:05PM -0400, marius schebella wrote: hi miller, not exaclty sure what sub-64-sample message delays means? block~ 64 64? or 64 delays each 0.0226757369615 ms. will test this. marius. Miller Puckette wrote: You can do it combining bang~ with sub-64-sample message delays. cheers M On Sat, Mar 15, 2008 at 10:05:46PM -0400, marius schebella wrote: hi, is there an alternative for bang~ that will work with blocksizes smaller than 64 samples? or is there a chance to fix bang~? marius. ___ 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang~ =64 samples
using tables now, coming closer! m. marius schebella wrote: ...uhmm, negative. I created now a subpatch with the 64 delays, and get good timer measurements of 0.0226757 ms. but when I hook it up to sig~ the signal is still only updated every 64 samples. same btw with vline~. I was trying [$1 1.45( into line~, but that only a bad fake, and the ring modulator effect is still there... am I missing something? marius. Miller Puckette wrote: Bang~ goes off at 64-sample intervals (1.45 msec) - but for instance a 0.725 msec delay would sync a message to 32 sample into a 64 sample buffer. Of course you might need objects that can deal with messages on such a fine time grain. Tne only one I know of is vline~ (which is the one I use for this kind of thing.) cheers M On Sat, Mar 15, 2008 at 10:45:05PM -0400, marius schebella wrote: hi miller, not exaclty sure what sub-64-sample message delays means? block~ 64 64? or 64 delays each 0.0226757369615 ms. will test this. marius. Miller Puckette wrote: You can do it combining bang~ with sub-64-sample message delays. cheers M On Sat, Mar 15, 2008 at 10:05:46PM -0400, marius schebella wrote: hi, is there an alternative for bang~ that will work with blocksizes smaller than 64 samples? or is there a chance to fix bang~? marius. ___ 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [bang]--clickable but bypass when indirect
robbert van hulzen wrote: in other words, i'm looking for a way to have incoming info stop at the [bang] (as it'll come out directly), but info generated at the [bang] move on. Well, you can't stop info at a bang, but you can stop the output with [spigot], as in the ascii below: in | [t b a b] | | | | gui | | | | 1 / 0 \ /| X | / \| / \ | |\ | | \ | [spigot 1] | out (the creation argument to spigot is the initial gate state, at least in recent Pd versions) Thanks, Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [bang]--clickable but bypass when indirect
i don't think this is possible. a workaround would be to change the color of the bang for 250 ms so the whole thing is black if a hit gets detected. [color 22 0 0( | [t a b] | | | [delay 250] | | | [color 0 22 0( | / | / [bng] Am 31.10.2007 um 15:10 schrieb robbert van hulzen: hi there dear list people, a little while ago, andy mentioned a construction for bypassing gui objects (numberboxes, in that case) while at the same time using the info you may put in them with the mouse. i can't find the post anymore, but i think that's exactly what i need now. i'm making an abstraction for my midi controller (drum pad thingy), that should both show what comes in--ie bang the nicely coloured [bang]s when the pad with the corresponding notenumber is hit--and function as an onscreen replacement: when a [bang] is clicked, it should send it out. in other words, i'm looking for a way to have incoming info stop at the [bang] (as it'll come out directly), but info generated at the [bang] move on. hope i make myself clear... anyone have any idea? thanks a lot! cheers, robbert ___ 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
Re: [PD] bang on ~ 0 crossing?
hello, with externals\ekext\zeroxpos~ and the edge~ object you can get bangs on audio zero crossing. pc Michal Seta a écrit : Hi, I don't have access to my pd machine right now but IIRC there is an extern called [zerocross~] (or something like that) available somewehere... could be part of nSlam (http://www.tot.sat.qc.ca/logiciels_nslam.html). ./MiS Hi all, I need something that can tell me when a phasor~ with a variable playback rate hits 0. In other words, I need something that spits out a bang at the next control phase if it sees a 0 in the audio data passing through it. Any contenders? -- Damian Stewart ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang on ~ 0 crossing?
Hi, I think the [threshold~] object should do exactly what you ask, would be more accurate than the [snapshot~]+[~]+[metro] approach and perhaps even cheaper, and it does not require any external either. But I may be missing something... bye m. attached post does what you want, to an accuracy of 1 ms. but another approach is to do away with the phasor and use fast metro attached to vline~..hang on, i'll attach that too. Hi, I don't have access to my pd machine right now but IIRC there is an extern called [zerocross~] (or something like that) available somewehere... could be part of nSlam (http://www.tot.sat.qc.ca/logiciels_nslam.html). Hi all, I need something that can tell me when a phasor~ with a variable playback rate hits 0. In other words, I need something that spits out a bang at the next control phase if it sees a 0 in the audio data passing through it. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vendi l'auto? La moto? La barca? Il Camper? Affitti un appartamento? * Per concludere i tuoi affari pubblica gli annunci con AdBoom.it! Facile. Veloce. Gratuito Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6419d=28-4 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang on ~ 0 crossing?
Hi, I don't have access to my pd machine right now but IIRC there is an extern called [zerocross~] (or something like that) available somewehere... could be part of nSlam (http://www.tot.sat.qc.ca/logiciels_nslam.html). ./MiS Hi all, I need something that can tell me when a phasor~ with a variable playback rate hits 0. In other words, I need something that spits out a bang at the next control phase if it sees a 0 in the audio data passing through it. Any contenders? -- Damian Stewart f r e y live music with machines http://www.frey.co.nz http://www.myspace.com/freyed ___ 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
Re: [PD] bang on ~ 0 crossing?
attached post does what you want, to an accuracy of 1 ms. but another approach is to do away with the phasor and use fast metro attached to vline~..hang on, i'll attach that too. phasor-retrig.pd Description: Binary data v-phasor~.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
On 02/12/2006, at 10.30, Frank Barknecht wrote: However with the metro it will be much easier to know when the fake phasor reaches 1 or 0. That's what bang'ed my question. Thanks for explaining. Bets, Steffen ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
Hallo, padawan12 hat gesagt: // padawan12 wrote: I guess just because they drift off. Or at least you cant be sure of keeping them together. Sometimes you want a whole bunch of things to all happen synchronously, to all happen in the same phase every time. An example is the paf~ algorithm, and here's little drum machine example attached. So you usually have just one phasor that is your master timebase and derive everything from that. [metro] with [vline~] won't drift off, as I wrote in the previous mail, it is equivalent to [phasor~] and can almost be used as a drop-in replacement. ([metro] has an artificial lower period boundary of 1ms, but you can use a [delay] based metro-clone, if that is a problem.) The disadvantage of [metro~]/[vline~] is that you cannot change the frequency in a smooth way, because, as you write, [metro] generates discrete events. The advantage of [metro]/[vline~] is, that it is possible to reset the phase without getting errors from the 64-samples quantization that [phasor~]'s right inlet has: The phase of a [phasor~] can only be reset every 64 samples, that is with usual sample rates at a quantization of about 1.5 msec. This definitely can be a problem if you want a tight synching of sequences. I made a variation of your drum machine to illustrate this effect. One drumset here is driven by a [vhasor~] abstraction which almost is a [phasor~] clone, built with metro and vline~. If you let both patterns run together and switch on the phase-reset-metro you will get flanging effects which are the fault of the inaccuracy of the phase-inlet of the [phasor~] object. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ #N canvas 377 467 551 486 10; #X obj 108 18 loadbang; #X obj 54 130 f \$1; #X obj 54 17 inlet; #X obj 54 385 vline~; #X obj 54 257 t b b; #X obj 157 405 outlet; #X obj 181 17 inlet; #X text 231 17 reset phase; #X obj 53 408 outlet~; #X obj 54 100 abs; #X obj 126 176 expr 1000/$f1; #X obj 54 150 t a a; #X obj 54 238 metro; #X obj 126 202 t a a; #X msg 181 58 bang; #X obj 286 126 0; #X obj 286 156 select 1 0; #X obj 54 285 f; #X obj 54 318 list append 0 1; #X msg 54 355 \$2 \, \$3 \$1; #X msg 286 180 1 0; #X msg 318 181 0 1; #X obj 54 56 t a a; #X text 370 156 up-down/down-up; #X connect 0 0 1 0; #X connect 1 0 11 0; #X connect 2 0 22 0; #X connect 3 0 8 0; #X connect 4 0 17 0; #X connect 4 1 5 0; #X connect 6 0 14 0; #X connect 9 0 1 0; #X connect 10 0 13 0; #X connect 11 0 12 0; #X connect 11 1 10 0; #X connect 12 0 4 0; #X connect 13 0 12 1; #X connect 13 1 17 1; #X connect 14 0 12 0; #X connect 15 0 16 0; #X connect 16 0 20 0; #X connect 16 1 21 0; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 19 0 3 0; #X connect 20 0 18 1; #X connect 21 0 18 1; #X connect 22 0 9 0; #X connect 22 1 15 0; #N canvas 224 127 673 486 10; #N canvas 267 211 916 531 phasesyncronousdrums 0; #X obj 283 98 / 60; #X obj 282 138 * -1; #N canvas 0 0 450 300 psbd 0; #X obj 167 30 wrap~; #X obj 182 230 *~; #X obj 168 55 *~; #X obj 183 146 osc~; #X obj 167 82 *~; #X obj 198 208 lop~ 100; #X obj 168 5 inlet~; #X obj 181 166 clip~ -0.9 0.9; #X obj 184 124 +~ 44; #X obj 184 104 *~ 44; #X obj 182 189 *~ 2; #X obj 177 260 outlet~; #X connect 0 0 2 0; #X connect 0 0 2 1; #X connect 1 0 11 0; #X connect 2 0 4 0; #X connect 2 0 4 1; #X connect 2 0 9 0; #X connect 3 0 7 0; #X connect 4 0 5 0; #X connect 5 0 1 1; #X connect 6 0 0 0; #X connect 7 0 10 0; #X connect 8 0 3 0; #X connect 9 0 8 0; #X connect 10 0 1 0; #X restore 203 335 pd psbd; #N canvas 0 0 501 413 pssd 0; #X obj 189 1 wrap~; #X obj 352 121 noise~; #X obj 198 343 *~; #X obj 188 26 *~; #X obj 187 53 *~; #X obj 197 280 vcf~ 6000 3; #X obj 269 238 loadbang; #X obj 188 -41 inlet~; #X obj 289 154 +~; #X obj 288 101 +~ 100; #X obj 288 123 osc~; #X obj 288 78 *~ 100; #X obj 288 177 clip~ -0.3 0.3; #X obj 232 205 *~ 8000; #X obj 200 84 *~; #X obj 232 225 +~ 700; #X msg 269 259 0.4; #X obj 198 303 *~ 1; #X obj 194 372 outlet~; #X connect 0 0 3 0; #X connect 0 0 3 1; #X connect 0 0 11 0; #X connect 1 0 8 1; #X connect 2 0 18 0; #X connect 3 0 4 0; #X connect 3 0 4 1; #X connect 4 0 2 1; #X connect 4 0 14 0; #X connect 4 0 14 1; #X connect 5 0 17 0; #X connect 6 0 16 0; #X connect 7 0 0 0; #X connect 8 0 12 0; #X connect 9 0 10 0; #X connect 10 0 8 0; #X connect 11 0 9 0; #X connect 12 0 5 0; #X connect 13 0 15 0; #X connect 14 0 13 0; #X connect 15 0 5 1; #X connect 16 0 5 2; #X connect 17 0 2 0; #X restore 298 334 pd pssd; #X obj 283 184 *~ 8; #X obj 25 242 clip~ 0 1; #X obj 101 242 clip~ 1 2; #X obj 179 242 clip~ 2 3; #X obj 257 242 clip~ 3 4; #X obj 341 241 clip~ 4 5; #X obj 417 241 clip~ 5 6; #X obj 494 241 clip~ 6 7; #X obj 570 241 clip~ 7 8; #X obj 282 118 / 4; #N canvas 0 0 450 300 pshh 0; #X obj 199 386 wrap~; #X obj 216 507 noise~; #X obj 214 595 *~; #X obj 198 411 *~; #X obj 213 555 *~ 0.3; #X obj 213 532 vcf~ 6000 3; #X obj 285 490 loadbang; #X obj 198 344 inlet~; #X msg 285 511 6; #X obj 214 460
Re: [PD] bang when phasor~ reaches 1
well i ended up doing a metro and vline~ job. this patch is still unfinished, but it's working enough that i could take a rest from patching and have a mess round with it today. i posted the workign draft on the forum: http://puredata.hurleur.com/viewtopic.php?pid=2494#p2494 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
Hallo, padawan12 hat gesagt: // padawan12 wrote: Is it just me though or is [expr ] really slow? I try to avoid it because almost every patch that uses [expr] on my machine runs about 50% slower than the equivilent arithmetic using atomic ops. Attached is a simple benchmark patch, which benchmarks taking the inverse in e/b-calc. Here builtin and expr are almost the same speed, builtin is only slightly faster. However as soon as you collect longer chains of calculations into one expr-object it beats the crap out of atomic ops, as the e/b-complex benchmark shows. If it doesn't pulp the atomic ops in your Pd installation, then there's something very wrong. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ #N canvas 326 164 736 482 10; #N canvas 0 0 450 300 bm 0; #X restore 218 423 pd bm; #X obj 100 381 s pd-bm; #X msg 220 349 clear; #X obj 100 269 until; #X obj 100 200 t b b; #X floatatom 210 154 5 0 0 2 howmany - -; #X obj 100 146 bng 32 250 50 0 empty empty test-x 0 -6 0 8 -24198 -1 -1; #X obj 100 294 f 10; #X obj 133 293 + 20; #X msg 144 269 10; #X obj 494 248 until; #X obj 435 150 bng 24 250 50 0 empty empty run_test 0 -6 0 8 -225271 -1 -1; #X floatatom 435 297 8 0 0 1 milliseconds - -; #X obj 435 182 t b b b; #X obj 435 243 t b b; #X obj 435 274 cputime; #X obj 494 274 s BANG; #X floatatom 531 206 5 0 0 0 - - -; #X obj 100 327 pack 0 s; #X obj 211 268 list; #X symbolatom 211 291 10 0 0 0 - - -; #X msg 100 348 obj 10 \$1 \$2; #X text 211 185 Which?; #X text 25 22 first select \, which and how many objects to create \, then create them in [pd bm] by pressing the big green bng. After that \, send the test data by the run_test-bng and watch the time it takes.; #X msg 212 211 b-calc; #X msg 211 231 e-calc; #X obj 494 226 f 1; #X obj 100 244 f 100; #X msg 284 213 e-complex; #X msg 285 233 b-complex; #X connect 2 0 1 0; #X connect 3 0 7 0; #X connect 4 0 27 0; #X connect 4 1 2 0; #X connect 4 1 9 0; #X connect 5 0 27 1; #X connect 6 0 4 0; #X connect 7 0 8 0; #X connect 7 0 18 0; #X connect 8 0 7 1; #X connect 9 0 7 1; #X connect 10 0 16 0; #X connect 11 0 13 0; #X connect 13 0 14 0; #X connect 13 1 26 0; #X connect 13 2 14 0; #X connect 14 0 15 0; #X connect 14 1 15 1; #X connect 15 0 12 0; #X connect 17 0 26 1; #X connect 18 0 21 0; #X connect 19 0 20 0; #X connect 20 0 18 1; #X connect 21 0 1 0; #X connect 24 0 19 0; #X connect 25 0 19 0; #X connect 26 0 10 0; #X connect 27 0 3 0; #X connect 28 0 19 0; #X connect 29 0 19 0; #N canvas 231 180 450 300 10; #X obj 97 54 r BANG; #X obj 97 135 f; #X obj 97 103 expr 1000/$f1; #X obj 97 80 f 12; #X connect 0 0 3 0; #X connect 2 0 1 0; #X connect 3 0 2 0; #N canvas 384 267 450 300 10; #X obj 87 90 r BANG; #X obj 87 127 expr 12*(1+2+3+4+5+6+7+8+9+10); #X obj 87 158 f; #X connect 0 0 1 0; #X connect 1 0 2 0; #N canvas 631 289 450 300 10; #X obj 143 191 f; #X obj 143 44 r BANG; #X obj 143 132 f 1000; #X obj 143 68 f 12; #X obj 143 97 t b a; #X obj 143 158 /; #X connect 1 0 3 0; #X connect 2 0 5 0; #X connect 3 0 4 0; #X connect 4 0 2 0; #X connect 4 1 5 1; #X connect 5 0 0 0; #N canvas 0 0 450 300 10; #X obj 224 224 * 12; #X obj 144 88 f 1; #X obj 144 111 + 2; #X obj 154 121 + 3; #X obj 164 131 + 4; #X obj 174 141 + 5; #X obj 184 151 + 6; #X obj 196 160 + 7; #X obj 204 171 + 8; #X obj 215 181 + 9; #X obj 224 201 + 10; #X obj 144 58 r BANG; #X obj 222 244 f; #X connect 0 0 12 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 10 0; #X connect 10 0 0 0; #X connect 11 0 1 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
Hallo, padawan12 hat gesagt: // padawan12 wrote: Cool! We've discovered something very wrong. Maybe not, read on. Here I get number bcalcecalcbcplxecplx 4 70 80 110 290 8 140 160 210 560 16 260 330 430 1130 32 560 660 1070 2300 64 1220 1490 3250 4720 Hm, you're right, with such small numbers I actually also get better results for the builtins. I was only testing bigger numbers at first. With a growing number of test objects I get a huge lead for [expr]. Here are some of my statistics (on a much faster machine): num bcplx ecplx --- 128 720 1170 2562780 2320 512 10430 5800 Now I'm wondering, if something became very wrong with [expr] ... Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang when phasor~ reaches 1
[phasor] [bang~] | / [snapshot~] | [ 0.99] | [sel 1] ? Jamie On Fri, 2006-12-01 at 22:35 +0900, hard off wrote: i want a phasor~ to send a bang when the signal reaches 1. any ideas? ___ 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
Re: [PD] bang when phasor~ reaches 1
The solution Marius offered is probably the most reliable. I've used Jamies [snapshot~] based solution in many cases it works fine, but sometimes misses a beat. It's because the blocksize (nominally 64) on which [snapshot~] operates may not contain the zero you're looking for. The thing you want is [delta~], but you can make your own arrangement with a [z~] and a [-~]. Basically look for any large dx/dt, not just negative, remember that a phasor can also be negative in slope, ie [phasor~ -100]. See also that as the frequency increases toward a high value eventually the solution will fail (each rising slope will be sufficiently fast to trigger the delta comparator. Theres probably a more elgant solution, I heard Martin Brinkman is a good chap to ask as he tends to work in the signal domain and derive his control messages. Any other ideas for a *reliable* detection of phase reset? On Fri, 1 Dec 2006 22:35:24 +0900 hard off [EMAIL PROTECTED] wrote: i want a phasor~ to send a bang when the signal reaches 1. any ideas? ___ 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
Re: [PD] bang when phasor~ reaches 1
On 01/12/2006, at 14.35, hard off wrote: i want a phasor~ to send a bang when the signal reaches 1. I the risk of showing off serious lack of knowledge: When is this approach different from using a metro object with the same frequency as the phasor~? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
