[L2Ork-dev] external objects path

[Gilberto Agostinho]

Hi Ico,

Indeed pd-extended is able to recognize an external object that is 
inside a subfolder of a path when the subfolder has the same name. I 
find feature useful to organize objects, because you keep them, their 
help files and any other files such as readme that may come with them. 
It also makes it slightly faster to add new objects, since no 
modification to the path is necessary. If it is a feature or byproduct, 
I really wouldn't know.

But indeed this is not an important issue at all, I just wanted to bring 
it to light because of the difference of behaviour when compared with 
pd-extended rather than asking for the feature to be implemented.

Best,
Gilberto

On 15/11/14 04:54, Ivica Ico Bukvic wrote:
> I think this is something I don't feel as strongly about as you do. 
> Perhaps one possibility would be to recursively navigate subfolders, 
> rather than devising some kind of a one-of navigation with a 
> subfolder. But there is a more fundamental problem we need to tackle 
> first which is the order of paths in respect to individual patches. I 
> agree with Jonathan that the first place a patch should look is its 
> own folder and then go from there to explore the rest of the paths. If 
> so, I would first worry about this, then worry about recursive 
> searching of an object, which would also address your request.
>
> All that said, I am wondering if you are suggesting that pd-extended 
> is able to recognize an external in a subfolder with a same name? If 
> so, I wonder if this is a feature or a byproduct of the current 
> implementation...
>
> Best,
>
> Ico
>
> On 11/14/2014 7:54 PM, Gilberto Agostinho wrote:
>> Hi all,
>>
>> I am sorry to bump this up, but I have the impression this message 
>> got forgotten in the middle the discussions about the latest commits.
>>
>> Best,
>> Gilberto
>>
>> On 13/11/14 03:34, Gilberto Agostinho wrote:
>>> Hello all,
>>>
>>> I just found out that Pd-l2Ork behaves differently than Pd-extended 
>>> when it comes to the path of external objects. Let's say I have some 
>>> objects named exampleN and their help files in the following folder 
>>> structure:
>>>
>>> ~/.pd/extra-objects/example1/example1.pd
>>> ~/.pd/extra-objects/example1/example1-help.pd
>>> ~/.pd/extra-objects/example2/example2.pd
>>> ~/.pd/extra-objects/example2/example2-help.pd
>>> ~/.pd/extra-objects/example3/example3.pd
>>> ~/.pd/extra-objects/example3/example3-help.pd
>>>
>>> That is, I don't want to simply put all these extra objects in a 
>>> same folder, each one has their one specific folder with the same 
>>> name. With Pd-extended, I could simply add ~/.pd/extra-objects to my 
>>> path, and all of them would be automatically loaded (if and only if 
>>> their subfolder names are the exact same as the object's name). This 
>>> is very handy because you can organize your objects better, and also 
>>> needs less work than adding each single one of them to your path.
>>>
>>> What do you think about this?
>>>
>>> Best,
>>> Gilberto
>>
>>
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> http://disis.music.vt.edu/listinfo/l2ork-dev
>
> -- 
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
> www.performingarts.vt.edu
> disis.music.vt.edu
> l2ork.music.vt.edu
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20141115/6a82b6c1/attachment-0001.html>