Here's a workaround to call [cyclone/line~] in pd-vanilla without overwritting vanilla's [line~]
First, a little history... Seems cyclone was first designed with First Capital letters object names to avoid name clashing, such as [Line~], this was present in Extended up to version Pd-Extended 0.42-5 (cyclone's version was then 0.1alpha 55). In Pd Extended 0.43 (and cyclone 0.1 alpha 56), cyclone also included two aliases for Line~ and other name clahsing objects, so it could instantiate also as only "line~". But the thing is that vanilla's [line~] would have priority and never be overwritten. Using [cyclone/line~] here would allow you to call cyclone's [line~] without screwing with vanilla's. What I found out is that cyclone, in this version, also carries another alias "cyclone/line~" this does not call a line~ object inside the cyclone folder, but calls "cyclone/line~" inside cyclone. So I supressed the "line~" alias and kept me with "Line~" (original object name) and "cyclone/line~" (alias), then tested on vanilla 0.46-7 64 bits and 32 bits. Now, if I call [Line~] on vanilla, it loads cylone's line~ without overwritting vanilla's [line~]. And I can also call it as [cyclone/line~] that vanilla's [line~] keeps intact and not overwritten! I tested the same compiled object in Pd Extended 0.42-5 (I don't use 0.43) and it worked fine as well. Thus, a quick immediate fix for this is changing the alias inside cyclone... seems like a workaround, but doesn't look that good I have to say... Besides cyclone, I don't know why anyone else would create externals with the same name as a vanilla internal... I still think that overwritting and renaming to "x_aliased" is not a good idea. The incapacity to specify objects inside regular libs is an old thing, I think it could be a nice feature request. cheers 2016-04-06 14:51 GMT-03:00 Alexandre Torres Porres <[email protected]>: > it's cool cyrille, sorry if I was too upset and harsh by the way :) > > Well, I actually seem to have found a trick... testing it right now! Stay > tuned... > > 2016-04-06 14:36 GMT-03:00 cyrille henry <[email protected]>: > >> >> >> Le 06/04/2016 17:53, Alexandre Torres Porres a écrit : >> >>> >>> >>> 2016-04-06 7:11 GMT-03:00 cyrille henry <[email protected] <mailto: >>> [email protected]>>: >>> >>> I see many example of the same issues, but not many issues. >>> >>> >>> ok, an issue (name clashing) that has many examples it is then. >>> >>> overwriting internals did not change anything in library clash-name >>> problem. >>> >>> >>> it did introduce the problem of name clashing between objects, being it >>> internal x external, or even between externals themselves - seems it just >>> made things worse. >>> >>> The way things are, name clashing is up for chance, it's a gamble. >>> >>> but yes, there is a problem in cyclone. >>> using cyclone as a libdir solve the name conflict problem >>> >>> >>> No it does not! Seems you're not grasping the issues I'm raising. >>> >> oups, sorry. >> right. it did create one more problem between extern and intern. >> it look like cyclone and vanilla dis not mix well together. >> >> >> >>> If I call [cyclone/line~] it will overwrite vanilla's [line~], and >>> [cyclone/line~] is not compatible to vanilla's - so name clashing and >>> incompatibility issues arise. >>> >>> This is one thing between internal x external objects. If there was a >>> way to specify [vanilla/line~], them great! Problem solved. But you do not >>> have any control on how to call vanilla line~ once it's been overwritten. >>> >>> using cyclone as a regular lib solve the weird name, but not >>> conflict. >>> >>> >>> the case with regular libs, whatever they are, is that you can't specify >>> them when loading a particular object, at least I don't know how to do >>> that. So again you have name clashing when objects aere overwritten. >>> >>> And I can also remember several other external objects with the >>> same name that aren't compatible - such as "uzi" as an alias of kalashnikov >>> or uzi from cyclone... >>> >>> they all obsolete since vanilla introduce [until], 10 years ago ;-) >>> >>> >>> No it's not obsolete as [uzi] has many features [until] doesn't have. >>> See... I get that Not using the externals is "a" solution, and one that I >>> actually thought of, but not the one I was after when raising this issue. >>> My motivations is finding a way to use externals and avoid name clashing, >>> so not using externals is not a valid solution for this issue. >>> >>> it just makes a lot of sense to me tha Pd allows the user to >>> have some control over what objects and externals to call. >>> >>> yes, obviously. it's the case when using libdir format, but not when >>> using regular lib. this is bad. >>> >>> >>> again, you seemed to not have realized that libdir also introduces >>> issues - so it is bad too, and it wasn't before! >>> >> yes, right. >> >> according to the mailing list, this feature was introduce in vanilla >> 0.42, and was briefly discuss 6 years ago. >> i did not find any other reference in this list since. >> >> >>> i think it take less time to write a 2 object abstraction than >>> sending this kind of mails. >>> >>> >>> good for you, let me be the one to raise the issues then. I just hope >>> you are not saying I shouldn't bother raising issues I'm having to >>> hopefully getting them sorted out. >>> >> its a good thing to raise - and solve - issues. >> >> >>> You cannot guarantee that your patches will work as they should >>> anywhere. >>> the ONLY solution to work everywhere is not to use external. >>> >>> >>> So far it's true, that's actually part of my point, things needed to >>> change to allow us a way to guarantee it >>> >>> if you do, the most safe solution is to load pd with -noprefs and >>> load preference per patch. >>> overwriting internals did not increase this problem, no solve it. >>> >>> >>> Overwriting internals did increase problems and made new issues arise. >>> At least in Extended and Pd-l2ork I can specify if I want cylone/line~ or >>> vanilla line~ - it'd be nice too if Pd-l2ork offered a way to load a >>> particular external from a specific regular lib or another. With such both >>> features, we'd have a safe and guaranteed solution >>> >>> I understand that you are upset because it break cyclone, but >>> except that, it's a nice feature (that should only be use wisely) >>> >>> >>> yeah, but it's not really nice if it introduces issues and losses. and >>> what would you lose if you could specify wether you wanted an object from >>> vanilla or one library or another? >>> >>> I get it that you do not have personal issues with the way things are, >>> that you are coping with it, but I'm not like that. >>> >> and i understand why you are upset with things been like that. >> >> >> >>> usually, it take me 10 years to understand why miller made the right >>> choice ;-) >>> >>> >>> Hey buddy, I'm open... but I need more than things like: >>> >>> - Got a problem with externals? Do not use the externals then; >>> - Yeah, you do have a problem and I don't have a solution, but other >>> than that, the thing you are complaining about is nice. >>> - I, personally, don't mind the issue, and I think that some workarounds >>> are worth it >>> - You might not agree it is nice now, and I'm not really trying to prove >>> any point, but maybe if you give it 10 years you might change your mind >>> >> ok, i'm sorry i could not help. >> >> cheers >> c >> >> >> >> >>> I still do not see any advantage in object overwritting, and I see how >>> it is causing name clashes. >>> >>> cheers >>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >>> >>> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
