Hi, I have a question about upper case letters in the begining of some objects like [Uzi] and [Scope~] in cyclone. Why is that? In Pd it does make a difference by the way, not in Max.
Anyway, if one would change that, old patches would need to be updated as well, which is a bummer, but even so I think it's preferable not to deal with knowing which objects need the upper case or not, and for no apparent particular reason. One way or another, I wonder why it happened, anyone? cheers 2015-02-24 16:41 GMT-03:00 Alexandre Torres Porres <[email protected]>: > Cool. > > One way or another, I just use expr~ whener I need these things anyway. > But it might be convenient to have these objects, and I just feel like > start coding somewhere, and this seems like an easy task. So the idea of > having these exact proper clones of the max objects felt good to me. But it > I confess it might be just too silly for anyone to really bother, and it's > more related to my will to start coding. > > The thing is that this characters issue might just ruin or everything in > the end... or make it more complicated than I thought, so... bummer... > > By the way, my abstractions wouldn't be exact clones of the max objects, > cause they don't even take arguments (like yours don't also). > > I can at least work on getting a code version of teeth~ > > cheers > > 2015-02-24 16:16 GMT-03:00 Martin Peach <[email protected]>: > > I did some of those in Pd-extended as I had the same trouble with weird >> characters in object names; try mrpeach/op~ >> >> Martin >> >> On Tue, Feb 24, 2015 at 1:51 PM, Alexandre Torres Porres < >> [email protected]> wrote: >> >>> "*I made one abstraction here for [>=~], find it attached. It works >>> fine here in my computer **even though it contains "weird and >>> problematic" characters in its name.*" >>> >>> Ha, it doesn't work at all with [!/], but it does with [!-] >>> >>> 2015-02-24 15:43 GMT-03:00 Alexandre Torres Porres <[email protected]>: >>> >>> Another option is that we could just keep this somewhat different >>>> behaviour that's also in the zexy objects, and just add the other 7. Those >>>> extra 7 could be in cyclone or maybe even in zexy, but that's up to the >>>> maintainers. >>>> >>>> I would really like to collaborate though. I've been meaning to start >>>> coding objects for a while, and this seems like a good motivation to start >>>> doing it. >>>> >>>> cheers >>>> >>>> 2015-02-24 14:35 GMT-03:00 Alexandre Torres Porres <[email protected]>: >>>> >>>> > try loading the "hexloader" before accessing these objects, it might >>>>> help. >>>>> >>>>> Yep, now it loads them all, thanks. >>>>> >>>>> So hmm, seems weird that it doesn't load on its own, but maybe I just >>>>> wont bother to follow up with all the tech issues. But anyway, I'd like to >>>>> know if there are any plans to get to a point where we could create these >>>>> objects without this workaround... is it? >>>>> >>>>> So, getting back to the objects. From the 10 objects I pointed out >>>>> (here below) >>>>> >>>>> [!-], [!-~], [!/], [!/~], [>~], [>=~], [<~], [<=~], [!=~] and [==~] >>>>> >>>>> We do have in fact only 3 in zexy (<~, >~, ==~), but their behaviour >>>>> wouldn't count as proper max cloning, cause when you put a number argument >>>>> in it, it only takes number data into the second inlet, while in Max it >>>>> still allows an audio signal to come through. >>>>> >>>>> I think it's important to avoid redundancies, but I guess you can't >>>>> avoid it if one is doing exact max clones of these 3 and the other 7 >>>>> objects. >>>>> >>>>> I made one abstraction here for [>=~], find it attached. It works fine >>>>> here >>>>> in my computer even though it contains "weird and problematic" >>>>> characters in its name. >>>>> >>>>> It doesn't work exactly like the max version though, cause that one >>>>> works with a number argument that is ignored whenever there's a signal >>>>> coming through (even if it is "0"). In order to do it like that, I guess >>>>> you have to compile it as an object. For that matter, I started another >>>>> thread, please check. >>>>> >>>>> thanks >>>>> >>>>> > PS: 0.42.5? wasn't that released 5 years ago, >>>>> > and superceded 2 years ago by 0.43.4? >>>>> >>>>> PS response: Yeah, but I never adapted to 0.43.4, I felt it was buggy >>>>> in a few ways. By the way, one of the issues was that many of my patches >>>>> didn't work because of the [poltocar~] and [cartopol~] bug/problem I >>>>> pointed out in this thread about maintaining cyclone. Moreover, I have a >>>>> quite dense tutorial with over 200 examples now, and many of them used >>>>> [cartopol~]... other patches wouldn't work for other reasons. >>>>> >>>>> I was expecting newer releases to fix this and other issues, but the >>>>> development stopped and died completely... so... >>>>> >>>>> > it seems that Pd has a revolutionary fast >>>>> > development cycle >>>>> >>>>> yeah, I beg to differ :) >>>>> >>>>> >>>>> >>>>> 2015-02-24 12:11 GMT-03:00 IOhannes m zmoelnig <[email protected]>: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA256 >>>>>> >>>>>> On 2015-02-24 15:50, Alexandre Torres Porres wrote: >>>>>> >> &&~, ||~, <~, >~, ==~ >>>>>> > >>>>>> > none of these are created in extended 0.42-5, were they added only >>>>>> > in the latest version? >>>>>> >>>>>> no. zexy ships these objects for about 10 years or so (maybe longer). >>>>>> >>>>>> >>>>>> there has been endless discussion about >>>>>> - - object names containing special characters (like '|') >>>>>> - - splitting multi-object libraries (like zexy) into single-object >>>>>> binaries >>>>>> >>>>>> both are most likely related to your problems. please check the >>>>>> archives on those issues (and let's not repeat themover). >>>>>> >>>>>> try loading the "hexloader" before accessing these objects, it might >>>>>> help. >>>>>> >>>>>> fgmasdr >>>>>> IOhannes >>>>>> >>>>>> PS: 0.42.5? wasn't that released 5 years ago, and superceded 2 years >>>>>> ago by 0.43.4? finally, it seems that Pd has a revolutionary fast >>>>>> development cycle - at least compared to inertia of its users :-) >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG v1 >>>>>> >>>>>> iQIcBAEBCAAGBQJU7JS6AAoJELZQGcR/ejb46ycP/j8hb/ak6TAAL2K/jXMFE/rW >>>>>> gSq8PiQqW7yo4+M1aUK9+sb/hnPBoC80OVjRBOlPou9ktH2z1/ioT+DCM+UQzXeb >>>>>> IvhF2ykmWU5s6morwEbZ2FtURNiB8KUSL919noKZGpZpxjFWo5GVch5h6YFTl7zm >>>>>> 8Xzia/7Gq5mR9XMVHwooPySY5qaGSUDCnXEWKmeBmnH3Pj77lovdzWOAN9jt8cUa >>>>>> SoPJEQuJyTF/nPlO/j6sA9DN0xU6crHK3wQL62cnwKKeviAW4b5toOWmMdJf6xXg >>>>>> i9059mhA/z1vD2IUcsbYJOokoNYxVI9S7P15NaY6Wf20wSPkyAkqOt7Cb8VMkVv/ >>>>>> G36SmSN00KL8Mdtu6a/68EhuHRk0fwwEc/alk3zTb1/hlXidmBiuHFzR+P+DklA3 >>>>>> Z0uhgGeSl2EL986ES/TQLKxibkVs3nTOpQ5R2shyXHoN7jS/wYdhcQaCdjx84s6U >>>>>> LHjxtpCpo8MHeKRMo6xq2Pduf6rmZNiKCzohqqtcZ1AY5bVAd1eZGY2CpQr7X1/C >>>>>> J8pkWXjNb38/J416Ix7Jo6M17NUaLoGlDogKx+BRFvTh3k8+M0zjBYAv8iW8ptGK >>>>>> GQ/JhPdBPZ+HBcUq+zxMdibUogf39Pxp5xhXpKJWfR/S3ZLIR+QeGEkYD535XaTj >>>>>> Lq7wpExpmCa5DnEnTumj >>>>>> =+wzf >>>>>> -----END PGP SIGNATURE----- >>>>>> >>>>>> _______________________________________________ >>>>>> [email protected] mailing list >>>>>> UNSUBSCRIBE and account-management -> >>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
