[PD] [import] question

[Hans-Christoph Steiner]

Hey,

I am cc'ing the Pd list with the discussion about [import] since I  
think it is of general interest.

On Sep 17, 2008, at 3:46 AM, Phil Stone wrote:

> Hey Hans,
>
> Thanks for replying.
>
> I'm [import]ing mrpeach and cyclone -- I'm using svf~ from cyclone  
> and some mrpeach OSC objects at least once for each polyphonic  
> instantiation of synthesizer voice.  Are [import]ed "libdir style"  
> objectclasses  loaded once and shared by all instances, or loaded  
> once for each instance?

The state of namespaces is currently a work in progress.  So with  
abstractions, using import means that they are loaded into the parent  
patch's canvas-local namespace only.  But with binary/compiled  
externals, once they are loaded, they are loaded globally.  I plan on  
focusing on fixing this stuff later this year for the next Pd- 
extended release.

> Are mrpeach and cyclone libdir-style libraries?

In Pd-extended, yes.

> Can I ask your recommendation for the best way to do external- 
> inclusion in this (auto-generated poly-objects) situation?  I'll  
> stick with [import] if it is not some kind of performance or memory  
> hit, but I don't fully understand the trade-offs, if any.

There aren't really any major performance considerations here that I  
am aware of.  Mostly it is about ensuring that your patch will work  
on the widest array of computers.  If you want to guarantee that you  
always get the right object, then use a namespace prefix, like  
[cyclone/prepend].  Then you'll always get cyclone's prepend no  
matter how the person's Pd-extended is setup, or what [import]s are  
used.  For Pd-vanilla users, they would just need to have cyclone  
installed as individual files per object-class in "extra/cyclone" and  
it would work the same (i.e. by copying "extra/cyclone" from Pd- 
extended, or building it themselves).

.hc

>
> Phil
>
> Hans-Christoph Steiner wrote:
>>
>> Hey,
>>
>> Sorry, I am super slammed at the moment.  Whether it loads it into  
>> memory depends on the library type.  With the old single-file- 
>> multiple-objectclass format, like Gem, PDP, etc. the whole thing  
>> is indeed loaded into memory.  With the "libdir" style, no  
>> objectclass is loaded into memory until you use it.
>>
>> .hc
>>
>> On Sep 16, 2008, at 7:09 PM, Phil Stone wrote:
>>
>>> Hi Hans,
>>>
>>> Sorry to bug you directly on this, but I think my question got  
>>> lost in the noise, and I'm trying to figure this out before I  
>>> release a big chunk of abstraction to the Pd community (another  
>>> polyphonic synthesizer, granular this time).
>>>
>>> Re-iterating my question from below:  when [import] says "loaded  
>>> library:  blah", is that literally what it's doing, loading the  
>>> library into memory, once for every one of the messages in a  
>>> multiple [import] situation as described below?
>>>
>>> I doubt that it is, as that would be incredibly inefficient, but  
>>> I would like to make sure.
>>>
>>> Thanks,
>>>
>>>
>>> Phil
>>>
>>>> multiple copies of cyclone (for instance, as below) are not  
>>>> really getting loaded are they?  Pardon my ignorance of the  
>>>> mechanics of [import].
>>>>
>>>> Phil
>>>>
>>>>
>>>>
>>>> Phil Stone wrote:
>>>>
>>>>> > I'm using [import] on an abstraction (as discussed earlier);  
>>>>> this > abstraction does some automatic object instantiation  
>>>>> (via [polypoly]) > and each of the generated objects has an  
>>>>> [import ...] in it.  This leads > to a barrage of console  
>>>>> output, like:
>>>>> >
>>>>> > [import] loaded library: 'cyclone'
>>>>> > libdir_loader: added 'cyclone' to the canvas-local  
>>>>> objectclass path
>>>>> > libdir_loader: added 'cyclone' to the canvas-local  
>>>>> objectclass path
>>>>> > [import] loaded library: 'cyclone'
>>>>> > libdir_loader: added 'cyclone' to the canvas-local  
>>>>> objectclass path
>>>>> > libdir_loader: added 'cyclone' to the canvas-local  
>>>>> objectclass path
>>>>> > .
>>>>> > .
>>>>> > .
>>>>> > (repeat for number of voices created by [polypoly].
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------- 
>> -------
>>
>> "Free software means you control what your computer does. Non-free  
>> software means someone else controls that, and to some extent  
>> controls you." - Richard M. Stallman
>>
>>
>>



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

There is no way to peace, peace is the way.       -A.J. Muste