I am thinking it would be quite handy to be able to get the current version of Pd from in a patch. This would probably take the form of a [version] object that returns the version when banged. The output could look like this:
major minor bugfix i.e [0 39 2(
Then you could specify a minimum Pd version for a patch, and have it test and give a warning if that minimum is not met. Should be pretty easy to implement, but there is one thing needed that's not there in m_pd.h:
#define PD_BUGFIX_VERSION 2
as in: #define PD_MAJOR_VERSION 0 #define PD_MINOR_VERSION 39 #define PD_BUGFIX_VERSION 2
Also, the pd_version string in s_main.c should probably also use the above macros so the version is set in one place.
Comments, ideas, suggestions, objections?
.hc
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
Zitiere Hans-Christoph Steiner hans@eds.org:
I am thinking it would be quite handy to be able to get the current version of Pd from in a patch. This would probably take the form of a
[version] object that returns the version when banged. The output could look like this:
Comments, ideas, suggestions, objections?
i would love that! especially with things like [atan2] which make patches build with older versions of pd totally useless...
mfg.asdr IOhannes
PS: totally unrelated (i just don't want to write a separate email for this minor correction, so i hijack this one) but in the other thread (regarding sinf,...) my "Yes!" is an answer for "objections?" rather than "i'll make a patch"
I am thinking it would be quite handy to be able to get the current version of Pd from in a patch. This would probably take the form of a
[version] object that returns the version when banged. The output could look like this:
i guess, you can write an external that does a gensym(pd_version) ...
i would love that! especially with things like [atan2] which make patches build with older versions of pd totally useless...
but maybe this is nothing that really requires an external ... maybe it's something, to be sent to the receive symbol 'pd', when it's banged ... (speaking in terms of programming languages, querying the state of the interpreter rather than a function call)
t
On Jan 28, 2006, at 4:40 AM, Tim Blechmann wrote:
I am thinking it would be quite handy to be able to get the current version of Pd from in a patch. This would probably take the form of a
[version] object that returns the version when banged. The output could look like this:
i guess, you can write an external that does a gensym(pd_version) ...
pd_version is the string, I think we would want separate floats for major, minor, and bugfix.
i would love that! especially with things like [atan2] which make patches build with older versions of pd totally useless...
but maybe this is nothing that really requires an external ... maybe it's something, to be sent to the receive symbol 'pd', when it's banged ... (speaking in terms of programming languages, querying the state of the interpreter rather than a function call)
That sounds appropriate, but where do you get the return value? I thought about it a bit, and I couldn't think of an established method to get return values from sending messages to pd.
.hc
t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
You can play a shoestring if you're sincere John Coltrane
________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
That sounds appropriate, but where do you get the return value? I thought about it a bit, and I couldn't think of an established method to get return values from sending messages to pd.
what about: |;pd getversion(
|r pd| | |route version| |
tim
On Jan 28, 2006, at 10:45 AM, Tim Blechmann wrote:
That sounds appropriate, but where do you get the return value? I thought about it a bit, and I couldn't think of an established method to get return values from sending messages to pd.
what about: |;pd getversion(
|r pd| | |route version| |
Yes, that sounds good. Is there currently anything that sends data to [r pd]?
I think that a standard receive symbol would be a nice standard interface to a lot of things, like querying the state of audio/midi hardware, querying the meta information of a patch, setting/getting canvas name, etc.
But if we are to use [r pd], then it would probably make sense to have a standardized interface for getting info. Maybe something like this:
[; pd get version( [; pd get canvasname( [; pd get path( [; pd get namespace(
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
Yes, that sounds good. Is there currently anything that sends data to [r pd]?
i once added an api for controlling the audio settings by sending commands to 'pd' ...
I think that a standard receive symbol would be a nice standard interface to a lot of things, like querying the state of audio/midi hardware, querying the meta information of a patch, setting/getting canvas name, etc.
well, it would be possible to query the state of all global (interpreter) settings like audio settings, but i don't see, why it should be used to query information from patches ... one would need a |thiscanvas| or |thispatcher| object for that ... (or if it's for dynamic patching just use dyn~)
tim
On Jan 28, 2006, at 12:20 PM, Tim Blechmann wrote:
Yes, that sounds good. Is there currently anything that sends data to [r pd]?
i once added an api for controlling the audio settings by sending commands to 'pd' ...
yes, I saw that patch, I would be good to have that included. I think Miller had an issue that he posted on the patch tracker. I think it should be possible to get that issue resolved and that patch included in Pd core.
I think that a standard receive symbol would be a nice standard interface to a lot of things, like querying the state of audio/midi hardware, querying the meta information of a patch, setting/getting canvas name, etc.
well, it would be possible to query the state of all global (interpreter) settings like audio settings, but i don't see, why it should be used to query information from patches ... one would need a |thiscanvas| or |thispatcher| object for that ... (or if it's for dynamic patching just use dyn~)
I am also talking about not-yet implemented features, like the namespace for the patch which was recently discussed. I think that would work well with this kind of interface. It could use the [namecanvas] name and the patch receive symbol, i.e.:
[; pd-mypatch.pd editmode 1(
[r pd-mypatch.pd] | [route editmode] | [X] <- (this would be a [tgl])
.hc
tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
Life is really simple, but we insist on making it complicated. Confucius
________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies." - Amy Smith
i once added an api for controlling the audio settings by sending commands to 'pd' ...
yes, I saw that patch, I would be good to have that included. I think Miller had an issue that he posted on the patch tracker. I think it should be possible to get that issue resolved and that patch included in Pd core.
miller didn't like the patch ... didn't think it's necessary ... since i have another opinion about it, it's in devel ... and as you know, i gave up submitting patches a long time ago ...
tim
On Jan 28, 2006, at 6:00 PM, Tim Blechmann wrote:
i once added an api for controlling the audio settings by sending commands to 'pd' ...
yes, I saw that patch, I would be good to have that included. I think Miller had an issue that he posted on the patch tracker. I think it should be possible to get that issue resolved and that patch included in Pd core.
miller didn't like the patch ... didn't think it's necessary ... since i have another opinion about it, it's in devel ... and as you know, i gave up submitting patches a long time ago ...
I encourage you to try again. Miller has recently accepted a bunch of patches, including some big changes like Thomas' new loader stuff. But of course we can't expect him to automatically accept every patch that we post.
.hc ________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom