I just finished integrating the MarkEx objects from Gem into the pd-externals CVS. These are objects from GEM which don't have any dependencies besides libc and are generally useful. What I moved is the entire contents of Gem/src/MarkEx except [hsv2rsb] and the vector lib. [hsv2rsb] depends on some Gem functions. The vector lib could be included as well, but it would be non-trivial to make those objects into single files, so I left it. [abs~] is now in creb and [reson~] is now in cxc, so I didn't include those. Also, all of the objects have been separated into one file per object. You can find these in externals/markex.
Hopefully they will be removed from Gem since they are now a part of the pure-data CVS. Also, this solves a few name conflicts: [average] with maxlib, [counter] with cxc and cyclone, and [change] with pd. I have renamed all of these using gem_ as a prefix, i.e. [gem_average] and included them.
I compiled them under Linux and MacOS X, and will try to compile under Win2k later tonight.
.hc
hi hc,
is it not unfortunate, that every other synthesis toolkit has a simple-and-standard tunable 2-order filter named 'reson', and only Pd would have a cheezy comb-like thing instead?
Is it used heavily out there?
Asking this, also, in order to prevent yet another confusion -- there is already reson~ in my local copy of cyclone (IRs matching those of the msp version)...
Krzysztof
Hans-Christoph Steiner wrote: ...
single files, so I left it. [abs~] is now in creb and [reson~] is now in cxc, so I didn't include those. Also, all of the objects have been
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
is it not unfortunate, that every other synthesis toolkit has a simple-and-standard tunable 2-order filter named 'reson', and only Pd would have a cheezy comb-like thing instead?
I would quite prefer it, if the comb one gets renamed. It will irritate users coming from languages like Csound. (It did irr. me)
ciao
On Thursday, Jul 31, 2003, at 04:59 America/New_York, Frank Barknecht wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
is it not unfortunate, that every other synthesis toolkit has a simple-and-standard tunable 2-order filter named 'reson', and only Pd would have a cheezy comb-like thing instead?
I would quite prefer it, if the comb one gets renamed. It will irritate users coming from languages like Csound. (It did irr. me)
Sounds good to me. [reson~] from Gem/cxc was relatively buried and undocumented, so I can't imagine that it got much use.
.hc
On Thu, 31 Jul 2003, Hans-Christoph Steiner wrote:
I would quite prefer it, if the comb one gets renamed. It will irritate users coming from languages like Csound. (It did irr. me)
Sounds good to me. [reson~] from Gem/cxc was relatively buried and undocumented, so I can't imagine that it got much use.
Hi,
Well, I don 't have to say that I think that the work you are doing is very valuable. For the externals that get trashed, I suggest that instead of renaming them (which would only be of any help if someone wants to use them in a new project). ....
... we just put them in a new folder "deprecated" (or the like). The advantage of this is that people who have old patches around using these objects can select the deprecated version just by adding a path to that folder, and they don't have to rename objects in their old patches.
The order pd searches for externals (abstractions) is:
*) externals come first 1) in local directory (dir of the patch) 2) in the path 3) in the extra directory
What do you think ?
Greetings, Guenter
On Thursday, Jul 31, 2003, at 18:30 America/New_York, guenter geiger wrote:
On Thu, 31 Jul 2003, Hans-Christoph Steiner wrote:
I would quite prefer it, if the comb one gets renamed. It will irritate users coming from languages like Csound. (It did irr. me)
Sounds good to me. [reson~] from Gem/cxc was relatively buried and undocumented, so I can't imagine that it got much use.
Hi,
Well, I don 't have to say that I think that the work you are doing is very valuable. For the externals that get trashed, I suggest that instead of renaming them (which would only be of any help if someone wants to use them in a new project). ....
... we just put them in a new folder "deprecated" (or the like). The advantage of this is that people who have old patches around using these objects can select the deprecated version just by adding a path to that folder, and they don't have to rename objects in their old patches.
The order pd searches for externals (abstractions) is:
*) externals come first
- in local directory (dir of the patch)
- in the path
- in the extra directory
I don't know if I understand this line:
*) externals come first
This order of searching makes sense to me:
- in local directory (dir of the patch)
- in the path
- in the extra directory
That way, you can stick deprecated objects into the local directory to make old patches work. But I have a question: do single objects before objects in libs, or vice versa?
.hc
On Mon, 4 Aug 2003, Hans-Christoph Steiner wrote:
On Thursday, Jul 31, 2003, at 18:30 America/New_York, guenter geiger wrote:
On Thu, 31 Jul 2003, Hans-Christoph Steiner wrote:
I would quite prefer it, if the comb one gets renamed. It will irritate users coming from languages like Csound. (It did irr. me)
Sounds good to me. [reson~] from Gem/cxc was relatively buried and undocumented, so I can't imagine that it got much use.
Hi,
Well, I don 't have to say that I think that the work you are doing is very valuable. For the externals that get trashed, I suggest that instead of renaming them (which would only be of any help if someone wants to use them in a new project). ....
... we just put them in a new folder "deprecated" (or the like). The advantage of this is that people who have old patches around using these objects can select the deprecated version just by adding a path to that folder, and they don't have to rename objects in their old patches.
The order pd searches for externals (abstractions) is:
*) externals come first
- in local directory (dir of the patch)
- in the path
- in the extra directory
I don't know if I understand this line:
*) externals come first
it means before abstractions..
This order of searching makes sense to me:
- in local directory (dir of the patch)
- in the path
- in the extra directory
That way, you can stick deprecated objects into the local directory to make old patches work. But I have a question: do single objects before objects in libs, or vice versa?
libs are already loaded at startup, so they come first. I think if you load two libs with the same object, then the second one is valid .. have to check that ...
Greetings,
Guenter
-
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Krzysztof Czaja