regarding a workaround between zexy's <~ and cyclone's I can also think of a workaround
in Max/MSP there are alphanumeric versions of those objects, such as [greaterthan~]. So they can be compiled as single objects, allowing someone to specify it as cyclone/greaterthan~ if needed/desired. these would solve clashing issues I found with cyclone and vanilla/zexy but other overwritting potential issues remain cheers 2016-04-06 15:44 GMT-03:00 Alexandre Torres Porres <[email protected]>: > 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
