Hi Miller,
Now that Pd is running on diverse platforms and variants, it would be very useful to have a generic interface that a patch can use to query the current platform. Something like sending a "getinfo" message to the pd object which would send back e.g.:
list osx vanilla pure-data
list linux pd-l2ork pure-data
list ios zengarden
list android droidparty libpd pure-data
The use-case for this is things like:
On Android, audio latency is high and needs to be factored in by patches.
A patch that wants to load a text file might need to use a different
path delimiter on linux versus windows.
What are your thoughts on this?
I am assuming the Pd-l2ork fellows will pipe up with some already implemented solution. :)
Cheers,
Chris.
On 09/24/2014 12:15 AM, Chris McCormick wrote:
Hi Miller,
Now that Pd is running on diverse platforms and variants, it would be very useful to have a generic interface that a patch can use to query the current platform. Something like sending a "getinfo" message to the pd object which would send back e.g.:
I've got [pdinfo] in Pd-l2ork which has a [version( method. Wouldn't be hard to add a symbol for the Pd distro, too.
As for OS-- what's the best way to do this? (Both in terms of the possible strings to output and a way to distinguish them in the C code.)
list osx vanilla pure-data
list linux pd-l2ork pure-data
list ios zengarden
list android droidparty libpd pure-data
The use-case for this is things like:
On Android, audio latency is high and needs to be factored in by patches.
A patch that wants to load a text file might need to use a different
path delimiter on linux versus windows.
Do you have an example where this would be necessary? I thought Pd was
implemented in such a way that everyone just writes unix-style paths in
their patches and Pd converts to the local path delimiters underneath.
(At least that's the way the tutorials look, and they load
soundfiles/textfiles correctly on all platforms.)
What are your thoughts on this?
I am assuming the Pd-l2ork fellows will pipe up with some already implemented solution. :)
[print( | [pdinfo]
prints this to the console:
audio-api: ALSA audio-apilist: OSS ALSA audio-apilist-raw: none ALSA OSS MMIO PortAudio JACK SGI audio-inchannels: 2 audio-indev: 0 2 audio-indevlist: HDA Intel (hardware) HDA Intel (plug-in) audio-multidev-support: 2 audio-outchannels: 2 audio-outdev: 0 2 audio-outdevlist: HDA Intel (hardware) HDA Intel (plug-in) blocksize: 64 classtable: 254 classes loaded ("classtable" outputs the full list) dir: /usr/local/bin/ dsp-status: 0 midi-api: ALSA midi-apilist: OSS ALSA midi-indev: midi-indevlist: midi-outdev: midi-outdevlist: pi: 3.14159 samplerate: 44100 version: 0 42 7
Each attribute is a method you can use to send the values to the outlet, like [dir(--[pdinfo]--[set $1(--[/usr/local/bin/(
"pi" and "audio-apilist-raw" will probably be removed
There's also:
[print( | [canvasinfo]
which prints:
args: boxtext: coords: 0 0 0 0 0 0 0 0 0 dir: /home/pd/pd/src dirty: 1 dollarzero: 1002 editmode: 0 filename: Untitled-1 hitbox: 0 name: .x98092c8 pointer: (pointer) posonparent: 0 0 screenpos: 526 181 976 481 toplevel: 1 vis: 1
There's also [classinfo]
and
[objectinfo]
which give info about class args, size, methods, object xlets, bbox, text, etc. and are still under development.
-Jonathan
Cheers,
Chris.
On 09/24/2014 06:15 AM, Chris McCormick wrote:
Hi Miller,
Now that Pd is running on diverse platforms and variants, it would be
finally! t
very useful to have a generic interface that a patch can use to query the current platform. Something like sending a "getinfo" message to the pd object which would send back e.g.:
iirc, there was [operating_system] in zexy. it doesn't do everything you want (actually, it doesn't do most), but iirc it has not been touched since the advent of Pd-on-OSX.
The use-case for this is things like:
- On Android, audio latency is high and needs to be factored in by patches.
but on android you are most likely using libpd and therefore have yet another wrapper that actually sets the latency (hopefully to something useable).
- A patch that wants to load a text file might need to use a different
path delimiter on linux versus windows.
why would you want to do that? even microsoft allows using forward slashes in fopen()/open() and in any case, Pd (sh)would do any necessary conversion on the C-level (that is: you tell [textfile] to open "foo/bar.txt" and it will convert it to "foo/bar.txt", "foo\bar.txt" or "foo:bar.txt" depending on whatever is required to open the file. the patch doesn't need to know at all.
What are your thoughts on this?
so i think that the primary goal should be to make this functionality unneccessary: a patch should run on *all* implementations of Pd, without adapting it's behaviour. platform specific quirks to guarantee consistent behaviour through all platforms are in the realm of the implementation of the interpreter.
having said that, i still see the need for that functionality and support the idea for such an object (after all, that's why i wrote [operating_system], though i cannot remember having used it _ever_).
though the output shall be uniform, an dwe need much more info, like ptr-size and whatnot. something like [uname], with some Pd-specifics like flavour, and *version*.
and i think we should go for messages that only report a single thing, rather than outputting long lists (that keep growing the more system information we want to add).
[version, flavour, os( | [uname] | [route version flavour os] | | | [0.46\ | | | | [vanilla\ | [freeBSD\
gfmrds IOhannes
PS: so what's the OS on Debian/kFreeBSD?
On 24/09/14 17:05, IOhannes m zmölnig wrote:
[version, flavour, os( | [uname] | [route version flavour os] | | | [0.46\ | | | | [vanilla\ | [freeBSD\
gfmrds IOhannes
PS: so what's the OS on Debian/kFreeBSD?
for os you would surely want the userland and interface mostly ... i.e. Android or GNU or OSX or iOS or ... the difference between GNU/linux and Android/linux is much more significant than any difference between GNU/linux and GNU/FreeBSD as far as a user at this level is concerned, especially if both are debian, even though the name "GNU/linux" fell out of favour a while ago.
Simon
This is a bit off-topic, but you should know that a single savvy Wikipedia editor made a unilateral decision to change nearly all instances of GNU/Linux to Linux across every page other than the one that describes the naming kerfuffle itself. (I think Gnewsense and maybe one other had an editor who was able to resist the massive search/replace, and maybe one other). Other editors were essentially forced into accepting the massive search & replace.
So in that context it fell out of fashion in the same way that U2's new album fell into fashion, which is that someone with more permissions than you clicked some buttons to ensure that the bits you get are the bits they like.
Even more off-topic: This is especially worrisome given that Wikipedia's resources to deal with abuse haven't grown much, but the incentives and resources to corrupt its content are larger than ever. I only know about this case because the editor in question is particularly brazen; most of the abuse is much more subtle and goes undetected without analyzing IP addys, timestamps, and other metadata. (For example, if you're a student learning a new topic or concept by reading Wikipedia, how would you recognize and report a lie of omission?)
-Jonathan
On Wednesday, September 24, 2014 3:52 AM, Simon Wise simonzwise@gmail.com wrote:
On 24/09/14 17:05, IOhannes m zmölnig wrote:
[version, flavour, os( | [uname] | [route version flavour os] | | | [0.46\ | | | | [vanilla\ |
[freeBSD\
gfmrds IOhannes
PS: so what's the OS on Debian/kFreeBSD?
for os you would surely want the userland and interface mostly ... i.e. Android or GNU or OSX or iOS or ... the difference between GNU/linux and Android/linux is much more significant than any difference between GNU/linux and GNU/FreeBSD as far as a user at this level is concerned, especially if both are debian, even though the name "GNU/linux" fell out of favour a while ago.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello
Le 24/09/2014 09:05, IOhannes m zmölnig a écrit :
The use-case for this is things like:
I see some other points:
- the output from [keyname], [key], [gemkeyboard], [gemkeyname] is different
- the window in Gem has to be placed (offset) in a different way for OSX
for fullscreen.
- the [shell] and [popen] object that are a very good connection to all
the other software behave differently
- one might want to call different script on different os as well for
specific usage
- for some specific IP hardware (badly coded), the bit order is
different when communicating with TCP/UDP.
- the path management can be different (old pix_write object for example
still in last pd-extended)
Best,
Nicolas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-09-24 10:14, Nicolas Montgermont wrote:
Hello
Le 24/09/2014 09:05, IOhannes m zmölnig a écrit :
The use-case for this is things like:
I see some other points:
- the output from [keyname], [key], [gemkeyboard], [gemkeyname] is
different * the window in Gem has to be placed (offset) in a different way for OSX for fullscreen * for some specific IP hardware (badly coded), the bit order is different when communicating with TCP/UDP.
so these are mainly bugs in specifc objects we want to work around with such a feature? .
- the [shell] and [popen] object that are a very good connection to
all the other software behave differently * one might want to call different script on different os as well for specific usage
though the script itself already has the possibility to check which OS it's running on, and cold adjust it's behaviour (e.g. by forwarding the request to an OS-specific sub-script)...though probably not easy to run a .bat from a .sh and vice-versa
- the path management can be different (old pix_write object for
example still in last pd-extended)
but if somebody chose to install a newer version of [pix_write] on their outdated Pd-extended, you will still use it the wrong way. in this case you might want to ask the version of [pix_write] instead.
fgamsdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi IOhannes,
On 24/09/14 15:05, IOhannes m zmölnig wrote:
On 09/24/2014 06:15 AM, Chris McCormick wrote:
Now that Pd is running on diverse platforms and variants, it would be
finally!
Yes, good point, that was a daft thing for me to say.
The use-case for this is things like:
- On Android, audio latency is high and needs to be factored in
by patches.
but on android you are most likely using libpd and therefore have yet another wrapper that actually sets the latency (hopefully to something useable).
It's more about letting the patch know that it is on a platform with higher latency. My specific use-case is network sync of audio streams. Unfortunately higher latency is unavoidable on some device/version combinations on Android. However, I think you are right that this is probably not a good enough reason to introduce a new Pd object.
- A patch that wants to load a text file might need to use a
different path delimiter on linux versus windows.
why would you want to do that? even microsoft allows using forward slashes in fopen()/open() and in any case, Pd (sh)would do any necessary conversion on the C-level (that is: you tell [textfile] to open "foo/bar.txt" and it will convert it to "foo/bar.txt", "foo\bar.txt" or "foo:bar.txt" depending on whatever is required to open the file. the patch doesn't need to know at all.
Dan pointed this out too, and I did not know that. Thanks for the heads-up! Good to know.
What are your thoughts on this?
My thoughts are that my idea is looking to be increasingly on unsound footing.
It's probably enough for PdDroidParty to tell the user in some kind of startup message that they are on that platform, and likewise Dan could implement something similarly non-invasive in PdParty. I guess we'll discuss this off list if it's necessary.
PS: so what's the OS on Debian/kFreeBSD?
Again, good point. I do not know the answer, but I am glad there are smart people on this list to keep my brief madness in check.
Unfortunately, getting the odd patch accepted has the unintended side-effect of making one see more and more solutions as patches to Pd itself instead of more creative and minimal solutions. I am glad Miller doesn't suffer that problem!
Cheers,
Chris.
-
Chris McCormick -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Nicolas Montgermont -
Simon Wise