Here is a quick snapshot of a bundle of classes I'm working on to provide a standardized way to get properties from parts of pd that aren't "objectified":
[canvasinfo] get the properties of a canvas [pdinfo] get info about the running Pd instance [classinfo] info on a class (still under construction)
I currently have them below [print] in x_interface.c from 0.43, so you can just drop it in and compile with Pd Vanilla if you want to check it out. (I'll make a patch later.)
The props for [canvasinfo] are from my patch on the tracker that adds a "get" method to canvas. The nice thing about this particular
interface is that there is only one class per domain which makes it much easier IMO to learn and remember the tools you need to inspect data (vs the one class per property approach which I find cumbersome). For example, a bang to canvasinfo or pdinfo will print out a complete sequence of all properties and their values to the Pd window, so one doesn't even have to memorize the methods in order to see the values. Incoming messages are done "pack" style, so that "symbol method" and "method" work the same, and with [canvasinfo] "A_SYMBOL A_FLOAT" messages get distributed among the inlets as lists do.
I only have "dsp" and "version" properties for [pdinfo] so far. I'm curious what else would be useful.
[classinfo] just tells whether the incoming symbol is one that will create an object that is already loaded. I'm not sure what an incoming bang would do here, or what more information would be useful. Actually I think [declare -lib blah] fails silently, so you could use this as a way to "catch" missing objects and specify an alternative.
I stole some code from IOhannes to get canvas args without digging into the innards of g_canvas.c. :)
-Jonathan
On 11/15/2012 01:34 AM, Jonathan Wilkes wrote:
Here is a quick snapshot of a bundle of classes I'm working on to provide a standardized way to get properties from parts of pd that aren't "objectified":
[canvasinfo] get the properties of a canvas [pdinfo] get info about the running Pd instance
sound good, i would probably like to include them into iemguts.
[classinfo] info on a class (still under construction)
[classtest]?
gmdsr IOhannes
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-dev@iem.at Cc: Sent: Thursday, November 15, 2012 7:52 AM Subject: Re: [PD-dev] info classes
On 11/15/2012 01:34 AM, Jonathan Wilkes wrote:
Here is a quick snapshot of a bundle of classes I'm working on to provide a standardized way to get properties from parts of pd that aren't "objectified":
[canvasinfo] get the properties of a canvas [pdinfo] get info about the running Pd instance
sound good, i would probably like to include them into iemguts.
[classinfo] info on a class (still under construction)
[classtest]?
Yep, looks like they do the same thing right now-- check for existence. I'm wondering if there's any other functionality to add that would be useful.
gmdsr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Just made a change so that the "args" method grabs from the parent instead of the root canvas. I initially didn't see a use case for grabbing the args of a [pd] object, but someone posted one awhile back.
Should I go ahead and also add a "selector" method to grab the selector of the parent canvas? This would make it possible to grab the "pd" selector or the name of the abstraction without the extension (e.g., ".pd"). This would be in addition to a "filename" method that grabs the gl_name regardless of whether you're in a [pd] or not. I find that necessary because, after all, we could be inside an abstraction within a max patch and so the patch author can't just append ".pd" to the "selector".
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: "pd-dev@iem.at" pd-dev@iem.at Cc: Sent: Thursday, November 15, 2012 2:34 AM Subject: [PD-dev] info classes
Here is a quick snapshot of a bundle of classes I'm working on to provide a standardized way to get properties from parts of pd that aren't "objectified":
[canvasinfo] get the properties of a canvas [pdinfo] get info about the running Pd instance [classinfo] info on a class (still under construction)
I currently have them below [print] in x_interface.c from 0.43, so you can just drop it in and compile with Pd Vanilla if you want to check it out. (I'll make a patch later.)
The props for [canvasinfo] are from my patch on the tracker that adds a "get" method to canvas. The nice thing about this particular
interface is that there is only one class per domain which makes it much easier IMO to learn and remember the tools you need to inspect data (vs the one class per property approach which I find cumbersome). For example, a bang to canvasinfo or pdinfo will print out a complete sequence of all properties and their values to the Pd window, so one doesn't even have to memorize the methods in order to see the values. Incoming messages are done "pack" style, so that "symbol method" and "method" work the same, and with [canvasinfo] "A_SYMBOL A_FLOAT" messages get distributed among the inlets as lists do.
I only have "dsp" and "version" properties for [pdinfo] so far. I'm curious what else would be useful.
[classinfo] just tells whether the incoming symbol is one that will create an object that is already loaded. I'm not sure what an incoming bang would do here, or what more information would be useful. Actually I think [declare -lib blah] fails silently, so you could use this as a way to "catch" missing objects and specify an alternative.
I stole some code from IOhannes to get canvas args without digging into the innards of g_canvas.c. :)
-Jonathan
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at" pd-dev@iem.at Cc: Sent: Friday, March 1, 2013 1:27 PM Subject: Re: [PD-dev] info classes
Just made a change so that the "args" method grabs from the parent instead of the root canvas.
After some more testing I think this change is wrong. If [my_abstraction]'s args are "foo bar" and I'm inside subpatch [pd blah], the tk window for [pd blah] shows the args as "(foo bar)" and not "(blah)". But this is just an effect of the larger point, which is that the _abstraction_ arguments are the ones that replace dollarsign variables regardless of which subpatch you happen to be in. So the "args" method to [canvasinfo] should return the atoms that will replace $1, $2, $3, etc. in the context of the current canvas. Even for nested subpatches, that means the arguments for the root canvas (i.e., containing abstraction, or if there's no abstraction then the toplevel patch), so those are the ones that will be returned. That makes the canvasinfo "args" method consistent with the rest of the Pd interface.
The only question is how to accommodate a user who wants to grab the args of a [pd]. For this I'd like to simply add a method that returns the entire object box contents for the current canvas. So [pd blah] would return "pd blah", [foo-abstraction 1 2 3] would return "foo-abstraction 1 2 3", and so on. (I suppose a toplevel patch would just return a bang since there's no box, and I already have a "filename" method.)
But what should I call the method? objstring? boxmatter? boxtext? boxguts?
-Jonathan
Ok, I've got some working code for building a simple linked list of classes and a function to return a class by symbol. This should be fun.
Should I go ahead and make some convenience functions for accessing class members? That way anyone who wants to use this functionality can get info on a class without worrying about being locked in to the class struct if it happens to change.
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at" pd-dev@iem.at Cc: Sent: Saturday, March 2, 2013 3:45 PM Subject: Re: [PD-dev] info classes
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at"
Cc: Sent: Friday, March 1, 2013 1:27 PM Subject: Re: [PD-dev] info classes
Just made a change so that the "args" method grabs from the parent instead of the root canvas.
After some more testing I think this change is wrong. If [my_abstraction]'s args are "foo bar" and I'm inside subpatch [pd blah], the tk window for [pd blah] shows the args as "(foo bar)" and not "(blah)". But this is just an effect of the larger point, which is that the _abstraction_ arguments are the ones that replace dollarsign variables regardless of which subpatch you happen to be in. So the "args" method to [canvasinfo] should return the atoms that will replace $1, $2, $3, etc. in the context of the current canvas. Even for nested subpatches, that means the arguments for the root canvas (i.e., containing abstraction, or if there's no abstraction then the toplevel patch), so those are the ones that will be returned. That makes the canvasinfo "args" method consistent with the rest of the Pd interface.
The only question is how to accommodate a user who wants to grab the args of a [pd]. For this I'd like to simply add a method that returns the entire object box contents for the current canvas. So [pd blah] would return "pd blah", [foo-abstraction 1 2 3] would return "foo-abstraction 1 2 3", and so on. (I suppose a toplevel patch would just return a bang since there's no box, and I already have a "filename" method.)
But what should I call the method? objstring? boxmatter? boxtext? boxguts?
-Jonathan
An update for the [classinfo] object:
*** Get methods and args with [classinfo] ***
You can get the number of methods for [bng] (other than built-ins like bang, float, etc.):
[methods( | [classinfo bng]
Or send a float to get the method and args at that index:
[my_numbox] | [classinfo bng]
Above, sending a "0" gives: list click A_FLOAT A_FLOAT A_FLOAT A_FLOAT A_FLOAT
Since all the pd classes are stored as methods to a class named "objectmaker", [mynumbox]---[classinfo objectmaker] lets you peruse all the loaded objects' args at your leisure. Put that all together with an [until] and a [route some-object-name] you can get the argument types for any loaded object. That's pretty handy, so I added some syntactic sugar:
[args( | [classinfo bng]
The above will do all that for you, thus outputting: symbol A_GIMME
This is in addition to figuring out which build-in methods a class accepts (float, symbol, etc.) as well as many of the other class fields. So now you can program 1,000 [random] monkeys building infinite well-formed Pd patches with the correct args and methods!
More useful, however, is that we can now auto-build a help patch with _some_ [pd META] comments already filled in, plus programmatically add argument info to the extant help patches. Of course the A_GIMME example above shows why the author can't be 100% lazy, but it does make it lots easier to make fun of devs who are 100% lazy since 50% of the work will be autocompleted by clicking a button. :)
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at" pd-dev@iem.at Cc: Sent: Monday, March 4, 2013 6:35 PM Subject: Re: [PD-dev] info classes
Ok, I've got some working code for building a simple linked list of classes and a function to return a class by symbol. This should be fun.
Should I go ahead and make some convenience functions for accessing class members? That way anyone who wants to use this functionality can get info on a class without worrying about being locked in to the class struct if it happens to change.
-Jonathan
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com; "pd-dev@iem.at"
Cc: Sent: Saturday, March 2, 2013 3:45 PM Subject: Re: [PD-dev] info classes
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Jonathan Wilkes jancsika@yahoo.com;
"pd-dev@iem.at"
Cc: Sent: Friday, March 1, 2013 1:27 PM Subject: Re: [PD-dev] info classes
Just made a change so that the "args" method grabs from the parent instead of the root canvas.
After some more testing I think this change is wrong. If
[my_abstraction]'s
args are "foo bar" and I'm inside subpatch [pd blah], the tk window for [pd blah] shows the args as "(foo bar)" and not "(blah)". But
this is
just an effect of the larger point, which is that the _abstraction_ arguments are the ones that replace dollarsign variables regardless of which subpatch you happen
to
be in. So the "args" method to [canvasinfo] should return the
atoms
that will replace $1, $2, $3, etc. in the context of the current canvas. Even for
nested
subpatches, that means the arguments for the root canvas (i.e., containing abstraction, or if there's no abstraction then the toplevel patch), so
those
are the ones that will be returned. That makes the canvasinfo "args"
method consistent with the rest of the Pd interface.
The only question is how to accommodate a user who wants to grab the args of a [pd]. For this I'd like to simply add a method that returns the
entire
object box contents for the current canvas. So [pd blah] would return "pd blah", [foo-abstraction 1 2 3] would return "foo-abstraction 1 2 3", and
so
on. (I suppose a toplevel patch would just return a bang since there's no box, and I already have a "filename" method.)
But what should I call the method? objstring? boxmatter? boxtext? boxguts?
-Jonathan
Some questions:
1) input/output format:
[attribute( | [canvasinfo]
|
Currently the output is "list foo bar bee". I considered outputting "attribute foo bar bee" to make it a little easier to route output when getting multiple attributes:
[attribute1, attribute2, attribute3( | [canvasinfo] | [route attribute3 attribute2 attribute1] | | |
[pack 0 0 0]
But there is a cost: you would have to do a [route attribute] or [$1( or [list split 1] any time you want to get just a single attribute. Furthermore, you can just do a [t a a] to forward "attribute" to the right inlet of [list prepend]---[route attribute3 attribute2 attribute1] if you need to get multiple attributes in sequence.
Additionally, I'm outputting "list foo bar bee" and not "foo bar bee" so that there's no chance of outputting a badly formed message. But for convenience I'm taking input [pack]-style, meaning that
both "list attribute 2" and "attribute 2" get the attribute and number distributed among the inlets.
Anyone see a problem with this type of interface?
2) system audio and MIDI devices What exactly would be useful here? Here's a sketch: * the active audio api. Should this be "A_FLOAT A_SYMBOL" where the float is the api# and the symbol is its description, or "A_FLOAT (atom) (atom) etc..." where the api description is broken into atoms according to pd's whitespace parsing rules? * available audio apis. same syntax as above * available audio devs. same syntax as above * audio params. these should just be for the currently selected device, no? And should these be split up and accessible by their names? ("channels", "samplerate", etc.) * midi stuff. same as above?
Any other audio-related stuff? I've already got DSP status.
-Jonathan
Taking a stab at getting audio API and device info with [pdinfo]:
It is currently difficult to control audio settings programmatically from within a patch. Users might want to do the following: * connect through JACK when they open patchX.pd, and through ALSA or Pulse when running any other patch * instructor might want to increase/decrease latency for demoX.pd on all the students laptops, which may be running different OSes/APIs * probably a lot else
1) Need to be able to query the current audio/midi API being used:
[audioapi( | [pdinfo] | "symbol ALSA"
Or should there be a single "api" method that returns an audio/midi pair like "list ALSA ALSA"?
2) Need to be able to query the available audio/midi APIs:
[listaudioapis( | [pdinfo] | "list OSS ALSA PA JACK ESD dummy"
or on windows you might get
"list MMIO ASIO"
3) Either let the user query the API symbol and get its esoteric api number, for use in the audio-dialog message:
[ALSA( | [pdinfo] | "1"
or change audio-setapi to take A_GIMME and translate a symbolarg to the corresponding number there so that this can be completely hidden from the user. (I'd vote for the latter)
4) Might need to be able to query the available audio devices for the current API. I'm kind of lost on this one. But I suppose all you'd need is:
[listaudioindevices( | [pdinfo] | "list HDA ATI SB (hardware) HDA ATI SB (hardware) HDA ATI HDMI (hardware) HDA ATI HDMI (plug-in)" | [list length] | "4"
AFAICT you can only deal with 4 devices total. The above is not optimal since those symbol-atoms have spaces in them and thus are difficult to [route] or [select].
5) Need to be able to query the current audio-dialog attribute values:
[listaudioparams( | [pdinfo] | "0 1 2 3 4 5 6 7 8 9 10 etc."
6) Need to query an annotated version of the current audio-dialog attribute values. I think it's best to just print them out to the console with newlines:
[printaudioparams(
| [pdinfo]
To the console:
DeviceIn1 0 DeviceIn2 1 DeviceIn3 2 DeviceIn4 3 DeviceIn1-Channels 4 DeviceIn2-Channels 5 DeviceIn3-Channels 6 DeviceIn4-Channels 7 DeviceOut1 0 DeviceOut2 1 DeviceOut3 2 DeviceOut4 3 DeviceOut1-Channels 4 DeviceOut2-Channels 5 DeviceOut3-Channels 6 DeviceOut4-Channels 7 SampleRate 8 AudioAdvance 9 Callback 10 Blocksize etc. 7) Might be handy to have this as well:
[listallaudioapis( | [pdinfo] |
"list MMIO ASIOOSS ALSA PA JACK ESD dummy"
That way you can see what Pd has available by default which may not be available on your own system.
-Jonathan
On 03/08/2013 21:48, Jonathan Wilkes wrote:
It is currently difficult to control audio settings programmatically from within a patch. Users might want to do the follow
not really, as there has been the "mediasettings" library around for about two years.
i think it already gives you access to all the stuff you want to do.
fgmasdr IOhannes
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-dev@iem.at Cc: Sent: Saturday, March 9, 2013 5:12 AM Subject: Re: [PD-dev] info classes
On 03/08/2013 21:48, Jonathan Wilkes wrote:
It is currently difficult to control audio settings programmatically from
within a
patch. Users might want to do the follow
not really, as there has been the "mediasettings" library around for about two years.
No, it's still difficult to control audio settings programmatically in Pd Vanilla, Pd-l2ork, and Pd-extended. Users shouldn't have to fish around for and compile an external library just because they'd rather have "ALSA" sent to a canvas instead of the console.
i think it already gives you access to all the stuff you want to do.
Thanks, I'll check it out and pull what I need into the kind of interface I've written about here.
-Jonathan
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-03-11 04:30, Jonathan Wilkes wrote:
not really, as there has been the "mediasettings" library around for about two years.
No, it's still difficult to control audio settings programmatically in Pd Vanilla, Pd-l2ork, and Pd-extended. Users shouldn't have to fish around for and compile an external library just because they'd rather have "ALSA" sent to a canvas instead of the console.
probably true, but i don't know how you can fix this.
it seems like your obvious solution is to include [pdinfo] into Pd-vanilla, Pd-extended and Pd-l2ork. you can also simply include [audiosettings] and [midisettings] into Pd-vanilla, Pd-extended and Pd-l2ork.
the advantage of the 2nd solution is that it is already there and a few people are already using it, whereas your proposal gives exactly the same functionality but is (afaict) not already there.
and [pdinfo] sounds like a query-only object rather than an object that can control Pd.
gfmsdt IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Cc: Sent: Monday, March 11, 2013 4:23 AM Subject: Re: [PD-dev] info classes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-03-11 04:30, Jonathan Wilkes wrote:
not really, as there has been the "mediasettings" library
around
for about two years.
No, it's still difficult to control audio settings programmatically in Pd Vanilla, Pd-l2ork, and Pd-extended. Users shouldn't have to fish around for and compile an external library just because they'd rather have "ALSA" sent to a canvas
instead of
the console.
probably true, but i don't know how you can fix this.
it seems like your obvious solution is to include [pdinfo] into Pd-vanilla, Pd-extended and Pd-l2ork.
Getting it in 2 out of 3 Pd flavors is good enough for me. :)
you can also simply include [audiosettings] and [midisettings] into Pd-vanilla, Pd-extended and Pd-l2ork.
the advantage of the 2nd solution is that it is already there and a few people are already using it, whereas your proposal gives exactly the same functionality but is (afaict) not already there.
For audio settings it's partially there already, because the audio api stuff is pretty easy to implement and I didn't notice your mediasettings stuff.
and [pdinfo] sounds like a query-only object rather than an object that can control Pd.
It is. But I don't think it'd be too hard to add some user-oriented messages to the "pd" receive symbol for setting stuff.
-Jonathan
gfmsdt IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlE9lI8ACgkQkX2Xpv6ydvRtVQCfS40Xo6Ur1rrkD1ss9vH6BH0a txwAoNhqDGw6YnkyKm5oqDPXIIosVKmm =yR8F -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes