hope this isn't too obvious couldnt find any documentation on the following messages to pd any pointers?
filename [symbol] [symbol] key [gimme] meters [float] foo [gimme] finderror ping
Hi Frank, Here's the ones I know:
key: send a keystroke message (see manuals/pd-msg/3.0.events.pd)
meters: turn on peak meters. args: 1=on/0=off (warning: doesn't update the meters checkbox!)
finderror: same as "Find" menu -> "Find last error"
-Jonathan
--- On Wed, 2/3/10, frank potaxpotax@gmail.com wrote:
From: frank potaxpotax@gmail.com Subject: [PD] messages to pd To: "pd-list" pd-list@iem.at Date: Wednesday, February 3, 2010, 3:05 AM hope this isn't too obviouscouldnt find any documentation on the following messages to pdany pointers? filename [symbol] [symbol] key [gimme]meters [float]foo [gimme]finderrorping
-----Inline Attachment Follows-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Feb 2, 2010, at 9:05 PM, frank wrote:
hope this isn't too obvious couldnt find any documentation on the following messages to pd any pointers?
Off hand:
filename [symbol] [symbol]
hans@palatschinken.at.or.at:src > grep -A1 '"filename"' *.*
m_glob.c: class_addmethod(glob_pdobject,
(t_method)glob_setfilename, gensym("filename"),
m_glob.c- A_SYMBOL, A_SYMBOL, 0);
key [gimme]
receive key press values
meters [float]
turn on/off the meters in the Pd window
foo [gimme]
m_glob.c: class_addmethod(glob_pdobject, (t_method)glob_foo,
gensym("foo"), A_GIMME, 0);
finderror
Find->Find Error
ping
ping the GUI to make sure things are still running.
.hc
"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
Hello, Taking acoustics~-help.pd as an example: is there any reason for the [sig~] object here? Doesn't the float from the gatom automatically get promoted to a signal?
Thanks, Jonathan
I think it's an historical thing, most audio inlets which might benefit from a signal level message have the [sig~] built in. I understand this might not always have been the case so some more old school PDers use it, and they remain in the help files. I don't know if there's some minor technical benefit to using the [sig~] object, but I've still to find a need for it
Date: Tue, 2 Feb 2010 20:51:45 -0800 From: jancsika@yahoo.com To: pd-list@iem.at Subject: [PD] float to a signal inlet
Hello, Taking acoustics~-help.pd as an example: is there any reason for the [sig~] object here? Doesn't the float from the gatom automatically get promoted to a signal?
Thanks, Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/
On 2010-02-03 08:20, Andrew Faraday wrote:
I think it's an historical thing, most audio inlets which might benefit from a signal level message have the [sig~] built in. I understand this might not always have been the case so some more old school PDers use it, and they remain in the help files. I don't know if there's some minor technical benefit to using the [sig~] object, but I've still to find a need for it
i don't think there is any technical benefit. the benefit is mainly in the non-ambiguity it offers. a message and a signal are 2 fundamentally different things, so an object could well accept both signals and float-messages on a single inlet (e.g [z~] comes to my mind). in order to allow this, you need a converter, which [sig~] is (and [line~] as well; but [sig~] probably _does_ have performance benefits with regard to [line~].
that was back then in the golden age of Pd (right after you could hit "delete" in the [f] box two(!) times without getting a crash)
since the conversion between numbers and floats seems to be an often demanded feature, it was eventually introduced as a built-in (breaking objects like [z~]). sigh.
in order to create a gatom controlled sinewave, you had to do
| [sig~] I [phasor~] I [cos~] I
fgmasdr IOhannes
PS: as we all now, the above patch (and it's modern equivalent [osc~] will produce ugly clicks when used like this; isn't it time to request a built-in [line~]?
Interesting thought, perhaps if the built in [line~] had a very low argument attached, like 3 or 4 milliseconds. Although line is usually a creative decision. Do I want the frequency to change instantly or to gently slide between frequencies over the next minute or so? Perhaps a built in [line~ 60000] wouldn't be such a good idea.
Date: Wed, 3 Feb 2010 10:10:28 +0100 From: zmoelnig@iem.at To: jbturgid@hotmail.com CC: jancsika@yahoo.com; pd-list@iem.at Subject: Re: [PD] float to a signal inlet
On 2010-02-03 08:20, Andrew Faraday wrote:
I think it's an historical thing, most audio inlets which might benefit from a signal level message have the [sig~] built in. I understand this might not always have been the case so some more old school PDers use it, and they remain in the help files. I don't know if there's some minor technical benefit to using the [sig~] object, but I've still to find a need for it
i don't think there is any technical benefit. the benefit is mainly in the non-ambiguity it offers. a message and a signal are 2 fundamentally different things, so an object could well accept both signals and float-messages on a single inlet (e.g [z~] comes to my mind). in order to allow this, you need a converter, which [sig~] is (and [line~] as well; but [sig~] probably _does_ have performance benefits with regard to [line~].
that was back then in the golden age of Pd (right after you could hit "delete" in the [f] box two(!) times without getting a crash)
since the conversion between numbers and floats seems to be an often demanded feature, it was eventually introduced as a built-in (breaking objects like [z~]). sigh.
in order to create a gatom controlled sinewave, you had to do
| [sig~] I [phasor~] I [cos~] I
fgmasdr IOhannes
PS: as we all now, the above patch (and it's modern equivalent [osc~] will produce ugly clicks when used like this; isn't it time to request a built-in [line~]?
Got a cool Hotmail story? Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/
i don't want a built in line~. there are plenty of synths i have where i need to frequency to go to the correct value immediately. not to mention my lfo's.
On Wed, 2010-02-03 at 10:10 +0100, IOhannes m zmoelnig wrote:
PS: as we all now, the above patch (and it's modern equivalent [osc~] will produce ugly clicks when used like this; isn't it time to request a built-in [line~]?
After this assumingly not so serious request consideration, I'll have one, that is certainly meant to be serious:
Isn't it time to request scheduled message-to-signal conversion for the inlets of many tilde-objectclasses? This would allow - for instance:
- changing frequency for [osc~] and [phasor~] _between_ block
boundaries
- setting the phase between block boundaries
- doing whatever you want _within_ block boundaries using messages for
objects like [*~ ], [-~] .....
Roman
-
Andrew Faraday -
frank -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Jonathan Wilkes -
Roman Haefeli