[PD-dev] namespaces for send/receive

[Hans-Christoph Steiner]

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

----------------------------------------------------------------------------

                                               http://at.or.at/hans/