On Mer Oct 3 8:45 , IOhannes m zmoelnig sent:
Enrique Erne wrote:
hi community
i patched a prototype for a gigatable abstraction to overcome the 16777216 sample limit http://lists.puredata.info/pipermail/pd-list/2007-09/053479.html
as a side product i got some abs that could be useful..
[between~] with 2 arguments to specify a range and outputs 0/1 if the incoming signal is within that range (purepd). it seems to work so far...
gt~ and lt~ are purepd abstractions of zexy's ~. a difference is the second inline where the zexy object accept signal _and_ control values for the second inlet. it should be easy to add the second inlet but only signal _or_ control can be done of corse.
not to be offsensive, but zexy's [~] are (optionally) implemented as abstractions that require nothing buth a "pd-vanilla" distribution (though they are not purepd, strictly speaking)
i see. simply with expr :-)
the <~ >~ seems to be pretty much standard, will they ever make it into pd-vanilla or is there a license issue?
nevertheless, i like the approach with tables.
btw, the [gt~] does not seem to behave correctly for small values (because of the 1e-6 offset)...
oups yes.. here's an update
Hi Enrique,
Enrique Erne wrote:
the <~ >~ seems to be pretty much standard, will they ever make it into pd-vanilla or is there a license issue?
Actually, on some systems there's an object name issue. I've seen many cases on Windows, and some on OS X, where ">" and "<" cannot be used in a filename, and therefore any object with those characters in the name will not create. I've recommended the [expr~] alternative for a long time now.
best, d.
On Thu, 2007-10-04 at 01:02 +0200, Derek Holzer wrote:
Hi Enrique,
Enrique Erne wrote:
the <~ >~ seems to be pretty much standard, will they ever make it into pd-vanilla or is there a license issue?
Actually, on some systems there's an object name issue. I've seen many cases on Windows, and some on OS X, where ">" and "<" cannot be used in a filename, and therefore any object with those characters in the name will not create.
just for the record: it will not create in pd-extended (or with externals compiled in libdir format), but it will with externals as library. i don't think, that the author(s) (IOhannes?) of zexy had this in mind, when writing zexy. afaik, that was far before pd-extended came up.
personally, i think as well, that these objects are good candidates to be inlcuded to pd-vanilla, as well as these: [abs~], [sgn~]
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hi Roman,
Roman Haefeli wrote:
just for the record: it will not create in pd-extended (or with externals compiled in libdir format), but it will with externals as library.
Ah! That's good to know. And of course it makes sense, if "zexy.pd_$OS" has no "<" or ">" in the filename, there's no reason why [>~] or [<~] cannot be created from that library.
best, d.
Roman Haefeli wrote:
On Thu, 2007-10-04 at 01:02 +0200, Derek Holzer wrote:
Hi Enrique,
Enrique Erne wrote:
the <~ >~ seems to be pretty much standard, will they ever make it into pd-vanilla or is there a license issue?
Actually, on some systems there's an object name issue. I've seen many cases on Windows, and some on OS X, where ">" and "<" cannot be used in a filename, and therefore any object with those characters in the name will not create.
just for the record: it will not create in pd-extended (or with externals compiled in libdir format), but it will with externals as library.
it should well be working in pd-extended if you use [import zexy] and then [>~]. however, it will not work with [zexy/>~].
it should also work with some versions of vanilla pd (if zexy is compiled as single objects), but i don't know the exact version numbers where this is supposed to work: probably >0.38 and <0.40 (or <0.41) for pd-vanilla >=0.41 (or 0.40) there is a loader external "hexloader" which you have to load before being able to load these objects.
the hexloader (whether it is used as an external loader or as an internal loader (in the mentioned special versions of Pd)), takes care of the filesystems that do not support extended characters.
this has been discussed a lot but not so recently (because the issue is basically solved) on this list.
i still have no idea how to solve a name [zexy/>~] in the hexloader (the hexloader would allow an object to be named [////], but it doesn't handle paths)
fm.asr IOhannes
On Thu, 04 Oct 2007 01:16:03 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
personally, i think as well, that these objects are good candidates to be inlcuded to pd-vanilla, as well as these: [abs~], [sgn~]
roman
Would get my vote. They are fairly essential core components. Shame about this Windows filename problem though, perhaps [gt~] and [lt~] are better names in that case.
On Thu, 2007-10-04 at 13:03 +0100, Andy Farnell wrote:
On Thu, 04 Oct 2007 01:16:03 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
personally, i think as well, that these objects are good candidates to be inlcuded to pd-vanilla, as well as these: [abs~], [sgn~]
roman
Would get my vote. They are fairly essential core components. Shame about this Windows filename problem though, perhaps [gt~] and [lt~] are better names in that case.
if they would be included into pd-vanilla, the name issue wouldn't be an issue anymore. and for consistency's sake it would be even better, if they kept their old names, since [<] and [>] are already part of pd. though, i don't know if it would lead to any problems, if internals steal the names of externals. at least i cannot think of any, if the behaviour is the same.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
though, i don't know if it would lead to any problems, if internals steal the names of externals. at least i cannot think of any, if the behaviour is the same.
pd grabbed the name of zexy's [tabread4]; i have never heard of someone complaining.
fgmasdr,. IOhannes
On Thu, 4 Oct 2007, Roman Haefeli wrote:
personally, i think as well, that these objects are good candidates to be inlcuded to pd-vanilla, as well as these: [abs~], [sgn~]
in desiredata i have just added [>~] [<~] [>=~] [<=~] [==~] [!=~].
later i will add some more.
[sgn~] won't be added if i don't also add [sgn], but I think that it would be more appropriate as a two-input operator called [<=>] that computes the [sgn] of the [-] of the two inputs. I haven't seen SGN() since BASIC.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Andy Farnell -
Derek Holzer -
Enrique Erne -
IOhannes m zmoelnig -
Mathieu Bouchard -
Roman Haefeli