is there an object in extended like [range] or [maxlib/scale] that works for audio signals? thanks
On Thu, 2015-06-04 at 18:07 -0300, Alexandre Torres Porres wrote:
is there an object in extended like [range] or [maxlib/scale] that works for audio signals? thanks
I couldn't find a [range] object in Pd-extended.
In [maxlib/scale] both - input and output ranges - are specified. I don't have the exact signal version of this at hand, but there is [rh_scalelin~] and [rh_scalelog~]. They assume to input signal to be between 0 and 1 and you can specify the desired output range. That might give you a start.
https://github.com/reduzent/netpd2-patches
Roman
I couldn't find a [range] object in Pd-extended.
I have it in 0.42, maybe yours is 0.43 - it's located in flatspace, but it doesn't even have a help file...
But anyway, I just found that both [range] and [maxlib/scale] have bugs, one being that you can't scale 0-1 to 1-0 for example.
Moreover, just found TWO more objects (abstractions) that also do this, and they seem to work perfectly with no issues, they are: [rrad.scale] & [expr_scale].
About finding an audio solution, [expr~ ($v1-$v2) * ($v4-$v5) / ($v2-$v3) + $v4] does the job, but I was really wondering if there was an object out there that would do it. It seems like a nice thing to have. So nice that 4 objects that are supposed to do the same thing and with similar names showed up (let's talk about redundancy), but it seems no one thought of making an audio version.
Max has both [scale] and [scale~], so it may be a good thing to have them both named like that into cyclone. I guess we could forget about [maxlib/scale] because it is buggy. By the way, "maxlib" seems to be a library that tries to bring max objects to Pd like cyclone, and I didn't know about it, I thought there was only cyclone around - so what's the deal with it?
Well, this all makes me say how I find Pd-extended to be very messy, with many redundanct objects, not to mention buggy or poorly documented (many have no help whatsoever). As I dig further, I just find more of all this... I know this directs this thread to another discussion, but I'd really hope for the update and maintenance active again, and that I could help cleaning some stuff up.
cheers
2015-06-05 3:56 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Thu, 2015-06-04 at 18:07 -0300, Alexandre Torres Porres wrote:
is there an object in extended like [range] or [maxlib/scale] that works for audio signals? thanks
I couldn't find a [range] object in Pd-extended.
In [maxlib/scale] both - input and output ranges - are specified. I don't have the exact signal version of this at hand, but there is [rh_scalelin~] and [rh_scalelog~]. They assume to input signal to be between 0 and 1 and you can specify the desired output range. That might give you a start.
https://github.com/reduzent/netpd2-patches
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fre, 2015-06-05 at 14:32 -0300, Alexandre Torres Porres wrote:
I couldn't find a [range] object in Pd-extended.
I have it in 0.42, maybe yours is 0.43 - it's located in flatspace, but it doesn't even have a help file...
Wow, you're missing so much new stuff... (and yes, I was checking 0.43-extended)
Well, this all makes me say how I find Pd-extended to be very messy, with many redundanct objects, not to mention buggy or poorly documented (many have no help whatsoever). As I dig further, I just find more of all this... I know this directs this thread to another discussion, but I'd really hope for the update and maintenance active again, and that I could help cleaning some stuff up.
I _believe_ Pd-extended was meant to be collection of as much software as was/is available for Pd. It respected the libraries (I'm sure this is argued by some, regarding multi-object libs vs. single-object externals) and put it into namespaces so that the user can decide what to use and what not. One could also say it deferred the burden to deal with the mess on the user. But it made much of the existing Pd ecosystem available to the masses - which I consider a huge achievement - and you can more or less assume that a patch made on platform Y will work the same on platform X with the same version of Pd-extended.
I think tiding it all up is again a huge task. It's all free software, so anyone could do it. Having followed this list for a few years, I don't believe in the "authoritative" collection of Pd externals and abstraction anymore. People are using software in different ways for different purposes, and one can observe that many create their own nice tidied-up unified collections of abstractions (mtl, rjlib, netpd, etc.) and none of them gained so much traction that they would be used by a majority of the Pd users. I even think that trying it would be a lost game and would end up with endless mailing list debates.
Retrospectively, it looks like maintaining something like Pd-extended is a too complex task to be distributed among many and too much for a single person (Pd-L2ork being the counter example). I sense agreement on the notion that effort is better spent on making separate libraries easily accessible/distributable. People willing to help could focus on the external they have the most interest in. It already started in Debian, where IOhannes, Hans (mainly) and me (to some lesser degree) worked on creating proper Debian packages of a lot of externals. Similar could be done for other platforms, too. Pd-extended could be the collection of those packages that are available on all major platforms (or whatever).
Personally, I suffer most from the fact, that Pd-extended is a separately maintained Pd with patches on one hand and a collection of externals on the other. If it would be simply a Pd with a collection of externals, it would be much simpler to just update Pd and add - for all I care - a frozen collection of externals. Pd-extended was always one or two versions behind Pd. Now it's already three. If I want to make my stuff portable and available to non-Pd-savvy people, I have to stick with compatibility with Pd-extended 0.43, which is a huge pain, considering what more recent versions of Pd offer ([array], [text], [oscparse], new methods for time based objects, etc.).
I agree with you that there is a lot of mess and redundancy. But I'm not sure if it matters that much.
Roman
I'm actually ok with lots of mess, check my apartment.
What actually bums me out is that the maintenance is dead, and there's no sign anything is gonna happen. Last time someone discussed it was 6 months ago and it just went silent...
I'd really like to spend a lot of personal effort in this, Pd is a very important part of my work and I'd love to pay it back, but unfortunately I'm no programmer. I'll do what I can, I'll manage, I'll test it, I'll try to clean the mess, I'll report bugs and organize/manage the project. I'll even study and start programming what I can. Count me in, but without an actual community, there's no deal.
I just collaborated with supercollider, I helped in a bug report, I revised and rewrote the help of 3 objects, and it went nice and smoothly like a charm. They seem to have a nice community working on out there, we don't. It seems extended was all concentrated in Hans and not a community.
cheers
2015-06-05 18:52 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Fre, 2015-06-05 at 14:32 -0300, Alexandre Torres Porres wrote:
I couldn't find a [range] object in Pd-extended.
I have it in 0.42, maybe yours is 0.43 - it's located in flatspace, but it doesn't even have a help file...
Wow, you're missing so much new stuff... (and yes, I was checking 0.43-extended)
Well, this all makes me say how I find Pd-extended to be very messy, with many redundanct objects, not to mention buggy or poorly documented (many have no help whatsoever). As I dig further, I just find more of all this... I know this directs this thread to another discussion, but I'd really hope for the update and maintenance active again, and that I could help cleaning some stuff up.
I _believe_ Pd-extended was meant to be collection of as much software as was/is available for Pd. It respected the libraries (I'm sure this is argued by some, regarding multi-object libs vs. single-object externals) and put it into namespaces so that the user can decide what to use and what not. One could also say it deferred the burden to deal with the mess on the user. But it made much of the existing Pd ecosystem available to the masses - which I consider a huge achievement - and you can more or less assume that a patch made on platform Y will work the same on platform X with the same version of Pd-extended.
I think tiding it all up is again a huge task. It's all free software, so anyone could do it. Having followed this list for a few years, I don't believe in the "authoritative" collection of Pd externals and abstraction anymore. People are using software in different ways for different purposes, and one can observe that many create their own nice tidied-up unified collections of abstractions (mtl, rjlib, netpd, etc.) and none of them gained so much traction that they would be used by a majority of the Pd users. I even think that trying it would be a lost game and would end up with endless mailing list debates.
Retrospectively, it looks like maintaining something like Pd-extended is a too complex task to be distributed among many and too much for a single person (Pd-L2ork being the counter example). I sense agreement on the notion that effort is better spent on making separate libraries easily accessible/distributable. People willing to help could focus on the external they have the most interest in. It already started in Debian, where IOhannes, Hans (mainly) and me (to some lesser degree) worked on creating proper Debian packages of a lot of externals. Similar could be done for other platforms, too. Pd-extended could be the collection of those packages that are available on all major platforms (or whatever).
Personally, I suffer most from the fact, that Pd-extended is a separately maintained Pd with patches on one hand and a collection of externals on the other. If it would be simply a Pd with a collection of externals, it would be much simpler to just update Pd and add - for all I care - a frozen collection of externals. Pd-extended was always one or two versions behind Pd. Now it's already three. If I want to make my stuff portable and available to non-Pd-savvy people, I have to stick with compatibility with Pd-extended 0.43, which is a huge pain, considering what more recent versions of Pd offer ([array], [text], [oscparse], new methods for time based objects, etc.).
I agree with you that there is a lot of mess and redundancy. But I'm not sure if it matters that much.
Roman
I'd actually like to know better the issues behind extended, and why is it so hard to just update it to the newer vanilla version and let people manage/update the libraries/externals...
Why, for instance, can't I update a library like cyclone and release a new updated version of extended (let it be 0.43) with the updated objects? What's the deal?
cheers
2015-06-05 20:24 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
I'm actually ok with lots of mess, check my apartment.
What actually bums me out is that the maintenance is dead, and there's no sign anything is gonna happen. Last time someone discussed it was 6 months ago and it just went silent...
I'd really like to spend a lot of personal effort in this, Pd is a very important part of my work and I'd love to pay it back, but unfortunately I'm no programmer. I'll do what I can, I'll manage, I'll test it, I'll try to clean the mess, I'll report bugs and organize/manage the project. I'll even study and start programming what I can. Count me in, but without an actual community, there's no deal.
I just collaborated with supercollider, I helped in a bug report, I revised and rewrote the help of 3 objects, and it went nice and smoothly like a charm. They seem to have a nice community working on out there, we don't. It seems extended was all concentrated in Hans and not a community.
cheers
2015-06-05 18:52 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Fre, 2015-06-05 at 14:32 -0300, Alexandre Torres Porres wrote:
I couldn't find a [range] object in Pd-extended.
I have it in 0.42, maybe yours is 0.43 - it's located in flatspace, but it doesn't even have a help file...
Wow, you're missing so much new stuff... (and yes, I was checking 0.43-extended)
Well, this all makes me say how I find Pd-extended to be very messy, with many redundanct objects, not to mention buggy or poorly documented (many have no help whatsoever). As I dig further, I just find more of all this... I know this directs this thread to another discussion, but I'd really hope for the update and maintenance active again, and that I could help cleaning some stuff up.
I _believe_ Pd-extended was meant to be collection of as much software as was/is available for Pd. It respected the libraries (I'm sure this is argued by some, regarding multi-object libs vs. single-object externals) and put it into namespaces so that the user can decide what to use and what not. One could also say it deferred the burden to deal with the mess on the user. But it made much of the existing Pd ecosystem available to the masses - which I consider a huge achievement - and you can more or less assume that a patch made on platform Y will work the same on platform X with the same version of Pd-extended.
I think tiding it all up is again a huge task. It's all free software, so anyone could do it. Having followed this list for a few years, I don't believe in the "authoritative" collection of Pd externals and abstraction anymore. People are using software in different ways for different purposes, and one can observe that many create their own nice tidied-up unified collections of abstractions (mtl, rjlib, netpd, etc.) and none of them gained so much traction that they would be used by a majority of the Pd users. I even think that trying it would be a lost game and would end up with endless mailing list debates.
Retrospectively, it looks like maintaining something like Pd-extended is a too complex task to be distributed among many and too much for a single person (Pd-L2ork being the counter example). I sense agreement on the notion that effort is better spent on making separate libraries easily accessible/distributable. People willing to help could focus on the external they have the most interest in. It already started in Debian, where IOhannes, Hans (mainly) and me (to some lesser degree) worked on creating proper Debian packages of a lot of externals. Similar could be done for other platforms, too. Pd-extended could be the collection of those packages that are available on all major platforms (or whatever).
Personally, I suffer most from the fact, that Pd-extended is a separately maintained Pd with patches on one hand and a collection of externals on the other. If it would be simply a Pd with a collection of externals, it would be much simpler to just update Pd and add - for all I care - a frozen collection of externals. Pd-extended was always one or two versions behind Pd. Now it's already three. If I want to make my stuff portable and available to non-Pd-savvy people, I have to stick with compatibility with Pd-extended 0.43, which is a huge pain, considering what more recent versions of Pd offer ([array], [text], [oscparse], new methods for time based objects, etc.).
I agree with you that there is a lot of mess and redundancy. But I'm not sure if it matters that much.
Roman
On 2015-06-06 02:07 AM, Alexandre Torres Porres wrote:
I'd actually like to know better the issues behind extended, and why is it so hard to just update it to the newer vanilla version and let people manage/update the libraries/externals...
Why, for instance, can't I update a library like cyclone and release a new updated version of extended (let it be 0.43) with the updated objects? What's the deal?
If you want Pd-extended 0.43 with the latest cyclone, the simplest way _now_ would be to replace the cyclone directory in your Pd-extended installation with the content of the appropriate zip on my site.
The build farm that used to create Pd-extended for all platforms is no more. Only one server is buiding a distribution (debian-wheezy-amd64.deb), but it is based on old sources, not the latest from the svn/git repositories. The 'update link' between the repositories and build server is also gone.
Roman accurately described the problems with maintaining Pd-extended as is. Apparently nobody has the time _and_ knowledge _and_ resources to do it. The 'vanilla' route seems more viable as it distributes the effort over more people.
Greetings,
Fred Jan
cheers
2015-06-05 20:24 GMT-03:00 Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com>:
I'm actually ok with lots of mess, check my apartment. What actually bums me out is that the maintenance is dead, and there's no sign anything is gonna happen. Last time someone discussed it was 6 months ago and it just went silent... I'd really like to spend a lot of personal effort in this, Pd is a very important part of my work and I'd love to pay it back, but unfortunately I'm no programmer. I'll do what I can, I'll manage, I'll test it, I'll try to clean the mess, I'll report bugs and organize/manage the project. I'll even study and start programming what I can. Count me in, but without an actual community, there's no deal. I just collaborated with supercollider, I helped in a bug report, I revised and rewrote the help of 3 objects, and it went nice and smoothly like a charm. They seem to have a nice community working on out there, we don't. It seems extended was all concentrated in Hans and not a community. cheers 2015-06-05 18:52 GMT-03:00 Roman Haefeli <reduzent@gmail.com <mailto:reduzent@gmail.com>>: On Fre, 2015-06-05 at 14:32 -0300, Alexandre Torres Porres wrote: > > I couldn't find a [range] object in Pd-extended. > > > I have it in 0.42, maybe yours is 0.43 - it's located in flatspace, > but it doesn't even have a help file... Wow, you're missing so much new stuff... (and yes, I was checking 0.43-extended) > Well, this all makes me say how I find Pd-extended to be very messy, > with many redundanct objects, not to mention buggy or poorly > documented (many have no help whatsoever). As I dig further, I just > find more of all this... I know this directs this thread to another > discussion, but I'd really hope for the update and maintenance active > again, and that I could help cleaning some stuff up. I _believe_ Pd-extended was meant to be collection of as much software as was/is available for Pd. It respected the libraries (I'm sure this is argued by some, regarding multi-object libs vs. single-object externals) and put it into namespaces so that the user can decide what to use and what not. One could also say it deferred the burden to deal with the mess on the user. But it made much of the existing Pd ecosystem available to the masses - which I consider a huge achievement - and you can more or less assume that a patch made on platform Y will work the same on platform X with the same version of Pd-extended. I think tiding it all up is again a huge task. It's all free software, so anyone could do it. Having followed this list for a few years, I don't believe in the "authoritative" collection of Pd externals and abstraction anymore. People are using software in different ways for different purposes, and one can observe that many create their own nice tidied-up unified collections of abstractions (mtl, rjlib, netpd, etc.) and none of them gained so much traction that they would be used by a majority of the Pd users. I even think that trying it would be a lost game and would end up with endless mailing list debates. Retrospectively, it looks like maintaining something like Pd-extended is a too complex task to be distributed among many and too much for a single person (Pd-L2ork being the counter example). I sense agreement on the notion that effort is better spent on making separate libraries easily accessible/distributable. People willing to help could focus on the external they have the most interest in. It already started in Debian, where IOhannes, Hans (mainly) and me (to some lesser degree) worked on creating proper Debian packages of a lot of externals. Similar could be done for other platforms, too. Pd-extended could be the collection of those packages that are available on all major platforms (or whatever). Personally, I suffer most from the fact, that Pd-extended is a separately maintained Pd with patches on one hand and a collection of externals on the other. If it would be simply a Pd with a collection of externals, it would be much simpler to just update Pd and add - for all I care - a frozen collection of externals. Pd-extended was always one or two versions behind Pd. Now it's already three. If I want to make my stuff portable and available to non-Pd-savvy people, I have to stick with compatibility with Pd-extended 0.43, which is a huge pain, considering what more recent versions of Pd offer ([array], [text], [oscparse], new methods for time based objects, etc.). I agree with you that there is a lot of mess and redundancy. But I'm not sure if it matters that much. Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Fred Jan Kraan -
Roman Haefeli