I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~] the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
.hc
----------------------------------------------------------------------------
kill your television
Quoting "Hans-Christoph Steiner" hans@at.or.at:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~] the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
while you are there, i would propose to use "/foo/bar" rather than "foo/bar".
while this doesn't fully match the [foo/bar] idiom for object-names, it does fit nicely into OSC.
mfgasdr IOhannes
gfamnsdr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Nov 16, 2009, at 3:10 PM, zmoelnig@iem.at wrote:
Quoting "Hans-Christoph Steiner" hans@at.or.at:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~] the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
while you are there, i would propose to use "/foo/bar" rather than "foo/bar".
while this doesn't fully match the [foo/bar] idiom for object-names, it does fit nicely into OSC.
Hmm, I guess that's a parallel. I personally never use OSC, so I don't see a reason to follow its syntax instead of Pd's syntax. Since the foo/bar syntax is already there, I think its best to stick with it for Pd. Then for people who use OSC, it would be an easy translation.
Plus wouldn't OSC namespaces follow the project rather than a library? I guess if you use OSC in a library, then it would follow the library.
.hc
----------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
On Nov 16, 2009, at 3:10 PM, zmoelnig@iem.at wrote:
Quoting "Hans-Christoph Steiner" hans@at.or.at:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~] the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
while you are there, i would propose to use "/foo/bar" rather than "foo/bar".
while this doesn't fully match the [foo/bar] idiom for object-names, it does fit nicely into OSC.
Hmm, I guess that's a parallel. I personally never use OSC, so I don't see a reason to follow its syntax instead of Pd's syntax. Since the foo/bar syntax is already there, I think its best to stick with it for Pd. Then for people who use OSC, it would be an easy translation.
why do you want a translation, if there is no need for one?
Plus wouldn't OSC namespaces follow the project rather than a library? I guess if you use OSC in a library, then it would follow the library.
right, let the user examine whether the lib uses OSC somewhere internally, and then they will figure out whether to prefix / or not :-)
it's open source after all
mgare IOhannes
2009/11/16 zmoelnig@iem.at:
Quoting "Hans-Christoph Steiner" hans@at.or.at:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~] the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
while you are there, i would propose to use "/foo/bar" rather than "foo/bar".
while this doesn't fully match the [foo/bar] idiom for object-names, it does fit nicely into OSC.
(okay, time-warping self-nullifying emailing at its best - see ending parenthetical for my most up-to-date thinking on this matter. I think I agree with IO after all).
Just a quick comment... when I was writing and pondering the (still very small) Pd Style Guide I decided it wasn't a good idea to use "/" in send/receive namespaces.
The reason being, I didn't see a point in making s/r addresses look like OSC addresses if they /weren't/ always OSC addresses, and that it would be better to be explicit about how OSC fits into the picture in cases where it actually does.
I used "-", like [s framesync-fps] (which matched well with what miller and the majority of Pd users do habitually anyway (albeit with no discernible formality in most cases).
Anyway, it's not meant as an attempt to bikeshed, just wanted to mention it : ).
(Ah, and just as I was about to hit send, I think I finally get the idea of doing this: it's so one could receive incoming OSC messages like [/framesync/fps 5( and then use a dynamic [send] to dispatch them to the right [recieve]s! I was stuck thinking you'd need a bunch of [routeOSC]s everywhere which, in my previous experience, slowed my patches to a crawl.).
Best Luke
mfgasdr IOhannes
gfamnsdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Nov 16, 2009, at 9:18 PM, Luke Iannini wrote:
2009/11/16 zmoelnig@iem.at:
Quoting "Hans-Christoph Steiner" hans@at.or.at:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~] the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
while you are there, i would propose to use "/foo/bar" rather than "foo/bar".
while this doesn't fully match the [foo/bar] idiom for object- names, it does fit nicely into OSC.
(okay, time-warping self-nullifying emailing at its best - see ending parenthetical for my most up-to-date thinking on this matter. I think I agree with IO after all).
Just a quick comment... when I was writing and pondering the (still very small) Pd Style Guide I decided it wasn't a good idea to use "/" in send/receive namespaces.
The reason being, I didn't see a point in making s/r addresses look like OSC addresses if they /weren't/ always OSC addresses, and that it would be better to be explicit about how OSC fits into the picture in cases where it actually does.
I used "-", like [s framesync-fps] (which matched well with what miller and the majority of Pd users do habitually anyway (albeit with no discernible formality in most cases).
Anyway, it's not meant as an attempt to bikeshed, just wanted to mention it : ).
(Ah, and just as I was about to hit send, I think I finally get the idea of doing this: it's so one could receive incoming OSC messages like [/framesync/fps 5( and then use a dynamic [send] to dispatch them to the right [recieve]s! I was stuck thinking you'd need a bunch of [routeOSC]s everywhere which, in my previous experience, slowed my patches to a crawl.).
Having the send/receive name the same as an OSC name sounds like a great idea if you are using OSC. But Pd != OSC, and I'd guess most Pd users never use OSC. I think we should follow Debian's lead here and use the same name everywhere. The remarkable consistency of Debian is a key reason why its so nice to use it. So in Debian, we have a package called 'foo', then you have:
foo-1.0-1_i386.deb /usr/share/foo /usr/share/doc/foo /usr/share/applications/foo.desktop /etc/foo /etc/init.d/foo start /etc/default/foo /usr/lib/foo /var/lib/foo /var/log/foo
The only changes to the name 'foo' are when they are required, like '.desktop' and '-1.0-1_i386.deb'. Since we are talking about Pd here, we can use one naming convention is as many places as possible. Then those who want to use OSC to send to these standardized symbols can use an object that strips off the leading slash, if need be.
.hc
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object.
For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~]
Why not call it [framesync/tabplay~]? Is [import] not yet good enough? Missing a feature like [import framesync as fs] to use [fs/tabplay~]?
the internal send/receive would be [send framesync/fps] and [receive framesync/fps].
.hc
Personally I'm not a fan of globals(*) - better for the user to tell the objects explicitly what name they should use to share information, thus letting more than one instance of the library functionality be used in the same instance of Pd.
So, my suggestion would be to use the first argument (or other easy to remember convention) to be the namespace to use for communication: if the user really wants a global they can use [framesync/fstabplay~ fs] and if they don't they can use [framesync/fstabplay~ $0].
The three extra characters " $0" are hardly a huge burden, but the benefits can be large imho.
But yes, if globals *must* be used, then using a global name closely related to the name of the library seems sensible.
(*) Pd has no non-globals, just obfuscated names..
Claude
On Nov 16, 2009, at 5:55 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
I am in the process of working on my 'framesync' library, and I just had a thought that I am not sure has come up before. Lots of times, we want to use send/receives in reusable code, but with a global namespace, there is the potential for nameclashes. So I propose that for libraries, we make it a 'best practice' to use the same namespace prefix as you would for loading an object. For example, this 'framesync' library, I need to send the FPS (Frames Per Second) to all the objects, so it needs to be a global send. So just like I could do [framesync/fstabplay~]
Why not call it [framesync/tabplay~]?
I think that relying on the namespaces alone could make for confusion if you want to use tabplay~ along with fstabplay~.
Is [import] not yet good enough?
[import foo] just loads a lib as if you did "pd -lib foo" or however you do it with [declare].
Missing a feature like [import framesync as fs] to use [fs/tabplay~]?
I think that python's import is much too complicated for Pd. I spent a long time wading thru all of the relevant discussions, code, and docs that I could find and put it in my PdCon3 paper. I would love to have feedback on the details of that paper rather than just reiterating bits of what's there.
http://at.or.at/hans/Let%27s_Make_Libraries_-_PdCon3.pdf
the internal send/receive would be [send framesync/fps] and [receive framesync/fps]. .hc
Personally I'm not a fan of globals(*) - better for the user to tell the objects explicitly what name they should use to share information, thus letting more than one instance of the library functionality be used in the same instance of Pd.
So, my suggestion would be to use the first argument (or other easy to remember convention) to be the namespace to use for communication: if the user really wants a global they can use [framesync/fstabplay~ fs] and if they don't they can use [framesync/ fstabplay~ $0].
The three extra characters " $0" are hardly a huge burden, but the benefits can be large imho.
But yes, if globals *must* be used, then using a global name closely related to the name of the library seems sensible.
(*) Pd has no non-globals, just obfuscated names..
Yeah, I also try to avoid globals as much as possible. With this library, its kind of mirroring the audio clock of tilde objects, so [fps] is like [samplerate~] and the frameclock is transparent, just like you don't have to tell tilde objects which audio clock to use. I am trying to address situations when you are scoring to a video. I can't see a time when you would have to deal with multiple video framerates within the same project.
I want to avoid having all this as arguments, since some of the objects already have 4 arguments. But I am open to suggestions to how else to deal with this. It would be nice to have the frame clock and fps within a project namespace, I just can't think of a way to do it without making things too complicated.
.hc
----------------------------------------------------------------------------
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." --Bjarne Stroustrup (creator of C++)
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
(*) Pd has no non-globals, just obfuscated names..
Yeah, I also try to avoid globals as much as possible. With this library, its kind of mirroring the audio clock of tilde objects, so [fps] is like [samplerate~] and the frameclock is transparent, just like you don't have to tell tilde objects which audio clock to use. I am trying to address situations when you are scoring to a video. I can't see a time when you would have to deal with multiple video framerates within the same project.
I want to avoid having all this as arguments, since some of the objects already have 4 arguments. But I am open to suggestions to how else to deal with this. It would be nice to have the frame clock and fps within a project namespace, I just can't think of a way to do it without making things too complicated.
If you really want to use globals I think you should minimize the number of global names in use by using a [route]-based approach like this:
[r GLOBAL_FRAMESYNC_RECEIVER] | [route fps pos ...] | | ...
Personally I have all my globals in UPPERCASE. In sssad, I used "SSSAD_" as prefix with divider.
A way to give users some flexibility in regard to globals is to let them name the globals with a $1 argument. This would make it possible for users to create groups of related code sections that are still independend from each other, for example to have two things playing at different FPS values, which would be impossible if "fps" is global. In the audio system of Pd the samplerate can be changed in subpatches, although a different approach is used for that.
Passing $0 as $1 would even make things "local" again.
Ciao
On Nov 17, 2009, at 4:53 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
(*) Pd has no non-globals, just obfuscated names..
Yeah, I also try to avoid globals as much as possible. With this library, its kind of mirroring the audio clock of tilde objects, so [fps] is like [samplerate~] and the frameclock is transparent, just like you don't have to tell tilde objects which audio clock to use. I am trying to address situations when you are scoring to a video. I can't see a time when you would have to deal with multiple video framerates within the same project.
I want to avoid having all this as arguments, since some of the objects already have 4 arguments. But I am open to suggestions to how else to deal with this. It would be nice to have the frame clock and fps within a project namespace, I just can't think of a way to do it without making things too complicated.
If you really want to use globals I think you should minimize the number of global names in use by using a [route]-based approach like this:
[r GLOBAL_FRAMESYNC_RECEIVER] | [route fps pos ...] | | ...
Personally I have all my globals in UPPERCASE. In sssad, I used "SSSAD_" as prefix with divider.
A way to give users some flexibility in regard to globals is to let them name the globals with a $1 argument. This would make it possible for users to create groups of related code sections that are still independend from each other, for example to have two things playing at different FPS values, which would be impossible if "fps" is global. In the audio system of Pd the samplerate can be changed in subpatches, although a different approach is used for that.
Passing $0 as $1 would even make things "local" again.
I've mostly done the UPPERCASE global symbols too. Its kind of an old convention. I am just really trying to think in Debian terms when organizing this stuff because I think Debian is awesome (did I mention DebConf10 is in NYC and I'm helping to run the thing :-D ).
So I guess to make it localizable, it would have to be something like framesync/fps$1. Without a settable receive, it makes this kind of chore to deal with then. I don't see a simple, clean way to incorporate some kind of project-specific pre/post-fix.
.hc
----------------------------------------------------------------------------
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So I guess to make it localizable, it would have to be something like framesync/fps$1. Without a settable receive, it makes this kind of chore to deal with then.
If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :)
Ciao
On Nov 18, 2009, at 2:35 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So I guess to make it localizable, it would have to be something like framesync/fps$1. Without a settable receive, it makes this kind of chore to deal with then.
If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :)
Why not have settable receives? I dont' see the downside or harm. In this case, a settable receive is only possible via arguments and dollarargs in the receive object box. I guess that's an old issue...
Perhaps another approach would be to have a standard receive name for a library, then make it local using routes. So something like [receive framesync/framesync] then the next route would be the project ID, then the standard bits of data (i.e. fps).
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
Why not have settable receives?
iirc, the problem is that you can easily make Pd crash with settable receives.
fgmar IOhannes
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 18, 2009, at 2:35 AM, Frank Barknecht wrote:
If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :)
Why not have settable receives? I dont' see the downside or harm. In this case, a settable receive is only possible via arguments and dollarargs in the receive object box. I guess that's an old issue...
I didn't mean to start a discussion on the general usefulness of settable receives (about which I have an opinion), I only meant your usecase, which as I understand is that you want to share a global or remote value like a video's FPS in many abstractions. For this I don't think you need a settable receive, as you can reserve a single, unchanging reveiver to receive such information, either a multi-use single-name receiver that distributes items with [route] or many separate receivers (with the namespace pollution problem).
Perhaps another approach would be to have a standard receive name for a library, then make it local using routes. So something like [receive framesync/framesync] then the next route would be the project ID, then the standard bits of data (i.e. fps).
Yep.
Ciao
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Luke Iannini -
zmoelnig＠iem.at