Hi Ivica, Jonathan,
Thanks for the response.
@Ivica:
Why not simply use cyclone help patches provided in pd-l2ork that already conform to the pddp standard?
The pd-l2ork help patches with standard format indeed look much better than the 'free-style' pd-extended patches. That is why I use these as a base. But I do not copy them directly for several reasons:
- the lack of curly lines in pd-extended make pd-l2ork formatted patches
a little less clean than possible,
- not all patches are correct, usually because the original had the problem,
- the pd META information is incorrect (probably copied from an pd-core
object),
- to learn as much as possible of these objects, I try then to see if
they work and how. This can lead to changes to the patch.
Of course a mass copy would be a fast way to improve cyclone help, but with the long term goal in mind, I think this slow method could result in better help files. Later I will see how they look in pd-vanilla and pd-l2ork and make adjustments.
@Jonathan:
But then Pd Vanilla aficionados might complain that to use cyclone they would be forced to also install the pddp library for [pddplink] and [helplink], because those objects do not ship with Pd Vanilla. Otherwise they would end up with a lot of broken objects in those help patches.
There seems to a 'rule' to make help-patches only dependent on vanilla objects, and this makes sense. But maybe we can use a rich help-patch to generate a vanilla-compliant one (see below).
All the little Pd libraries in Debian don't help this problem, because not every GNU/Linux distribution uses apt. (Nor does OSX or Windows, for that matter.)
The other main distribution tool is rpm. It might be interesting to know how much of the "Linux-market" uses either deb or rpm. For Windows and OSX, there is no ready made solution yet. But other software packages have a cross-platform package distribution system; the examples I know are perl (ActiveState) and cygwin. But is probably not trival to build or adapt something for Pd.
Also, I believe Hans emailed awhile back asking if I'd do the work of removing the PDDP template boilerplate from the tutorial revisions I did. He wanted me to leave only the [pd META] subpatch, because that's evidently the only part Miller wanted to add to Vanilla.
Making help-patches as much as possible is also one of the modifications I make to the pd-l2ork help-patches. So far I ignored the pddp code. But removing the line with "pddp/pddplink" seems to work and this can be scripted. But for pd environments that always have the complete set, it is a great feature to have links.
Greetings,
Fred Jan
Hey guys, Are there any plans to get toxy/tot included in pd-extended? I find it very useful.Cheers,Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
On Saturday, 6 December 2014, 10:00, Fred Jan Kraan <fjkraan@xs4all.nl> wrote:
Hi Ivica, Jonathan,
Thanks for the response.
@Ivica:
Why not simply use cyclone help patches provided in pd-l2ork that already conform to the pddp standard?
The pd-l2ork help patches with standard format indeed look much better than the 'free-style' pd-extended patches. That is why I use these as a base. But I do not copy them directly for several reasons:
- the lack of curly lines in pd-extended make pd-l2ork formatted patches
a little less clean than possible,
- not all patches are correct, usually because the original had the problem,
- the pd META information is incorrect (probably copied from an pd-core
object),
- to learn as much as possible of these objects, I try then to see if
they work and how. This can lead to changes to the patch.
Of course a mass copy would be a fast way to improve cyclone help, but with the long term goal in mind, I think this slow method could result in better help files. Later I will see how they look in pd-vanilla and pd-l2ork and make adjustments.
@Jonathan:
But then Pd Vanilla aficionados might complain that to use cyclone they would be forced to also install the pddp library for [pddplink] and [helplink], because those objects do not ship with Pd Vanilla. Otherwise they would end up with a lot of broken objects in those help patches.
There seems to a 'rule' to make help-patches only dependent on vanilla objects, and this makes sense. But maybe we can use a rich help-patch to generate a vanilla-compliant one (see below).
All the little Pd libraries in Debian don't help this problem, because not every GNU/Linux distribution uses apt. (Nor does OSX or Windows, for that matter.)
The other main distribution tool is rpm. It might be interesting to know how much of the "Linux-market" uses either deb or rpm. For Windows and OSX, there is no ready made solution yet. But other software packages have a cross-platform package distribution system; the examples I know are perl (ActiveState) and cygwin. But is probably not trival to build or adapt something for Pd.
Also, I believe Hans emailed awhile back asking if I'd do the work of removing the PDDP template boilerplate from the tutorial revisions I did. He wanted me to leave only the [pd META] subpatch, because that's evidently the only part Miller wanted to add to Vanilla.
Making help-patches as much as possible is also one of the modifications I make to the pd-l2ork help-patches. So far I ignored the pddp code. But removing the line with "pddp/pddplink" seems to work and this can be scripted. But for pd environments that always have the complete set, it is a great feature to have links.
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 12/06/2014 04:53 AM, Fred Jan Kraan wrote:
Hi Ivica, Jonathan,
Thanks for the response.
@Ivica:
Why not simply use cyclone help patches provided in pd-l2ork that already conform to the pddp standard?
The pd-l2ork help patches with standard format indeed look much better than the 'free-style' pd-extended patches. That is why I use these as a base. But I do not copy them directly for several reasons:
- the lack of curly lines in pd-extended make pd-l2ork formatted patches
a little less clean than possible,
- not all patches are correct, usually because the original had the problem,
- the pd META information is incorrect (probably copied from an pd-core
object),
- to learn as much as possible of these objects, I try then to see if
they work and how. This can lead to changes to the patch.
Of course a mass copy would be a fast way to improve cyclone help, but with the long term goal in mind, I think this slow method could result in better help files. Later I will see how they look in pd-vanilla and pd-l2ork and make adjustments.
@Jonathan:
But then Pd Vanilla aficionados might complain that to use cyclone they would be forced to also install the pddp library for [pddplink] and [helplink], because those objects do not ship with Pd Vanilla. Otherwise they would end up with a lot of broken objects in those help patches.
There seems to a 'rule' to make help-patches only dependent on vanilla objects, and this makes sense. But maybe we can use a rich help-patch to generate a vanilla-compliant one (see below).
It's instructive to have some history on this...
The PDDP template was developed by developers of Pd. They started with
a format, revised it based on IRC chats (and maybe other meetings, I'm
not sure), and wrote some wiki pages about the goals of the project.
AFAICT this included all the major developers of Pd. Everyone gave
input. Input was considered and things were revised. There were
certainly drawbacks and benefits to the template and design chosen, but
that's true with anything.
Then nobody worked on actually implementing any of this.
I didn't participate in that process. I just came along after it had happened, noticed it hadn't been implemented, and began the long, boring task of implementing it. Hans had a help patch for [float] which already used the template and had links-- plus some other templates on pure data info-- so I took those and ran with it.
I added some things like the "Usage Guide", and where details were missing I inquired on the list. After typically receiving no feedback from the list (because, after all, this is truly boring stuff), I just made a decision and stuck with it. Other than [pddp/helplink], I added no dependencies to the template that weren't already there. I asked Hans for permission to commit, and committed all the pd-extended reference docs you currently see included in the distro.
Consequent to that I found out Miller didn't want to include the
PDDP-formatted help patches in Vanilla. That, along with other obvious
signs of Pd-community dysfunction convinced me that it would be more
trouble than it's worth trying to convince everyone to use the PDDP
template for the external libs. Still, the other part of the standard
was to tag the terse help docs with keywords to make it possible to
search for Pd objects/tutorials/etc. That only required the addition of
a single subpatch, and who would possibly argue against adding that?
(It turns out one dev still didn't accept that.) I then added those
subpatches to as many libs as I could, and contacted the maintainer to
commit the changes. For unmaintained libs I did the commits myself.
So, to recap: the "rule" you observe stems from my own reluctance to have futile discussions about why there aren't hyperlinks in Pd Vanilla, how to get them included, how to further revise the PDDP template for devs who barely even write help patches as it is, and so on. I just wanted to be able to search the docs to find what I need. By only adding subpatches I was able to achieve this. The downside is that the help patches remain way less helpful because there are no links to easily cross-reference topics. My own knowledge about what those cross-references would be has disappeared over time.
All the little Pd libraries in Debian don't help this problem, because not every GNU/Linux distribution uses apt. (Nor does OSX or Windows, for that matter.)
The other main distribution tool is rpm. It might be interesting to know how much of the "Linux-market" uses either deb or rpm. For Windows and OSX, there is no ready made solution yet. But other software packages have a cross-platform package distribution system; the examples I know are perl (ActiveState) and cygwin. But is probably not trival to build or adapt something for Pd.
Also, I believe Hans emailed awhile back asking if I'd do the work of removing the PDDP template boilerplate from the tutorial revisions I did. He wanted me to leave only the [pd META] subpatch, because that's evidently the only part Miller wanted to add to Vanilla.
Making help-patches as much as possible is also one of the modifications I make to the pd-l2ork help-patches.
I don't understand what you mean. Are you saying you revised the Pd-l2ork help patches? If so, send them to me and I'll commit.
If not-- is there a way for me to get a master list of the changes you've made? If so I'm happy to integrate them into Pd-l2ork's help docs.
So far I ignored the pddp code. But removing the line with "pddp/pddplink" seems to work and this can be scripted. But for pd environments that always have the complete set, it is a great feature to have links.
That would only work if all [pddp/pddplink] objects come last in the pd file. Otherwise you'll throw off the connection indices. (Maybe you didn't notice the effect because so many of the objects are comments, which don't have wires.)
Why aren't there hyperlinks in Pd Vanilla? We shouldn't be working around this in the 21st century.
-Jonathan
Greetings,
Fred Jan
Hi Jonathan,
It's instructive to have some history on this...
I prefer to focus on what is possible, and the cyclone patches are for pd-extended/pd-l2ork anyhow. Hyperlinks are cool, but there can be a downside; maybe someone creates a pd-based exploit ;-).
That would only work if all [pddp/pddplink] objects come last in the pd file. Otherwise you'll throw off the connection indices. (Maybe you didn't notice the effect because so many of the objects are comments, which don't have wires.)
Maybe some smart scripting could do this properly. Added it to the todo list. This would mean we can build rich help-patches for pd-extended/pd-l2ork and automatically strip them down to be vanilla-compliant. Is there a description of the file format somewhere?
Why aren't there hyperlinks in Pd Vanilla? We shouldn't be working around this in the 21st century.
We have them in other forks like pd-extended and pd-l2ork. Lets concentrate on making those better and more accessible. A lot of good pd forks have died because of the focus on getting their features in pd-vanilla.
But enough of this. For now, I'll prefer to spend my sparse free time on learning pd and improve help-patches. It is more constructive and more fun.
-Jonathan
Greetings,
Fred Jan
hi, you probably know about this bug, but [rand~]'s argument doesn't really work. I'd be happy to help find other bugs, do you have a list of bugs you're working on?
cheers
2014-12-07 14:43 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Jonathan,
It's instructive to have some history on this...
I prefer to focus on what is possible, and the cyclone patches are for pd-extended/pd-l2ork anyhow. Hyperlinks are cool, but there can be a downside; maybe someone creates a pd-based exploit ;-).
That would only work if all [pddp/pddplink] objects come last in the pd file. Otherwise you'll throw off the connection indices. (Maybe you didn't notice the effect because so many of the objects are comments, which don't have wires.)
Maybe some smart scripting could do this properly. Added it to the todo list. This would mean we can build rich help-patches for pd-extended/pd-l2ork and automatically strip them down to be vanilla-compliant. Is there a description of the file format somewhere?
Why aren't there hyperlinks in Pd Vanilla? We shouldn't be working around this in the 21st century.
We have them in other forks like pd-extended and pd-l2ork. Lets concentrate on making those better and more accessible. A lot of good pd forks have died because of the focus on getting their features in pd-vanilla.
But enough of this. For now, I'll prefer to spend my sparse free time on learning pd and improve help-patches. It is more constructive and more fun.
-Jonathan
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Alexandre,
Thanks for the report.
Next to working on the help-patches, I am working on creating such a list. I'll put it somewhere public when the patches are done.
So when you find any others, I would like to know.
Greetings,
Fred Jan
hi, you probably know about this bug, but [rand~]'s argument doesn't really work. I'd be happy to help find other bugs, do you have a list of bugs you're working on?
cheers
cartopol~ and poltocar~ are also buggy
I pointed it out once, but only cartopol~ was corrected and it made it worse. check atatchment.
do you have this covered?
cheers
2014-12-08 14:30 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Alexandre,
Thanks for the report.
Next to working on the help-patches, I am working on creating such a list. I'll put it somewhere public when the patches are done.
So when you find any others, I would like to know.
Greetings,
Fred Jan
hi, you probably know about this bug, but [rand~]'s argument doesn't really work. I'd be happy to help find other bugs, do you have a list of bugs you're working on?
cheers
A few other things, I'm on Extended 0.42-5 btw
About [allpass~], it seems it's supposed to have only 3 arguments, not 4
[delay~] takes 2 arguments, you should mention that in the help file.
there's no help file for [triangle~] and [zerox~]
now for a suggestion max's teeth~ seems like an easy new object to clone, based on comb~
cheers
2014-12-08 20:37 GMT-02:00 Alexandre Torres Porres porres@gmail.com:
cartopol~ and poltocar~ are also buggy
I pointed it out once, but only cartopol~ was corrected and it made it worse. check atatchment.
do you have this covered?
cheers
2014-12-08 14:30 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Alexandre,
Thanks for the report.
Next to working on the help-patches, I am working on creating such a list. I'll put it somewhere public when the patches are done.
So when you find any others, I would like to know.
Greetings,
Fred Jan
hi, you probably know about this bug, but [rand~]'s argument doesn't really work. I'd be happy to help find other bugs, do you have a list of bugs you're working on?
cheers
Hi all,
The set of updated help-patches for the cyclone library is now complete. I'll check them at least once more time. For now they are at: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches
Meanwhile there is also a list of issues to fix: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
If more people want to help, I could put the list in the wiki if I manage to figure out how.
Fred Jan
Great work! I'll take a look at them for Pd-l2ork.
-Jonathan
On Friday, December 12, 2014 8:20 AM, Fred Jan Kraan <fjkraan@xs4all.nl> wrote:
Hi all,
The set of updated help-patches for the cyclone library is now complete. I'll check them at least once more time. For now they are at: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches
Meanwhile there is also a list of issues to fix: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
If more people want to help, I could put the list in the wiki if I manage to figure out how.
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
awesome, though I wouldn't point th issue with cartopol~/poltocar~ as "accuracy", it's just positive when it should be negative and vice versa, but I assume you know what's going on.
cheers
2014-12-12 13:03 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at
:
Great work!
I'll take a look at them for Pd-l2ork.
-Jonathan
On Friday, December 12, 2014 8:20 AM, Fred Jan Kraan fjkraan@xs4all.nl wrote:
Hi all,
The set of updated help-patches for the cyclone library is now complete. I'll check them at least once more time. For now they are at: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches
Meanwhile there is also a list of issues to fix: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
If more people want to help, I could put the list in the wiki if I manage to figure out how.
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Alexandre,
Thanks for the clarification, I changed the overview. But this is a good example for the type of problem that maybe shouldn't be fixed in the current objects. How many now working patches will break when the object behaviour changes? A workaround could be to create new objects, e.g. cartopol2~ and poltocart2~ with the correct behaviour. A correct working cartopol~ and poltocart~ would then have to wait for a new library.
Some community input is welcome on this.
The plan now is to further investigate the items on the list, create bug-report tickets at https://sourceforge.net/p/pure-data/bugs, try to fix the problem, test it and create and insert code-patches at https://sourceforge.net/p/pure-data/patches/ and then have them apply to the code. The mechanism is just for this and it is operational. The list on my site should be seen as just a preliminary overview of tasks.
Greetings,
Fred Jan
awesome, though I wouldn't point th issue with cartopol~/poltocar~ as "accuracy", it's just positive when it should be negative and vice versa, but I assume you know what's going on.
cheers
2014-12-12 13:03 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>:
Great work! I'll take a look at them for Pd-l2ork. -Jonathan On Friday, December 12, 2014 8:20 AM, Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> wrote: Hi all, The set of updated help-patches for the cyclone library is now complete. I'll check them at least once more time. For now they are at: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches Meanwhile there is also a list of issues to fix: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html If more people want to help, I could put the list in the wiki if I manage to figure out how. Fred Jan _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here's the deal, using such objects only make sense if converting to and back, right? I mean, at least for FFT that's the way it is, and I can't think of another example.
Oh, and let it be clear that only the phase value is coming out wrong (negative when it should be positive). And that is by using [cartopol~], of course.
Anyway, for any kind of spectral processing and stuff, it doesn't really matter if the phase is positive or negative. In other words, it sounds the same wether the phase value is theoretically correct or not. But this is only true if the backwards conversion with [poltocar~] is equally "incorrect".
This is an example where two wrongs make it right. And they were both wrong, but working. On the other hand, [cartopol] and [poltocar] where always correct, by the way.
So the issue was just that if you wanted plot or print the phase from [cartopol~] you get a wrong value. Not that much of a big deal. But it would hurt to make the audio objects rights like the data versions.
Now get ready for the ultimate issue. I had complained about all this way way long ago. And when Pd Extended 0.43 came out, apparently, something was done about it, but only one of the objects where changed (I guess [cartopol~]).
What doesn it mean? As of then, NONE of the spectral processing do work at all! Cause when [poltocar~] converts it back. It's just wrong.
In other words, it was better before, when two wrongs made it right.
How many now working patches will break when the object behaviour changes? A workaround could be to create new objects, e.g. cartopol2~ and poltocart2~ with the correct behaviour.
So, it was an honest concern. But the bottom line of what I'm telling you is: Nothing will break if this is corrected, and, actually, my patches using cartopol and poltocar are all broken in Pd Extended 0.43
So the only reasonable thing to do right now is just fix it as it is supposed to be. What do you say?
Can you follow all that I'm saying? I hope I was clear. Let me know if you need more details.
Thanks
2014-12-13 11:33 GMT-02:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Alexandre,
Thanks for the clarification, I changed the overview. But this is a good example for the type of problem that maybe shouldn't be fixed in the current objects. How many now working patches will break when the object behaviour changes? A workaround could be to create new objects, e.g. cartopol2~ and poltocart2~ with the correct behaviour. A correct working cartopol~ and poltocart~ would then have to wait for a new library.
Some community input is welcome on this.
The plan now is to further investigate the items on the list, create bug-report tickets at https://sourceforge.net/p/pure-data/bugs, try to fix the problem, test it and create and insert code-patches at https://sourceforge.net/p/pure-data/patches/ and then have them apply to the code. The mechanism is just for this and it is operational. The list on my site should be seen as just a preliminary overview of tasks.
Greetings,
Fred Jan
awesome, though I wouldn't point th issue with cartopol~/poltocar~ as "accuracy", it's just positive when it should be negative and vice versa, but I assume you know what's going on.
cheers
2014-12-12 13:03 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>:
Great work! I'll take a look at them for Pd-l2ork. -Jonathan On Friday, December 12, 2014 8:20 AM, Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> wrote: Hi all, The set of updated help-patches for the cyclone library is nowcomplete.
I'll check them at least once more time. For now they are at: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches Meanwhile there is also a list of issues to fix:http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
If more people want to help, I could put the list in the wiki if I manage to figure out how. Fred Jan _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Dec 13, 2014 8:35 AM, "Fred Jan Kraan" fjkraan@xs4all.nl wrote:
Hi Alexandre,
Thanks for the clarification, I changed the overview. But this is a good example for the type of problem that maybe shouldn't be fixed in the current objects. How many now working patches will break when the object behaviour changes? A workaround could be to create new objects, e.g. cartopol2~ and poltocart2~ with the correct behaviour. A correct working cartopol~ and poltocart~ would then have to wait for a new library.
FWIW, I adamantly oppose this kind of an approach within pd-l2ork because if the original object behaves wrong, it needs to be fixed. And if any patches really on this wrong behavior they should be fixed as well. Otherwise, this is not a Max compatibility library and the pd libraries that are treated this way will morph into a confusing pile of similar objects with minimal differences and an incredibly steep learning curve.
Some community input is welcome on this.
The plan now is to further investigate the items on the list, create bug-report tickets at https://sourceforge.net/p/pure-data/bugs, try to fix the problem, test it and create and insert code-patches at https://sourceforge.net/p/pure-data/patches/ and then have them apply to the code. The mechanism is just for this and it is operational. The list on my site should be seen as just a preliminary overview of tasks.
Greetings,
Fred Jan
awesome, though I wouldn't point th issue with cartopol~/poltocar~ as "accuracy", it's just positive when it should be negative and vice versa, but I assume you know what's going on.
cheers
2014-12-12 13:03 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>:
Great work! I'll take a look at them for Pd-l2ork. -Jonathan On Friday, December 12, 2014 8:20 AM, Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> wrote: Hi all, The set of updated help-patches for the cyclone library is now
complete.
I'll check them at least once more time. For now they are at: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches Meanwhile there is also a list of issues to fix:
http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
If more people want to help, I could put the list in the wiki if I manage to figure out how. Fred Jan _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
On 06/12/14 20:53, Fred Jan Kraan wrote:
The other main distribution tool is rpm. It might be interesting to know how much of the "Linux-market" uses either deb or rpm.
perhaps more interesting ... how much of the multimedia producer and pd developer community uses linux which is neither deb based nor source based like gentoo, and also isn't a multimedia distribution which includes pd packages. My guess would be that a lot of the remainder would be using fedora in the context of an institution, have IT support and a standard institution wide install.
Alien will translate to rpm format if you wish, and of course the debian repository has complete sources and build systems for the packages and all their dependencies (and better than daily builds alongside the dependencies, on many hardware and kernel combinations). Alien translates both ways. there is a debian package available, and it seems available for rpm based systems also .. see http://joeyh.name/code/alien/
For Windows and OSX, there is no ready made solution yet. But other software packages have a cross-platform package distribution system; the examples I know are perl (ActiveState) and cygwin. But is probably not trival to build or adapt something for Pd.
a packaging system is a long long way from easy, somethinng that does what debian does is a truly vast undertaking ... unless within the context of some bigger packaging system then your only choice is source distribution, with pre-built binaries with the most generic options for the most common platforms ... which is what pd has available now. Keeping all the external libraries built is a huge task, l2ork picks a most common and useful set, and distributes them directly ... but they are linux users and only have resources for doing so for linux (they have said they would welcome any efforts from the other user communities to build for their platforms), pd-extended is a valiant attempt to cater for more, it is a huge and cumbersome system because of that ... while there is a lot of interest in downloading binaries for Windows and OSX there is generally almost no interest from those communities in actually doing the work to prepare and make available those binaries.
Simon
Keep in mind that even with the perfect design, you'd still be packaging a lot of binaries that would read like this to the user:douglib - library of binaries written by a guy named doug -Jonathan
On Wednesday, December 10, 2014 7:09 PM, Simon Wise <simonzwise@gmail.com> wrote:
On 06/12/14 20:53, Fred Jan Kraan wrote:
The other main distribution tool is rpm. It might be interesting to know how much of the "Linux-market" uses either deb or rpm.
perhaps more interesting ... how much of the multimedia producer and pd developer community uses linux which is neither deb based nor source based like gentoo, and also isn't a multimedia distribution which includes pd packages. My guess would be that a lot of the remainder would be using fedora in the context of an institution, have IT support and a standard institution wide install.
Alien will translate to rpm format if you wish, and of course the debian repository has complete sources and build systems for the packages and all their dependencies (and better than daily builds alongside the dependencies, on many hardware and kernel combinations). Alien translates both ways. there is a debian package available, and it seems available for rpm based systems also .. see http://joeyh.name/code/alien/
For Windows and OSX, there is no ready made solution yet. But other software packages have a cross-platform package distribution system; the examples I know are perl (ActiveState) and cygwin. But is probably not trival to build or adapt something for Pd.
a packaging system is a long long way from easy, somethinng that does what debian does is a truly vast undertaking ... unless within the context of some bigger packaging system then your only choice is source distribution, with pre-built binaries with the most generic options for the most common platforms ... which is what pd has available now. Keeping all the external libraries built is a huge task, l2ork picks a most common and useful set, and distributes them directly ... but they are linux users and only have resources for doing so for linux (they have said they would welcome any efforts from the other user communities to build for their platforms), pd-extended is a valiant attempt to cater for more, it is a huge and cumbersome system because of that ... while there is a lot of interest in downloading binaries for Windows and OSX there is generally almost no interest from those communities in actually doing the work to prepare and make available those binaries.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Ed Kelly -
Fred Jan Kraan -
Ivica Bukvic -
Jonathan Wilkes -
Simon Wise